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

@dtjones404 - A couple of questions for you:

1. Consider websites that check only for the error codes currently defined in the spec: `AbortError`, `SecurityError`, `RangeError`, `InvalidStateError`, `NotSupportedError`, and `NotAllowedError`. What will happen when a new error code is returned? Is there a way to make this transition smoother?
2. Consider different release cycles and cadences for different browsers: What if Safari ships the new error code a few months before Chrome or vice versa?
3. Consider supporting older browser versions* during the transition period - some newer browsers will have the new error code, while some older one's won't.
4. Consider how browsers gradually roll out features. For example, Chrome may enable new error codes for 1% of users to observe metrics. Then user agent version check would not work.

Some thoughts off the cuff:

1. Feature detection: Add a static method `PaymentRequest.isErrorCodeSupported(errorCode)`?
1. Feature control: Introduce `enableOperationErrorCode: true` boolean parameter to the `new PaymentRequest()` constructor?

* - Speaking of older browser versions, (this is totally unrelated to the topic at hand, so -- my apologies!) your code example mentions `Chrome <= 76`, which released quite a while ago. Older browser versions tend to have known vulnerabilities that are patched up in the newer versions. Do you consider this an increased risk for payments? How long do you support old versions? 

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

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