A Payments Initiation Architecture for the Web - w3c/webpayments GitHub Wiki

What follows is an entirely abstract Payment Initiation Architecture, made up of a number of components and describing their interaction and interfaces. Each component fulfils a role in the initiation of a payment and has some set of minimal capabilities but no assumptions are made in the architecture about how these will be implemented or deployed or how the communications between components will be performed.

In other words, different implementations of this architecture may result in components running on entirely different physical systems communicating over network boundaries or, in the other extreme, the same physical system assuming the role of a number of components with communication simply crossing process boundaries.

This architecture is designed to address the scope of work of the W3C Web Payments Working Group and is therefore not an architecture for end-to-end payments on the web. The edge components will interface with payment service providers in order to facilitate a payment in the majority of implementations and deployments.

While the Web Payments WG charter provides definitions for digital wallet, digital payment scheme and digital payment instrument early indications are that these terms have alternate definitions amongst different stakeholder groups, which gives rise to confusion.

Further, the digital wallet metaphor has proven to be difficult to replicate on the Web for the following reasons:

• In the physical world it is not practical for users to have multiple wallets. On the Web this is possible and for there to be a copies of the same payment instrument in more than one wallet.
• In the physical world the process of deciding how to pay is not done by the wallet, it is done by the user. On the Web the process of selection can be facilitated by digital algorithms that are capable of processing complex data and relationships to assist the user in deciding how to pay.
• In the physical world a user selects a payment instrument directly because this what is held in their wallet. On the Web the user is more likely to pick some abstraction of their payment instrument that may itself represent multiple payment instruments.

To deal with this, the architecture proposes a single payment mediator and multiple payment apps to replace the digital wallet.

Payment apps specify which payment methods they support and in this way the payment mediator (knowing which payment methods the payee supports) can present the user with a choice of apps applicable for a given transaction. In this model, users select from among applicable payments apps, as people would choose a payment instrument from a wallet in the physical world. In this model payment apps can further assist the user: those that hold multiple payment instruments can offer choices to the user based on various computations or preferences, or with prior user consent and configuration could handle selection automatically.

The following is a summary of the terminology in this document and relation to previous terminology attempts. Note: there is not a one-to-one mapping from the previous terminology to the current terminology, as the modeling is fundamentally different. For example, a Payment App now encapsulates Payment Instruments as an implementation detail (with respect to the core architecture); Payment App is not just a new term for Payment Instrument.

Current Terminology	Previous Terminology	Definition
Payment App	Digital Wallet & Payment Instrument	A piece of software that enables a payer to make payments (usually provided by the payer's payment service provider (PSP))
Payment Method	Payment Scheme	A system and set of rules for payments. A payment app may support one or more payment methods.
Payment Mediator	Digital Wallet & Payment Instruments	A piece of software that coordinates the flow of messages between a payee’s (Web) application and the payer’s Payment Apps

Next section: Architecture components.