Abstract payment architecture

[msporny]

This issue is being created to track the abstract payment architecture wiki pages outlined here:

https://github.com/w3c/webpayments/wiki/A-Payments-Initiation-Architecture-for-the-Web https://github.com/w3c/webpayments/wiki/Components

[msporny]

Hey Adrian, I think you've successfully generalized the components necessary for a functioning payment system. A few thoughts on how to improve the presentation (as I haven't yet had enough time to form any opinions on the components).

While reading through the document, I found it difficult to figure out how everything fits together. Leading on the https://github.com/w3c/webpayments/wiki/Components page with an image and brief summary of the components would have been helpful. There are two ways you could do this that I can think of:

1. Show the image of all the components and what talks to what. Have a table below with brief 1-2 sentence descriptions of what each component does.
2. Show a simple credit card purchase flow with all of the components. Have a table below with a brief 1-2 sentence description and what each component is doing in the flow described above.

I think doing that might help people understand how all the components play with one another first, and then you can dive into what each component does below there.

[adrianhopebailie]

While reading through the document, I found it difficult to figure out how everything fits together. Leading on the https://github.com/w3c/webpayments/wiki/Components page with an image and brief summary of the components would have been helpful.

I have moved the diagram to the top of the Components page

Show a simple credit card purchase flow with all of the components. Have a table below with a brief 1-2 sentence description and what each component is doing in the flow described above.

My plan is to show these components arranged in various different deployment and implementation scenarios (note the links in the sidebar that have no target yet) which should help to explain how they fit together.

[adrianhopebailie]

I have added 3 deployment examples to clarify how the components would fit together:

• All in the Browser
• Browser with remote Payment Apps
• Mobile platform

Still planning to add a Web of Things example

[dlongley]

Regarding: https://github.com/w3c/webpayments/wiki/All-in-the-Browser

If we're considering "installing" Payment Apps as ServiceWorkers (or something similar), we should consider how to handle the case that a new browser or device is being used. If a payer's Payment Apps can be discovered via some external service, then a discovery request could be issued that results in Payment App manifests. Those manifests could include a URL that could be used to perform the installation on demand.

[dlongley]

We'll want a clear path forward for public terminal use as well.

[dlongley]

I'm concerned we're not considering the Rule of Least Power by making payment instruments into applications. Perhaps we're not because of their related "manifests", but we'll have to be clear about what is in them. If we strongly tie payment instruments to applications (or model them as such), we're limiting their use.

There seem to be some other potential problems, for example, how does one authenticate with a Payment App? If you're using some kind of credit card, for example, is the information necessary to authenticate included in the manifest for the Payment App? Where is that information located? When you go to a site to install a Payment App -- do you have to enter the information there? Is it then stored in the manifest that is associated with you/your browser? (By the way, is the information user-centric and associated with you or is it associated only with a particular browser?)

If the information is integrated with the Payment App and not present in the manifest, and you have to install a Payment App in a new browser, do you have to re-register the information associated with the app?

[LaurentCastillo]

Hey Adrian,

A few random remarks/questions: 1/ The examples definitely help. I think the "Browser with remote Payment Apps" and "Mobile platform" are the most two common cases considered and should be first.

2/ Love the renaming of the components. We might be missing one type of component that describes the various sources (and destination) of funds in a single payment method. Payment Account could work? For instance, for bitcoin payment method, that would be bitcoin addresses, for Visa payment method, that would be credit card numbers.

3/ What's the impact of describing methods through a manifest? In particular, is it easy to add a new payment method / account after install if we use manifests?

[mattsaxon]

I think there may be examples where the Payment App may be provided by the Payee's PSP, so wouldn't want to have the "(usually provided by the Payer's PSP)" in the definition.

[mattsaxon]

Can we make it explicit in the architecture if there may be multiple Payment Mediators involved in particular payment interaction or is it expected that there can be only one? Previously when we discussed these as 'wallets' there was an idea of nested wallets - does this apply or has the redefinition changed this?

[adrianhopebailie]

I think there may be examples where the Payment App may be provided by the Payee's PSP, so wouldn't want to have the "(usually provided by the Payer's PSP)" in the definition.

The only situation I see this happening is if the payer and payee are using the same PSP. e.g. The Payment App is from PayPal and the merchant is using PayPal as their PSP. Are there use cases I am not thinking of?

[adrianhopebailie]

Can we make it explicit in the architecture if there may be multiple Payment Mediators involved in particular payment interaction

What I'm proposing is a single mediator otherwise you need a mediator to pick the mediator. It's entirely possible that some implementations will make this a "pluggable" component or even allow this to be hosted remotely but I'd still expect there to only ever be one active mediator for a payment.

[mattsaxon]

What I'm proposing is a single mediator otherwise you need a mediator to pick the mediator. It's entirely possible that some implementations will make this a "pluggable" component or even allow this to be hosted remotely but I'd still expect there to only ever be one active mediator for a payment.

Thanks Adrian, that is as I had expected.

[mattsaxon]

The only situation I see this happening is if the payer and payee are using the same PSP. e.g. The Payment App is from PayPal and the merchant is using PayPal as their PSP. Are there use cases I am not thinking of?

There are 2 use cases commonly used today, both of these have regard to the protection of sensitive card information as it passes through the merchant to the acquirer. The two uses cases are encryption or tokenisation, Both of these need Merchant PSP specific processing prior to the card details being send to the merchant. The Payer is not aware that this is happening currently and it is principally a solution to reduce risk at the merchant. There is a case in my mind for making this added layer of security visible to the user however.

It is my view that supporting this type of interaction is necessary for our specification to be adopted.

Furthermore supporting it explicitly somehow in the flow would allow the User-Agent to flag to the user that their card details cannot be intercepted by the merchant.

I've documented these flows on GitHub, once of them can be seen here https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/Card/MerchantHosted-CardPaymentwithTokenisation-Current.pml

[adrianhopebailie]

@mattsaxon

I think these additional requirements would be encapsulated in different payment methods. (This is one of the main reasons I am advocating for the term "payment method" as opposed to "payment scheme")

One of the key benefits of this API is that new payment methods could be introduced without a user even being aware.

As an example, a bank may publish a payment app which allows their users to pay using their bank issued cards. As such the app may advertise that it supports a payment method called "Legacy Visa Credit" or similar.

As time goes by the industry may standardize on a better way to do card payments that includes tokenisation or similar. This new method would need to be supported by both the app and the PSP's of the merchants where the user uses the app as it's likely the message schema for the request and response messages will have changed.

If the app supports this new payment method it can add it to its list of supported payment methods and going forward when the user uses that app with a merchant PSP that supports the new payment method that's the method that will be used (invisible to the user).

[mattsaxon]

The approach you outline would reduce the ability for the Payment Processors (Merchant PSPs) to innovate independently of the issuers which is a key part of the existing ecosystem.

[dlongley]

The approach you outline would reduce the ability for the Payment Processors (Merchant PSPs) to innovate independently of the issuers which is a key part of the existing ecosystem.

This is also related to #31.

[webpayments]

Hello guys,

In hopes I don’t repeat things others said or contradict others that have already been decided upon when I wasn’t there. (There’s just too much information floating around for me to follow properly besides my daily job…) But I think we are touching a few important points which I feel we have some experience with, which might differ…

· While I still oppose the term ‘payment app’ at all, I have the feeling it is used ambiguously: Is it

o an app with a UI which the user is aware of and being issued by e.g. a bank or

o an implementation of the payment mechanism/ scheme (e.g. ‘MasterCard PayPass’)

· While I’d strongly object to introduce the first interpretation, I’d reconfirm that the latter one needs to be around in our architecture anyway. This is, how VISA/ MC are working when their applet is installed into a Secure Element. They can be controlled (in a very limited way) via an authorized app on the device. (Which could be a wallet or - a more abstract - mediator)

· Something a user might recognize as a ‘payment instrument’ would be e.g. a profile within such an applet, saying that this is my GoodBank VISA. (Just one of the three VISA cards the user might have among their payment instruments. Alongside with my Company VISA and a complimentary Purple Status VISA from the MoreMiles loyalty system.)

Whether the implementation sits on some piece of hardware, on the device or in the network – the user needs a representation of the ‘payment instrument’ which allows her/ him to handle it and which is technically referring to an implementation, likely passing on some parameters to allow the same implementation to serve several instruments, pseudonyms, cards – or whatever you’d like to use for visualization.

Would ‘Payment implementation’ be a better word than ‘payment app’?

Cheers, Jörg

From: Adrian Hope-Bailie [mailto:notifications@github.com] Sent: Mittwoch, 9. Dezember 2015 12:24 To: w3c/webpayments Subject: Re: [webpayments] Abstract payment architecture (#11)

@mattsaxonhttps://github.com/mattsaxon

I think these additional requirements would be encapsulated in different payment methods. (This is one of the main reasons I am advocating for the term "payment method" as opposed to "payment scheme")

One of the key benefits of this API is that new payment methods could be introduced without a user even being aware.

As an example, a bank may publish a payment app which allows their users to pay using their bank issued cards. As such the app may advertise that it supports a payment method called "Legacy Visa Credit" or similar.

As time goes by the industry may standardize on a better way to do card payments that includes tokenisation or similar. This new method would need to be supported by both the app and the PSP's of the merchants where the user uses the app as it's likely the message schema for the request and response messages will have changed.

If the app supports this new payment method it can add it to its list of supported payment methods and going forward when the user uses that app with a merchant PSP that supports the new payment method that's the method that will be used (invisible to the user).

— Reply to this email directly or view it on GitHubhttps://github.com/w3c/webpayments/issues/11#issuecomment-163193061.

[ianbjacobs]

@mattsaxon

The approach you outline would reduce the ability for the Payment Processors (Merchant PSPs) to >innovate independently of the issuers which is a key part of the existing ecosystem.

I am not sure to understand why that would be the case. Can you explain in more detail?

Ian

[adrianhopebailie]

@mattsaxon

The approach you outline would reduce the ability for the Payment Processors (Merchant PSPs) to innovate independently of the issuers which is a key part of the existing ecosystem.

I disagree. In fact I'd say that this opens up the ecosystem for far more innovation from both issuers and PSPs.

There is absolutely no barrier to publishing a payment app (as opposed to the ability to issue payment instruments today). In this ecosystem PSPs could both process payments on behalf of payees and also publish payment apps.

Today only a small number of PSPs (eg: PayPal, Braintree) have the scale and reach to provide both the payer and payee components of online payments. In future any PSP that is capable of processing payments using a particular payment instrument can encapsulate that instrument in their own app. The app can support one or more of the standard payment methods for that payment instrument but also add proprietary methods that extend those standard methods with custom data that can be exchanged when the payer uses their app at merchant sites for whom they are also the PSP.

[dlongley]

@adrianhopebailie,

Note: You might want to skip to my next comment and then come back.

I'm not convinced our abstraction is being done in the right place. I'm not totally opposed either, but it feels like the modeling isn't quite right. It is a departure from the existing ecosystem -- where issuers give people instruments which they can then use with a variety of different processors. Whether or not that's a good idea can be debated. I do think, without some changes, we're potentially missing an opportunity to make it easier for payment app developers to get access to payment instruments in a standard way.

If we define an API to register payment instruments and pass those to payment apps during payment, then payment apps are no longer required to implement N different ways to get a user's payment instruments into their app. If we loosely couple payment instruments and payment apps, then we make it possible for payment app creators to innovate independently from payment instrument issuers and we can have a simple standard (basic) format for providing the instrument information to an app. From a user perspective, it would be nice to only have to register instruments once -- and then be able to swap out which apps to use to pay with them. There's also a certain amount of "payment app lock in" that may occur if we don't decouple.

With loose coupling, users can acquire payment instruments from issuers and then independently change the payment app associated with that instrument as they discover new or more interesting payment apps that support the instrument's scheme. This does not disable entities that want a tighter coupling from operating, it just enables more pathways for innovation and user choice.

I do see another abstraction layer on top of payment instruments being useful, but not necessarily as a hiding of payment instruments as a detail of payment apps. Rather, I see that we could create "keys" to payment apps where these keys are what users select when making a payment rather than selecting a payment instrument or a payment app. A key always links to a payment app, but it may also contain payment instrument information that makes it possible to change its link to another compatible payment app.

So here "key" a doubles as a payment app selection device and something can be potentially used by that app to make a payment. For example, a key may be a Visa card or a bitcoin private key, or it may be a "Bob Pay Key" that will only work with the "Bob Pay" app. Some issuers will create keys such that they only work with their app (the issuer is the app creator). But other issuers will want to issue keys that can be used by a variety of different payment apps.

In either case, when a payment request arrives, the user will be presented a list of their keys that match the available schemes. A key may be a Visa credit card that they have associated with their currently favorite payment app for processing Visa cards or a key may be a "Bob Pay Key". The former can be edited to change the payment app link as the user discovers and registers more interesting payment apps. The latter cannot -- it will always load the Bob Pay app. However, once Bob Pay is invoked, it may have its own mechanism for managing traditional "payment instruments" for the user. It will be up to Bob Pay to implement proprietary mechanisms to get the user's payment instruments into their app.

With this approach, there is support for the existing ecosystem and room to innovate in both spaces while keeping the user selection UI simple. Some users will just get a Bob Pay key and always use that to pay. Other users will get instruments from issuers and use a variety of different payment apps -- and have the choice to swap them out.

To be clear, I think an abstraction is helpful here, but we need to be careful that we don't lose important features of the existing ecosystem or dampen user control and choice in how we go about modeling it.

[dlongley]

@adrianhopebailie,

Having thought and discussed this a bit more, I think we can get the same decoupling even if we make the user selection "payment app"-based and let the payment apps handle the payment instrument registration details. We can perform the decoupling via a later standardization phase, by creating a basic standard payment instrument format and API that payment apps use in the future (we don't need to do this now). This keeps the payment mediator simpler and avoids any liability there (important for polyfills) but still makes broadening user choice and ease of use a possibility in the future.

Unfortunately, this means payment apps will have to deal with proprietary payment instrument registration and formats and so forth in the near term, but in the future, more standardization work can be done to reduce the amount of effort payment app developers need to put in to support new schemes and to help users avoid having to register payment instruments. Instead they could be issued and shared in a standard way.

In short, I now do think that pushing payment instrument details into payment apps may actually be the better way to go -- with an eye on potential future standardization of the basic payment instrument information and an API for registering/sharing tokenized instruments. Again, we needn't concern ourselves with that future at the moment, but it is important and good to know we're not taking a step that would make that effort more difficult.

[adrianhopebailie]

:+1:

I am closing this issue as there seems to mostly be consensus on the current form of the architecture. If there are any more specific issues please log with [Architecture] in the title.

@dlongley do you think it's important to standardise payment instrument registration? The way this is done and what is actually stored is very dependent on the payment method.

I'd consider payment methods as standards themselves. These will either emerge from communities interested in a common method for using a particular payment instrument (like a Bitcoin wallet) or be designed by proprietary networks that issue payment instruments (like card networks).

Personally, what I like about this model is that it accommodates legacy instruments like cards but is well placed to handle a future where payments online originate from something more akin to an app (like the digital wallets already in use today).

TL;DR: we absolutely need to accommodate cards but I think their days are numbered as digital payment instruments.

[dlongley]

@adrianhopebailie,

I am closing this issue as there seems to mostly be consensus on the current form of the architecture.

:+1:

do you think it's important to standardise payment instrument registration? The way this is done and what is actually stored is very dependent on the payment method.

First, I don't think this is important to do now in the first phase of this work. I do think it is important to do later.

That being said, I'm not talking about the issuing process, rather I'd like to see a standard Payment Instrument format and API that would enable this flow:

1. User visits issuer website and goes through some method-specific issuing process.
2. Issuer calls a browser API and gives the User a Payment Instrument that can be used within any Payment App that supports its method. The Payment Instrument has some basic standard format that is extensible to cover the needs of all payment method specific data.
3. A Payment App can later call an API to request previously issued Payment Instruments from the user.

There would likely be some (hand-waving) standard tokenization process that would occur somewhere in the above flow.

This pushes all of the payment method issuance-specific stuff to one place: the issuer's application. It also removes the need for users to perform registration more than once and allows their instruments to travel with them and be easily shared with their Payment Apps. It removes all of the registration overhead from Payment App devs and any need for those devs to create screens or N various back channel flows to obtain a user's Payment Instruments.

I think some portion of the above may also have overlap with what a potential Verifiable Claims/Identity Credentials group works on in the future. Anyway, as I said earlier, I don't think we need to consider any of this now, but it's good to know we're not making choices that could block the ability to work on it later.

[mattsaxon]

@ianbjacobs

I am not sure to understand why that would be the case. Can you explain in more detail?

The example that @adrianhopebailie gave states that that an issuer changes what they accept and releases a new payment app that supports this. The merchant PSP must support this also. This makes supporting this a two party solution, this dependency reduces options for innovation IMO, hence my comment.

The example I was thinking of was when the PSP independently creates an innovation. Granted the PSP can rollout a new payment method to solve this, but then this introduces other issues;

1. How can the new payment method share data with an old payment method? (covered in issue #15) or
2. How can the Merchant PSP dynamically register this new payment method? (covered by issue #14 )

Whilst these are covered somewhat under other issues, my specific proposal in this architectural issue is that the architecture should support some sort of pipelining.

To support the use case I mention, it could be very basic such that the payment request could specify some preprocessing to be performed prior to sending the payment details to the merchant.

How this might be handled is very different between the two current proposals on the table. This is principally because the CG proposal allows for interaction directly with a Merchant specified PSP/Processor who would be specifying this preprocessing, whereas I don't believe the Google/Microsoft proposal allows for this (at least not on my last reading)

[adrianhopebailie]

@mattsaxon said:

The example that @adrianhopebailie gave states that that an issuer changes what they accept and releases a new payment app that supports this. The merchant PSP must support this also. This makes supporting this a two party solution, this dependency reduces options for innovation IMO, hence my comment.

I don't see it this way. In the current card payment ecosystem, as an example, one has acquirers. issuers and schemes. The issuers issue cards in accordance with the scheme rules knowing that if they do so their card holders will be able to use those cards at acquirers that also support the scheme.

In the proposed ecosystem we add app publishers in addition to card issuers, make payment schemes more open by just specifying a payment methods and generalize the concept of acquirers with payment services providers.

This is a superior system because:

1. Payment methods are not limited to using cards or running on traditional card rails. They may be based on existing schemes but that's not a technical or market imposed limitation.
2. Linking a payer and payee through a payment method is far more dynamic and fluid process than rigid payment schemes. Anyone can invent a payment method and it's success is measured by the number of people that adopt it as app publishers and payment acceptors. i.e. Market forces will determine the best payment methdos and there will still be room for minor players with niche markets.
3. Further, anyone can publish an app. That means banks, PSPs, traditional wallet vendors, crypto-currency exchanges, MNOs etc. Users can even deploy an open source app themselves.
4. With that level of flexibility it follows that almost anyone can accept payments as long as they can follow the rules of some payment method. If it's an open payment method like Bitcoin then the barriers to being a payment accepting PSP are very low. Obviously if the payment method is something like tokenisaed card payments then the scheme that underlies the payment method will dictate much more rigorous requirements for payment acceptors. In that case the payment method is simple a "marker" or "handshake" that helps the user and merchant select an existing scheme and a mechanism for that scheme to define a message format for the request and response.

It wouldn't take much for the existing ecosystem to function as it does today using this new architecture.

Assuming we (the WG) publish a recommendation for how a "legacy card" payment method works (already in the works by @adrianba I believe). I'd expect it to be as simple as defining the field names that would be used to send clear card details and billing address in the payment response.

The browser vendors could ship a default payment app that is able to process payments using this payment method and the app could load itself with all of the payment card details that they already store to do card payment form auto-fills.

Now all that is required is for merchants (or their PSPs) to update their websites to call the Web Payments Browser API when it comes time to take payment (an unavoidable step since we are deploying a new API). If this API returns a legacy card payment response containing clear card details then these can simply be passed to the the PSP in the same way they would have been for a form post.

In this way we have bootstrapped our system to be at least as good as the status quo but haven't even begun to leverage the power of the new system.

An obvious next step would be for payment accepting PSPs to begin publishing payment apps so they can attempt to control both ends of the flow and implement proprietary innovations that reduce risk, lower costs or improve the user experience. This would be an obvious strategy for the many PSPs that already hold card details on behalf of merchants and the merchant simply holds a token issued by the PSP which they use whenever the customer makes a payment.

To illustrate, imagine Bob's Pay currently hold thousands of payment card details in their PCI DSS certified secure storage system. They have hundreds of merchant customers who use them as their PSP and whenever they have processed a card payment in the past have been returned a token from Bob's Pay which they can use again in future to process payments for that user. This was all done using Bob's Pay's proprietary APIs so the tokens are not usable through any other PSP and the merchants don't want to have to get their customers to enter card details again.

Bob's Pay publishes a white-label payment app that supports the legacy card payment methods but also a new one called Bob's Pay. All of Bob's Pay's merchants will now encourage their customers to install their new payment app (the merchant branded Bob's Pay app). If they do then when they attempt to make a payment at a Bob's Pay merchant the preferred payment method will be Bob's Pay and the flow will simply facilitate the exchange of the existing Bob's Pay token from the user's app to the merchant who will pass it on to Bob's Pay and processing continues as normal.

Bob's Pay may choose to only support their proprietary method (and fall back to a traditional payment's page if the user doesn't have a Bob's Pay compatible app installed) for a while until they have migrated enough users onto the app or they could roll out a seamless new loyalty program that leverages the Bob's Pay payment method and use this to incentivize users to install the app.