Re: [webpayments] Abstract payment architecture (#11)

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

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