Forum Replies Created

Viewing 15 replies - 31 through 45 (of 45 total)
  • Hi @mrclayton!

    Well, for me it was unexpected behaviour that once I had set the order to the partially refunded status, and then went to capture it correspondingly, when I came back to the order it had changed. Obviously, one wants the amount captured to correspond to the net sale amount in WC.

    In your example that seems to assume no change in the order itself. And in that case, yes, it makes sense to adjust the order total to match the captured amount. But I think that is less likely as a workflow because most stores will want the order to show an audit trail of what happened, as well as simultaneously putting items back into stock.

    There are lots of ways to skin the proverbial cat here, starting with probably the least work:

    1. Introduce a dialog at the point of manual capture so that if the amount captured is different to the order total, net of any manual refund, then the user can choose to create another adustment within the order, so that the amounts match. If the amounts already match, then just capture…

    Order total: $50
    Authorized Amount: $50
    “Refund” requested $10 for product or shipping not wanted
    New Order total $40
    Manual Captured Total: $40

    2. The most seamless experience I can think of, given what I understand of the Braintree framework, is to change the behaviour of the refund, so that if the order is authorized, not captured, the button for “Refund $10 via Braintree XXX Gateway” saves a new lower value for the capture amount that will be used later when the order is marked complete and captured automatically.

    Thanks.

    Rather belatedly, I have found another problem with this, which makes manual partial refunds quite difficult, and explains why our bookkeeper has been having trouble reconciling.

    Just now, we were asked to refund postage as the customer made two orders that can be merged. So I did a manual partial refund of the postage, and captured the new total. I happened to look at the order afterwards, and it seems the act of capturing also changed the order total a second time, and the new amount paid was shown as the amount captured, less the manual refund, not the original amount, less the refund.

    I was able to put this right by editing the order manually, after putting it into Processing status. I don’t really like doing this, as it sends another email to the customer when it goes back to Processing. For postage, it would have been easier to have done a manual edit instead of a manual refund and then a manual edit. But that would not work for products which need to be put back into stock and the correct batch.

    This is a great plugin in so many ways, but I’m afraid that because of these issues, we only have this plugin active for Apple Pay, for which we have no other option. We use another gateway for cards and Paypal.

    Many thanks for that tweak to the refund error message in the latest update! I imagine that will save a bit of confusion to some people.

    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.

    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?

    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.

    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.

    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.

    Thread Starter tufty

    (@tufty)

    Hello there,

    I’ve done some more investigations on staging. The issue is not isolated to Yoast. It is also not related to caching, as it occurs with all caching off. But the good news is that it is not hugely serious. By refreshing the blank page 5-6 times it eventually comes back. I think it is memory related.

    Thread Starter tufty

    (@tufty)

    Dang. It turned out to be “Remove query strings from static resources” that was causing it. I was not expecting that.

    Thanks!

    Enable jQuery Migrate Helper did not work immediately for me.

    So I downgraded to WP 5.4.2. SU still failed to work. So I disabled it and re-enabled. Then it worked. Phew.

    Then I backed up again, re-enabled Enable jQuery Migrate Helper, upgraded to WP 5.5 and SU was still working.

    If I was going to try again, I would have stayed on WP 5.5, installed Enable jQuery Migrate Helper, disabled and then re-enabled SU. I’m guessing that would work.

    Thread Starter tufty

    (@tufty)

    Thank you. I understand that. This is really an issue with plugin providers who run their support outside wp dot org. There are quite a few of them. Most of the official Woocommerce plugin providers, and many others. The reason I came here is not because I need support here but because I really think this is a wider issue that should properly be dealt with in WP core.

    If I can anonymize a staging copy of my site, plugin providers can see much more quickly what the issue is. And the options for engaging a developer are much better.

    Most plugin developers are understanding about the problem and do their best without access. Only one (Elementor) actually refused to support me if I din’t give access to the site.

    Thread Starter tufty

    (@tufty)

    Hi David,

    No. It’s not too difficult to itemise gross sales to different countries and pick out countries that are non-UK-EU (although that’s not exactly automated) but the VAT return wants net data, which the report simply doesn’t do.

    We sell a mixture of standard and zero rated goods mostly to the UK, but also to a multitude of EU and non-EU Europe, including the Channel Islands, so we can’t just take the VAT off.

    There’s another function that stores selling physical goods round Europe need in relation to VAT, and that’s a simple way of setting up sales VAT. I’ve only just discovered that there’s a setting to make shipping VAT dependent on the contents of the basket. That’s a help for a tiny part of the issue.

    As I understand VAT rules on shipping, the vat status of the delivery charge follows the VAT status of the goods being shipped. https://www.gov.uk/guidance/vat-on-postage-delivery-and-direct-marketing-notice-70024#delivered-goods

    WC follows this but only in a binary way. In other words, it does not vary the VAT between standard and zero based on the average rate in the order, which I think it probably should. It just uses the highest rate in the order. Minor issue.

    But I’m really struggling to set up things so that VAT-inclusive prices in the store have VAT removed in the cart if the shipping address is in a non-VAT area like the Channel Islands. It must be possible, and many people must have the same issue.

    Thread Starter tufty

    (@tufty)

    Sorry, I should be clearer about this. The plugin works well on the register page and reset page, because the register/reset button changes to allow progress. But on the Checkout page, the messages are confusing because eg on the setting 2, it says “Password Strength: Weak – Please enter a stronger password.” Then it changes to “Password Strength: Weak” which implies that it is still too weak, and there is no other change of status to suggest it is adequate to proceed.

    If we could put in a message at that point like: “A stronger password is advised but not compulsory” Then that would help hugely. It could be used when level 1 or 2 thresholds are selected and if the password itself is below level 3.

    Many thanks.

    As I understand it, WP Rollback only rolls back plugins that are on www.ads-software.com. Since I have a fair few that are not, it would be a very incomplete solution for me.

    I rolled back using Beyond Compare (not affiliated, but a paying customer for 13 years). I get it to mirror the web server file structure locally with sftp, before updating. And if something goes wrong, I get it to sync back that folder. And it just worked. No need even to activate.

Viewing 15 replies - 31 through 45 (of 45 total)