- From: Zach Koch <notifications@github.com>
- Date: Wed, 24 Feb 2016 09:37:13 -0800
- To: WICG/paymentrequest <paymentrequest@noreply.github.com>
- Cc: webpayments <public-payments-wg@w3.org>
Received on Wednesday, 24 February 2016 17:37:44 UTC
So I think the real problem we're driving at is this: registered payment apps should be able to support payment methods independent of their own `identifying_url`. For example, BobPay should be able to support BobPay payments as well as the ability to return back a normal PAN. In principle, I agree. Here's the problem I'm looking for help solving with registration: A payment app registering with the ability to **support** a particular payment method does **not** mean the user using that payment app has that particular payment method available. As an example: A merchant supports Visa and MC only. A user then registers AliceWallet, which support Visa and MC, but the user only has an AMEX card inside of AliceWallet. In my opinion, AliceWallet should not be presented as a payment option because the user doesn't currently have any payment methods inside of AliceWallet that intersect with the set of supported instruments from the merchant, i.e. Visa and MC. Open to suggestions on how to solve this problem. --- Reply to this email directly or view it on GitHub: https://github.com/WICG/paymentrequest/issues/66#issuecomment-188371056
Received on Wednesday, 24 February 2016 17:37:44 UTC