woocommerce-ios icon indicating copy to clipboard operation
woocommerce-ios copied to clipboard

[Woo POS] Improve error message when failing to check Order after a Payment Capture error

Open joshheald opened this issue 7 months ago • 1 comments

If we get an error from the call to capture_terminal_payment, and then repeated errors from the check calls to orders\{id} as added in #13165, then we show a generic error message.

In this scenario, which is most likely when they have a bad network connection, we need to be clear with the merchant that the payment status is unknown.

@joe-keenan has said that we should show it as an in-line error, with an additional modal popover to prompt the merchant to check the order.

They can acknowledge (let's not use Cancel for the button) the error and collect payment again – it's safest to do this, as it'll benefit from the order checks by using the same order.

There are risks both ways on this – if they handle it wrong, they could double charge, or undercharge, the shopper. We need to be clear in our messaging to minimise these risks.

We're already intercepting the error, refreshing the order, and showing "Payment successful" if find the order is actually paid. That should make it happen less often. But if we can't refresh the order (likely when there's a network connection issue) then we need to show an error in a way which makes it clear that they need to check whether the customer was charged or not... The risks we need to balance are: They assume the error means the customer wasn't charged, and make a new order to charge them again – but if the payment capture was successful, this means double charging the customer. We don't know either way. They think the error isn't relevant, e.g. because the card reader beeped acceptance of the card, and let the customer go. If the payment hadn't actually been captured, they would be undercharging the customer. (This is less likely, but could become a learnt behaviour.)

  • p1719559897287399/1718835247.409189-slack-C070SJRA8DP

Repro steps

  1. Set up Proxyman or Charles to intercept traffic for your test device
  2. Launch the app using a store eligible for IPP
  3. Navigate to Menu > Point of Sale mode
  4. Add an item to your basket and tap Checkout
  5. Enable breakpoints in your proxy for the response of POST requests to https://public-api.wordpress.com/rest/v1.1/jetpack-blogs/*/rest-api/ and the requests to GET https://public-api.wordpress.com/rest/v1.1/jetpack-blogs/*/rest-api/?json=true&path=/wc/v3/orders/*
  6. Tap your card on the reader
  7. Abort the capture_terminal_payment response and order requests when the breakpoints are hit (equivalent to poor network conditions meaning it was lost.)
  8. Observe that the payment shows a generic error – this is what we need to improve
  9. Cancel and try again – allow the requests through
  10. Observe that the "Payment success" screen is shown without needing to tap a card.

joshheald avatar Jun 28 '24 17:06 joshheald