Re: [w3c/browser-payment-api] Should we define nesting/grouping semantics for payment method identifier matching? (#30)

I was relayed on an example by Jean-Vves about a certain card sub brand that charges 7% interest rate and is designed for purchase of high end goods.

Another example is the acceptance on the Discover network for UnionPay credit cards. A merchant may not want to be able to decline those even though the network can accept, e.g. Because of different Ts&Cs.

An alternative is to simply decline the card at the acquirer. This decline approach demonstrates the need for some more refined return codes rather than just success, failure, pending etc. That have been said used, perhaps a failure reason with an enumeration of reasons.

Lastly. I prefer the grouping semantics, though I do appreciate the challenge of modelling this. However grouping might still benefit from a 'not supported' approach so you can say, I accept all Visa cards apart from electron.

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