- From: Stephen McGruer <notifications@github.com>
- Date: Mon, 23 Feb 2026 06:51:30 -0800
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 23 February 2026 14:51:34 UTC
stephenmcgruer left a comment (w3c/payment-request#1040) Realized that it's not covered in this issue, so recording that we have heard desire for this from another Payment Handler active in Chrome today. They have cases today where due to mis-configuration or bugs (nobody's code is perfect!) they find that after being invoked by `show()` they cannot handle the transaction. Today their only choice in the API is to send back what maps to an `AbortError` as above, but this then carries the connotation of "user aborted the payment" to the merchant level, which *isn't* what happened! The user wants to pay, there's just an error with this specific payment app and so the merchant should be able to offer the user a different choice (and clearer communication). So just to note that it's not just a use-case for our friends from PayPal who filed this, but also for existing Payment Handlers in the wild :) -- Reply to this email directly or view it on GitHub: https://github.com/w3c/payment-request/issues/1040#issuecomment-3945216462 You are receiving this because you are subscribed to this thread. Message ID: <w3c/payment-request/issues/1040/3945216462@github.com>
Received on Monday, 23 February 2026 14:51:34 UTC