How are payment apps shared between different browser brands?

[msporny]

In Phase I, when a user registers a new payment instrument, how is that payment instrument shared between different browser brands? For example, if I register a Visa debit card issued by my bank in Google Chrome on my laptop, when I go to purchase something using my mobile phone, is that same debit card available to me via my Firefox web browser (assuming I've authenticated in some way with both browsers)?

How would this change in Phase II or beyond?

[msporny]

There are a variety of choices here, in order of easiest to implement to hardest to implement:

1. There is no sharing mechanism
2. There is a unified payment instrument export mechanism
3. There is a storage and discovery mechanism that all browsers use to import data from other browsers

I assert that the last bullet point is what we should strive for, but we may need to take baby steps to get there. In any case, we should implement the API as if the third item existed and figure out a way to polyfill our way there.

[mattsaxon]

Agreed, though this needs to be available beyond just browsers, other Payment Apps might want to import these.

[mountainhippo]

If a mechanism is to exist for sharing payment instruments between payment
applications for given user, that must be explicitly permissioned by the
owner entity (user).

There may be good reason for one payment instrument to be provisioned into
one payment application and a different instrument into a second
application.

TBH any sharing between payment applications feels beyond the scope of a v1
implementation

Nick

Nick Telford-Reed
e: nicktr@gmail.com
m: +447538177619
On 2 Dec 2015 12:43 p.m., "mattsaxon" notifications@github.com wrote:

Agreed, though this needs to be available beyond just browsers, other
Payment Apps might want to import these.

—
Reply to this email directly or view it on GitHub
#15 (comment).

[dlongley]

I assert that the last bullet point is what we should strive for, but we may need to take baby steps to get there. In any case, we should implement the API as if the third item existed and figure out a way to polyfill our way there.

+1

We need to ensure very early that we can get to where we eventually want to go even if we elect to take baby steps to get there.

[ianbjacobs]

Regarding NickTR's point, I think there are two scenarios to consider:

• I want to register my Payment Apps once and have all my other software (N browsers, for example) know about them.
• I may have N Payment Apps that all have access to my same payment method data. For example, I have a Visa card that a Visa app might contain, but my bank's app might also contain. I might choose one app for one reason (e.g., points) and another app for another reason (e.g., mobile banking).

I mention this second use case in passing, but I think the first use case is the subject of this issue.

Ian

[mattsaxon]

Ian, the second case is also relevant to me. The scenario that I am most interested in is where a wallet holds a credit card number in its own internal form and is used to passing this to the merchant unencrypted. I believe that we would wish to have a Payment App intercept this and tokenise or encrypt it before passing it to the merchant.

[ianbjacobs]

Matt,

For the second case ("data shared by N payment apps") how should we document that use case? (Flow? Spec?)

For the case you cite ("intercept and tokenise/encrypt"), let's flesh out the ecosystem a bit. I assume Payment Apps will offer different features (e.g., this one tokenises, this one does not, etc.). Then we have some options:

• Payment Apps do not interact at all.
• Payment Apps can be pipelined (one-way communication).
• Payment Apps can communicate with each other in more interesting ways.
• The Browser-As-Payment-App is special and so even if other Payment Apps do not interact, the
  Browser can act on the output of other Payment Apps.

(Of course, there may be contexts where we have no control over the communication among different pieces of software. Here I am talking about what we want or anticipate rather than what we can't control.)

So it sounds to me like you would either want to the second or fourth option, so that if Payment App A is about to return a plain text PAN, you can have another Payment App step in and tokenise the result before the browser ships it to the merchant.

Thoughts?

Ian

[mattsaxon]

The only use cases I've identified so far is where you need 2 Payment Applications, one chosen by the Payer using the process we've been talking about from the start (of the WG) and a second one which would be specified by the Merchant. So effectively I'm talking of a max of 2 Payment Applications which are pipelined. So yes this is covered under your option 2, though I've restricted it further by saying one is client registered as per our usual process and the other is merchant specified, so probably on demand with no user intervention. I don't think option 4 cuts it because a 3rd party wallet might throw up the non tokenised PAN, though it is fair to say that usually there isn't such a 3rd party and we are talking about the browsers form-filler.

[adrianhopebailie]

@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.

[adrianhopebailie]

I have renamed this thread to use the "payment app" terminology.

This thread strayed away from the core question and raises another about the need for payees to have control over the payment app that is used or the idea of having a "payee app".

@ianbjacobs and @mattsaxon - perhaps that is something you want to raise in another question?

[dlongley]

I have renamed this thread to use the "payment app" terminology.

This is similar to another payment instrument issue (#16) where the rename isn't necessarily 1:1. We may want two separate issues: one for sharing payment apps across different browser brands and one for sharing payment instruments across different payment apps.

[adrianhopebailie]

Based on the way the thread was discussed (specifically called out in @ianbjacobs comment on 3 Dec) this thread felt like an app discussion. If there is still a discussion to be had about payment instruments I agree that we should open another thread.

[msporny]

Migrated to w3c/payment-request#38