Re: [w3c/payment-request] Improved error codes (Issue #1040)

stephenmcgruer left a comment (w3c/payment-request#1040)

The `show()` algorithm returns a promise that can ultimately be resolved/rejected in the following cases. I *think* this list is exhaustive, but I may have missed some!

1. Step 2.1. of the `show()` algorithm, if user activation is not present and the user agent wishes to enforce that it be required. The promise is rejected with a `SecurityError`.
1. Step 5 of the `show()` algorithm, if the document is not fully active. The promise is rejected with an `AbortError`. 
1. Step 6 of the `show()` algorithm, if the document is not visible. The promise is rejected with an `AbortError`. 
1. Step 7 of the `show()` algorithm, if the user agent wishes to enforce an implementation-specific security requirement of some sort (e.g., a rate limit). The promise is rejected with a `SecurityError`. 
1. Step 8 of the `show()` algorithm, if `request.[[state]]` is not "created" (I think this means that `show()` was called twice). The promise is rejected with an `InvalidStateError`.
1. Step 9 of the `show()` algorithm, if another PaymentRequest is already showing in this browser context. The promise is rejected with an `AbortError`.
1. Step 13.1 of the `show()` algorithm, if the user agents wishes to preserve privacy or other reasons. The promise is rejected with an `AbortError`.
1. Step 17.4.2 of the `show()` algorithm, if conversion of the serialized payment method data fails. The error is implementation-specific to the particular payment method.
1. Step 18.2 of the `show()` algorithm, if no handler exists that can handle the request. The promise is rejected with a `NotSupportedError`.
1. Step 7.3 of the `abort()` algorithm, which is called *by the site* to abort an ongoing PaymentRequest (if possible). The promise is rejected with an `AbortError`.
1. Step 17 of the **User accepts the payment request algorithm**. The promise is resolved with the `PaymentResponse`.
1. Step 8 of the **User aborts the payment request algorithm**. The promise is rejected with an `AbortError`. 
1. Step 3.5 of the **abort the update* algorithm. This algorithm is called in various error states when parsing the details provided to `show()` or to any of the various 'update' algorithms that can happen between site and payment app while it is invoked. The promise is rejected with an `AbortError`.

----

So, it looks to me like there just isn't the concept today of "an error occured within the payment handler". Is that statement accurate to your knowledge, @marcoscaceres ? Are payment handlers meant to communicate that via the `PaymentResponse` in a method-specific way, or is this just an oversight in the spec?

Separately from this btw, we would need to look at Payment Handler for web payment handlers and define a way for web Payment Handlers to indicate an internal error.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/1040#issuecomment-3521053292
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/payment-request/issues/1040/3521053292@github.com>