-
Notifications
You must be signed in to change notification settings - Fork 135
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
Fine-grained error reporting with canMakePayment() #847
Comments
After thinking about this more, let's not add this state for Personally, I would be OK to not add this feature to
After version 1 is finished, let's discuss a
Let's recommend to be specific with error messages without requiring all browsers to use the same error message text. The error codes (e.g., AbortError) are normative, but the error messages (e.g., "Request cancelled") are informative.
Agreed. |
👍
👍 It's not clear to me what merchants would do with the extra granularity. hasEnrolledInstrument() returning false should not be a reason to not call show() so long as canMakePayment() returns true. Handlers can choose to offer instrument enrollment as part of their payment flow or just reject the call to show(), which as you point out offers the same information.
FWIW, WebKit throws an InvalidAccessError in the PaymentRequest constructor if a non-root certificate in the chain is signed with SHA1. I don't think we reject on self-signed certificates, but maybe I'm misreading the code (and maybe we should in a way that doesn't break our testing). We could start here (after v1) by agreeing on what exception to throw, when to throw it, and under what circumstances (and then maybe add a new method if we still think we need it).
👍 If we really need to be programmatically granular, I guess we can use different error codes.
👍 |
I am creating this issue based on discussion on issue #843.
I am hearing several use cases for fine-grained error reporting when canMakePayment() returns false:
An error message (e.g., "okToUseAPI") that indicates that the user does not want to share detailed information but would like to use the API under show() conditions would reveal some information about the user's browser configuration.
Errors in SSL. For example, self-signed SSL causes Chrome to always return "false" to canMakePayment() and reject show() with "AbortError: Request cancelled."
Reasons why the payment sheet closed, e.g., "AbortError: User closed the payment handler", "AbortError: The payment handler cancelled the transaction", or "AbortError: User closed the card CVV entry form."
I propose that we take up these use cases after version 1.
The text was updated successfully, but these errors were encountered: