@adamroach I think we are tending toward something like what @mattsaxon pointed to and much much more. This is only limited to card payments and there are already too many to justify needing to explicitly name them all. Consider that third party payment apps will allow payments on this API that are completely outside the current payment ecosystem and may have semantics we can't even consider today. The set of PMIs and the way they are used by payment methods is going to explode (a good thing) and our matching algorithm should allow for this not restrict it. Right now we have ignored the fact that payment methods may want to allow apps and merchants to define what currencies they can transact in (card networks deal with this out of band or through DCC). So if I have http://hopebailie.com/adrianpay/USD do I need a separate PMI for all of the currencies I support (http://hopebailie.com/adrianpay/EUR etc)? As soon as I have more than 2 or 3 sub-classes the number of PMI's grows exponentially. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/w3c/browser-payment-api/issues/30#issuecomment-222006698
Received on Thursday, 26 May 2016 21:57:11 UTC