You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
Set up Proxyman or Charles to intercept traffic for your test device
Launch the app using a store eligible for IPP
Navigate to Menu > Point of Sale mode
Add an item to your basket and tap Checkout
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 GEThttps://public-api.wordpress.com/rest/v1.1/jetpack-blogs/*/rest-api/?json=true&path=/wc/v3/orders/*
Tap your card on the reader
Abort the capture_terminal_payment response and order requests when the breakpoints are hit (equivalent to poor network conditions meaning it was lost.)
Observe that the payment shows a generic error – this is what we need to improve
Cancel and try again – allow the requests through
Observe that the "Payment success" screen is shown without needing to tap a card.
The text was updated successfully, but these errors were encountered:
If we get an error from the call to
capture_terminal_payment
, and then repeated errors from the check calls toorders\{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.
Repro steps
Menu > Point of Sale mode
Checkout
POST
requests tohttps://public-api.wordpress.com/rest/v1.1/jetpack-blogs/*/rest-api/
and the requests toGET
https://public-api.wordpress.com/rest/v1.1/jetpack-blogs/*/rest-api/?json=true&path=/wc/v3/orders/*
capture_terminal_payment
response andorder
requests when the breakpoints are hit (equivalent to poor network conditions meaning it was lost.)The text was updated successfully, but these errors were encountered: