Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
joshheald opened this issue Jun 28, 2024 · 1 comment · Fixed by #13215
Closed
Assignees
Labels
feature: POS type: task An internally driven task.

Comments

@joshheald
Copy link
Contributor

joshheald commented Jun 28, 2024

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.
@dangermattic
Copy link
Collaborator

dangermattic commented Jun 28, 2024

Thanks for reporting! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature: POS type: task An internally driven task.
Projects
None yet
3 participants