Enables payment handlers that are accessed via the Payment Request API to return distinct errors for "user cancelled" vs "internal payment app error". This allows web developers to build better flows for users, e.g. by retrying or falling back to a different flow when an internal app error occurs, whilst properly stopping the flow if the user wants to cancel. The Web-based Payment Handler API can indicate this difference based on what error they use to reject the promised passed to PaymentRequestEvent.respondWith. If the promise is rejected with an OperationError, then "internal app error" (OperationError) is returned to the merchant via the PaymentRequest.show(), otherwise "user cancel" (AbortError) is returned. Native app payment handler infrastructure is similarly updated, but is out of scope for web APIs.
Currently, when PaymentRequest.show() is rejected due to an error in the underlying payment handler app, the only possible outcome is AbortError. This makes it difficult for payment apps using Payment Request to build good user flows, as it is difficult to differentiate between "call failed because user cancelled out of the payment app" and "call failed because the app had an internal error".
Explainers: https://github.com/w3c/payment-request/issues/1040