Re: [webpayments] How are payment instruments shared between different browser brands? (#15)

@mattsaxon How would a Merchant specify a payment app?

In the proposed architecture the payment app is registered and managed by the payer. The only way I imagine the merchant being involved in the payment app is by providing one of their own and incentivizing the payer to use this in preference to another.

**Example:**
* Payer has XYZ bank's payment app registered in their browser
* The app returns the PAN and expiry of a VISA card issued by XYZ bank in response to a payment request
* The app advertises its ability to support the "Legacy VISA" payment method which simply requires the app to respond with the clear PAN, expiry and CVV2 (it will prompt the user to enter the CVV2 when required)
* The merchant website (ABC Stores) sends a payment request in which it states that it supports two payment methods: "Legacy VISA" and "ABC Stores".
* The payment mediator knows that only one of these is supported by the installed apps so prompts the user to use the "Legacy VISA" payment app.

The merchant should incentivize the user to install/register the ABC Stores app for this to be available as an option.

Further, I propose that since the ABC Stores app may be tied to the same origin as the merchant website that the website will be able to probe (via the API) if that app is installed before initiating the payment request so they can tailor the user experience. (This requires that registered payment apps claim define their origin, perhaps in their manifest, or this is defined by the registration process - i.e. the origin of the site that registers the app is the origin that can probe for it).

If the user installs the ABC Stores app they may then store their XYZ Bank issued VISA card details via that app (these would probably be stored by ABC Stores PSP and a token held in the payment app). In this way the payer can use the same payment instrument (their XYZ VISA card) but with two different payment apps. The ABC Stores app is unlikely to be supported anywhere else but can be used by ABC Stores to offer different pricing, track loyalty spend etc.

To take this one step further, ABC Stores' PSP (let's call them Bob's Pay) could offer a white-label payment app that is usable at many merchants (who all use Bob's Pay). This could be done as a single app that renders/behaves uniquely depending on where it is being used (the user would be aware that they have installed the Bob's Pay payment app) or Bob's Pay could register a separate app per merchant and the fact that this is being facilitated by Bob's Pay is invisible to the user unless they observe the origin of the payment app. Either way, Bob's Pay could handle the tokenisation of the card once and store the same token in the one or many payment apps used by the user so they never have to enter their card details and the merchant is out of PCI DSS scope.

The fact that the ABC Stores/Bob's Pay app support tokenisation means they would likely advertise that they support some new payment methods like "Tokenised Visa Card" (if there is a standard established for this) or "Bob's Pay Visa Card". This payment method would not send the clear PAN anymore but rather send the token in the format defined by the payment method.

If the Bob's Pay app has to perform a "Legacy Visa" payment it needs to send the clear PAN and expiry so it would need to use the token it has stored to fetch the clear data from Bob's Pay on demand and this would use some system that Bob's Pay deem secure enough for them to still be PCI DSS compliant.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/15#issuecomment-162527538