Refund issues
-
Placing an order via Braintree gateway works well, however if we try to refund it, we get a popup error saying “Error processing refund. Reason: Cannot refund a transaction unless it is settled.”
It appears the payment is not settled yet and i imaging this is the reason for it?
On braintree you can “Void” the transaction.Few questions
1. Does the plugin support refunds immediately after payment?
2. We have set up the webhook. Should we expect braintree to notify our endpoint when the payment has finalised?
3. Voiding a transaction through braintree, doesn’t update the order status on admin.Are the above meant to work with this plugin?
thanks in advance
-
Spooky… I was about to post on the same issue. I am testing Braintree and this plugin on our production site with production credentials, but customers are still directed to the existing gateway until I sort this issue out, as it is quite a big workflow glitch for us.
In answer to the OP’s main question, you can Cancel the order in WC Admin, and that has the effect of voiding and restoring stock to the whole order.
My issue is more nuanced. As I understand it, transactions are batch settled in the evening sometime. Before they are settled, they can be voided in their entirety as above, but not partially. We get a fair few customers who change their minds about one item after buying, and ask for a partial refund, which we do before same day dispatch. It’s good customer service.
I’ve used several other gateways, and all of them, including our current one, allow partial refunds straight away. If we can’t do this, our same day dispatch workflow is out of the window because we would have to manually make changes to dispatch, and then make more manual changes the next day. It’s a step backwards to implement something that either requres considerable manual intervention, or requires us to delay shipment by a day if there is a change to it (which also has a manual component)
Talking to Braintree developer support, they said:
“At this point, instead of attempting to issue partial refunds, I would recommend that you submit the sale transactions for settlement after?you know what the final price of the item and shipping is. For example, if you authorize a customer’s card for $100, and later figure out that you do not need to charge that much, you can submit the sale transaction for a lesser?amount.?? As a flow, this would mean that you do not use the options.submitForSettlement option with Transaction: Sale.?Instead, you explicitly submit the transaction for settlement in a separate Transaction: Submit For Settlement?call with the correct amount that you’d like to charge the customer. You can always submit a transaction for settlement for a lesser amount than is authorized, but you cannot submit for settlement for an amount that is more than the original authorization.??This would mean that the customer is charged the correct amount at the time of the sale. This flow would also mean that you are not waiting until the sale transaction is settling or settled to issue a partial refund.”
Dealing with this is beyond me personally (that’s one reason I need a professionally developed plugin!). I’m actually amazed that there is no mention of this previously.
We too are moving from another Braintree plugin (the one on woocommerce.com) to this and came across this unexpected (and unreported) issue.
In our case, we are attempting full refunds (order with Credi/Debit card) and a Javascript popup comes up with the message I mentioned above. @tufty are you saying you don’t get this message, and refunds work fine?
I am sure we’ll also need partial refunds, so it’s definitely worth exploring both issues.
p.s. this plugin seems considerably better than the other one and comes with more features, so I’m surprised it’s not monetised yet.
Hi @subscriptiongroup We’re actually using a completely different payment provider; one that doesn’t have Apple Pay via any plugin, and that is the reason we’re *trying* to move to Braintree. Other than this partial refund issue, it looks great.
From my testing, I’ve found that refunds do not work at all until settlement (and fail with that message you got), but for full refunds, the workaround is to Cancel the order in the WC Order system. This results in voiding with Braintree and order reversal in WC. But it’s no help for partial refunds.
It appears the payment is not settled yet and i imaging this is the reason for it?
On braintree you can “Void” the transaction.Correct, you cannot refund a transaction that does not have a status of settled. If you look underneath the billing details you will see a clickable icon labeled
Transaction Data / Actions
. If you click that, you will see the option to void the transaction. Or you can set the order’s status to cancelled and it will void automatically.1. Does the plugin support refunds immediately after payment?
The only option available when the transaction is not settled is to void. Braintree does not allow refunds for unsettled transactions. They enforce that via their API. Have you seen this work somewhere else? If so, what’s most likely happening is the other plugin is performing a void even though you triggered a refund via WooCommerce.
2. We have set up the webhook. Should we expect braintree to notify our endpoint when the payment has finalised?
Braintree doesn’t have a webhook that is triggered when a payment is settled. I have spoken to them about that and their response is that for merchants that have many thousands of transactions, it would result in the merchant’s site slowing down since it’s responding to all of the requests.
3. Voiding a transaction through braintree, doesn’t update the order status on admin.
That’s because Braintree doesn’t have a webhook that is triggered when a void is triggered. Because the plugin supports voids within the WordPress dashboard, it’s expected that you will rely on the plugin to perform those actions which will result in the order status being updated.
Are the above meant to work with this plugin?
Yes, all of the above work with the plugin.
Kind Regards,
I’ve used several other gateways, and all of them, including our current one, allow partial refunds straight away
Yes, other Gateways such as Stripe for example allow refunds immediately. Braintree however does not allow this. There isn’t anything I can do within the plugin because that’s enforced by Braintree’s API.
What Braintree’s support is recommending you do is authorize all of your payments instead of capturing them immediately. This way, you can remove items from the order, update the total, then capture the final amount which will be less than the original order amount.
The Braintree plugin has an option within each gateway where you can specify if you want to authorize or capture the payment.
FYI, anytime you load the order details page, the plugin fetches the status of the transaction so it’s always up to date on the order details page.
Kind Regards,
Hi @mrclayton,
1. Ideally, the plugin should decide what actions to take when the staff member presses the “refund” button. Is it not possible to extend the plugin to do so? I might be wrong, but I think the one on woocommerce.com does that.
2. I don’t think it’s as big an issue as they describe because it’s only one API call per order and websites with thousands of orders would have bigger issues to worry about. Ideally, this type of callback would be editable on their platform, just like the rest of the callbacks, so admins can decide if they want this or not. In any case, I just wanted to confirm we’ve not missed any configuration steps.
3. Again, (nothing to do with this plugin) I don’t think their approach is correct because there is the potential for discrepancies. If people are permitted to refund orders through their system, they should make use of the endpoints and notify them.
-
This reply was modified 3 years, 7 months ago by
George.
Hi @mrclayton
The Braintree plugin has an option within each gateway where you can specify if you want to authorize or capture the payment.
Thank for explaining that. If specifying authorization means we would need to manually capture the final amount to get paid, then I’m not sure that is viable at scale. However if, for example, marking an order Completed automatically submitted for settlement with the final amount, then that might be more usable. Does that happen? …or what do you advise?
Edit: I’ve just read down to the bottom of the documentation page:
Order status set to complete – If transcation status is authorized, plugin attempts to submit the transaction for settlement.Sounds good. When you say “attempts” does that mean there is any significant chance it will fail?
-
This reply was modified 3 years, 7 months ago by
tufty.
1. Ideally, the plugin should decide what actions to take when the staff member presses the “refund” button. Is it not possible to extend the plugin to do so? I might be wrong, but I think the one on woocommerce.com does that.
What about in the case of the refund amount being less than the order total? You can’t do partial voids in Braintree so you would have to void the entire transaction. That makes for a horrible merchant experience if the merchant tries to refund $5 of a $25 order but the whole thing is voided. Again, this is because partial voids aren’t possible in Braintree.
2. I don’t think it’s as big an issue as they describe because it’s only one API call per order and websites with thousands of orders would have bigger issues to worry about. Ideally, this type of callback would be editable on their platform, just like the rest of the callbacks, so admins can decide if they want this or not. In any case, I just wanted to confirm we’ve not missed any configuration steps.
Ya I agree it would be a great feature and I have actually requested it in the past but that was the response I received.
3. Again, (nothing to do with this plugin) I don’t think their approach is correct because there is the potential for discrepancies. If people are permitted to refund orders through their system, they should make use of the endpoints and notify them.
I recommend you submit a feature request to Braintree and explain to them that other gateways like Stripe, don’t have this limitation.
Kind Regards,
What about in the case of the refund amount being less than the order total? You can’t do partial voids in Braintree so you would have to void the entire transaction. That makes for a horrible merchant experience if the merchant tries to refund $5 of a $25 order but the whole thing is voided. Again, this is because partial voids aren’t possible in Braintree.
I’m definitely not suggesting voiding the entire transaction if you need a partial refund. Websites that need this, should use “Authorise” instead of “Capture”.
For cases where you just want to refund the entire order, however, can’t you just hijack the “refund” button and void/refund of the entire order? It can even show a popup saying “Braintree does not allow partial refunds. This will refund the entire order. Are you sure? (yes/no)”.
Just to sum up the current functionality around refunds
When “Capture” is selected
1. Orders cannot be voided/refunded fully until they have settled. Presumably, Braintree does this automatically on their end? If there’s no webhook for this, does this plugin allow you to process a refund after certain time?
2. Orders cannot be partially refunded until they have settled?When “Authorise” is selected
3. The order is created and the funds are “blocked” on the customer’s card.
4. We can then do a partial refund/void until the point where it has been captured?
5. Does the plugin request capture automatically? If so when? If not, does Braintree do it automatically?
6. When an order has been captured, can we then do partial or full refunds?Finally, you mentioned that every time you load the order, the plugin checks the status of the order.
7. Does this fire every time, or until the order has been marked as “settled” at which point you update a meta?
8. Does this mean that every time we load an order, an API request takes place?
9. What is the purpose of this API request? Is there something (other than a refund) that requires that? If not, could you not hook this after you’ve pressed the “refund” button so it doesn’t unnecessarily slow down the page?When you say “attempts” does that mean there is any significant chance it will fail?
No, failures are very rare and any failure would most likely be the result of a network issue.
For cases where you just want to refund the entire order, however, can’t you just hijack the “refund” button and void/refund of the entire order? It can even show a popup saying “Braintree does not allow partial refunds. This will refund the entire order. Are you sure? (yes/no)”.
Sure that’s possible, just never had any merchants request that functionality before. Some of the largest merchants using WooCommerce use this plugin so I figured if there was a high demand for that it would have come up.
1. Orders cannot be voided/refunded fully until they have settled. Presumably, Braintree does this automatically on their end? If there’s no webhook for this, does this plugin allow you to process a refund after certain time?
When the refund button is clicked, the plugin attempts to refund the transaction. If transaction doesn’t have a status of settled or settling, then Braintree returns an error and the plugin displays that message informing you that the transaction can’t be refunded right now. That’s the indicator to the merchant that they should perform the void.
2. Orders cannot be partially refunded until they have settled?
Orders cannot be partially refunded unless the transaction associated with the order has a status of settling or settled.
When “Authorise” is selected
3. The order is created and the funds are “blocked” on the customer’s card.
4. We can then do a partial refund/void until the point where it has been captured?You don’t need to perform a refund on an authorized transaction. An authorized transaction just means the funds have been held but not captured. That means you can just update the order total and when you’re ready to ship your items, capture the transaction.
5. Does the plugin request capture automatically? If so when? If not, does Braintree do it automatically?
The plugin requests to capture the transaction when the order’s status is updated to completed.
6. When an order has been captured, can we then do partial or full refunds?
Yes
Finally, you mentioned that every time you load the order, the plugin checks the status of the order.
What I should have said is the transaction status is fetched when you open the
Transaction Data / Actions
popup. An API request is not made every-time the order details page is rendered.Thank you for this. I’ve now made the gateway public and I can see a fair few transactions.
1. Capture/Authorization is separately selected for CC/AP/GP/PP. Do they all work in the same way as you have described?
2. I’ve just tried partially refunding a trial order, selecting “Refund £XX via Braintree CC Gateway” It again said that it cannot process that until settled. Does that mean I should instead select “Refund £XX Manually” and that your plugin will automatically pick up the new order value and attempt to settle that on Completion? If that is the case, would it make sense to hide the Braintree button and rename the manual one to something like: “Amend order by -£XX” if the transaction is in Authorized status?
1. Capture/Authorization is separately selected for CC/AP/GP/PP. Do they all work in the same way as you have described?
Yes
If that is the case, would it make sense to hide the Braintree button and rename the manual one to something like: “Amend order by -£XX” if the transaction is in Authorized status?
I don’t think that makes sense because as the merchant, you already know that you have set the
Transaction Type
to authorize therefore you know you should use the manual refund option. The manual option will update the order total, then when you’re ready you can capture the order’s new total.For cases where you just want to refund the entire order, however, can’t you just hijack the “refund” button and void/refund of the entire order? It can even show a popup saying “Braintree does not allow partial refunds. This will refund the entire order. Are you sure? (yes/no)”.
Sure that’s possible, just never had any merchants request that functionality before. Some of the largest merchants using WooCommerce use this plugin so I figured if there was a high demand for that it would have come up.
It’s not the first time we raise issues with the plugins we use that nobody else did… I don’t understand why this is happening, because as you say, you’d expect other big merchants to have found them previously.
Not sure if you have the means to contact some of those merchants and check what they do in the scenario we described? Maybe they have written custom code to extend your plugin thinking this feature will never become available? We would certainly look into this option if you don’t plan to change this.5. Does the plugin request capture automatically? If so when? If not, does Braintree do it automatically?
The plugin requests to capture the transaction when the order’s status is updated to completed.
1. I assume there are hooks available to change when this takes place?
2. Is there a time limit on how long a transaction can stay in “Authorised”? If for example you use a “pre-order” plugin where the customer is paying but know they’ll get their item in a month or two, would the transaction remain authorised forever?
3. Have you heard of any cases where the transaction had been Authorised correctly but failed to capture? If so, the merchant would end up with lost income because the item is already sent.
4. Can we override the Authorise/Capture setting dynamically via a plugin? So set it to “Capture” by default, but when a custom plugin is active, change the setting to “Authorise”. Have you got a hook for this? Can this be done per transaction? For example only if the order is a Subscription?I don’t think that makes sense because as the merchant, you already know that you have set the Transaction Type to authorize therefore you know you should use the manual refund option.
Ideally, the back-end should always be self-explanatory and you should always assume that whoever uses it has just parachuted in the business and has zero experience at all. On growing and larger businesses, it is very common that changes are not communicated correctly and that can lead to issues. For example, you might have the setting to Authorise, but a developer decides to change it to Capture to test something or because it’s needed by a new feature. This change might not be communicated to Customer Services who deal with refunds. The CS staff might also be new to the business and unaware of the internals of the system, so their options should be limited and very clear to avoid mistakes. In the past, we had some CS staff hitting the “Refund manually” button because they thought that “Refund via Stripe” would take them to the Stripe dashboard for which they didn’t have an account. They had a valid point, but you can imagine the customer complaints this caused…
-
This reply was modified 3 years, 7 months ago by
George.
Hi there,
I don’t think that makes sense because as the merchant, you already know that you have set the Transaction Type to authorize therefore you know you should use the manual refund option.
Well that is true, and I know that now thanks to this helpful discussion, which has added considerably to what I learned from the documentation.
However I have to write the procedures manual for people to apply this, so the more intuitive the process, the easier it will be for people to pick up and remember. I don’t want to diminish from the many hugely more usable functions that your plugin has compared with others, and with the Authorising option, I now do at least have a partial refund process that isn’t a dealbreaker. But compared with all the other gateways/plugins I have used for refunds, the Braintree limitation has caused a dogs dinner here.
My procedures draft is as follows:
1. To finish off [Other Gateway] refunds, just press the button “Refund £XX via [Other Gateway]” and you are done.
2. To finish off Braintree, Paypal, Apple Pay and Google Pay refunds BEFORE the order is sent and marked Completed because PART of the order is being refunded, press “Refund £XX manually”. Note down the new amount that the customer is being charged. Then scroll up and click “Transaction Data / Actions”. Change the amount in the field to the new amount to charge the customer. Then press “Capture Charge”, and you are done.
3. For Braintree, Paypal, Apple Pay and Google Pay refunds BEFORE the order is sent and marked Completed because ALL of the order is being refunded, instead of selecting all the items for refund, select Order Status Cancelled and Update. This voids the whole order, and you are done.
4. To finish off Braintree, Paypal, Apple Pay and Google Pay refunds FROM THE DAY AFTER DISPATCH whether partial or complete, just press the button “Refund £XX via Braintree” and you are done.The difference between the process for the other gateway and Braintree is quite wide, with a lot of extra steps. I can’t be alone in needing partial refunds, so if anyone has a smoother process I’d be really interested. Despite the Braintree limitation, I think there are still opportunities for streamlining this.
One of them is to do with changing the amount in “Transaction Data / Actions”. Ideally pressing a Refund button in the Edit Order page would pre-empt most of step 2 above. It would change the amount to be captured on Completion.
Another thing as @subscriptiongroup suggested, is to have a more useful error message when trying to refund before settlment. The current one is a dead end that gives no clue that there is a voiding option via cancelling the order.
-
This reply was modified 3 years, 7 months ago by
tufty.
-
This reply was modified 3 years, 7 months ago by
- The topic ‘Refund issues’ is closed to new replies.