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

Hi @rsolomakhin, thanks for the suggestions!

Using feature detection with an opt in control seems like a good idea and would certainly work for our use case.  Most likely our strategy in that case would be to use the improved errors if available, and if not fall back to our existing implementation. That way, we would have better future-proofing, since we wouldn’t be relying on string matching moving forward, but we’d still be compatible with browsers that haven’t implemented the new error code.

Differentiating between the two error classes also seems like the right choice moving forward, and we’d hope to see it become the default behavior in the future, but getting there without breaking existing integrations is tricky.

Our overall strategy for the PayPal JS SDK is to support a minimum of Chrome 69, but we have the ability to facilitate payment through other flows (e.g. opening a popup) if PaymentRequest isn’t recommended in older browsers. Exposing something like a PaymentRequest spec version could potentially help us with that, and with feature detection in general, although I’m not sure how feasible that is. We aren’t always able to determine browser version reliably with user agent checks, since some of our merchants consider it to be PII.

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

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