The following components make up the architecture of an abstract system required to perform the payment initiation functions defined in the Web Payments Working Group flows:

• Payment App
• Payment App Host
• Payment Mediator
• Payer Interface
• Payee Interface

This set of components would normally sit between the Payment Service Providers (PSPs) of the payer and payee. However, for some payment schemes such as Bitcoin, the components communicate directly into the scheme's infrastructure.

Diagram

Payment App

The basic building block of the architecture is the Payment App. A Payment App is an application provided by the payer’s Payment Service Provider. The Payment App facilitates a payment on behalf of the payer using one or more Payment Methods (@@IJ: include examples of payment methods here@@). The Payment App communicates information about supported payment methods with the Payment Mediator.

As part of facilitating payment, a Payment App may render a user interface and/or take advantage of one or more other IO channels for payer or third-party interaction (e.g., payment service provider). In some cases and where supported by a payment method, a Payment App may be able to facilitate a payment without immediate user interaction based on prior payer consent. (Example: A Web of Things scenario where the payer is a machine capable of executing payments in accordance with predefined rules and logic).

The composition of a Payment App will be platform and deployment dependent and many aspects of how the Payment App communicates with the host, interacts with the payer and payee, and communicates with third-party services will be determined by the implementer who provides the Payment App Host, as an execution environment for the app, and the Payment Mediator, that mediates all interactions between the Payment App and other components.

Implementation Note: There may be advantages to using a manifest to store information about supported payment methods rather than dynamically querying the Payment App. In particular, this should enable the Payment Mediator to filter Payment Apps without needing to launch the apps.

Payment App Host

The Payment App Host provides the execution environment for the Payment App, such as (@@IJ: Include examples here@@).

The Payment App Host may be tightly integrated with other components such as the Payment Mediator and Payer Interface or may be one or more separate systems hosting individual Payment Apps or a combination of these.

Payment Mediator

The Payment Mediator fulfills a number of roles:

• It helps determine which payer Payment Apps can be used to fulfill the payment request given the payee's accepted payment methods.
• It helps the payer choose one (typically with explicit interaction or prior consent).
• It passes payment request data to the payer's selected Payment App.

A Payment Mediator thus co-ordinates the flow of messages between the Payee Interface, Payer Interface and the selected Payment App. In some implementations the Payment Mediator may also facilitate interaction between the Payment App and the Payer Interface.

A Payment Mediator may implement different algorithms for filtering suitable Payment Apps.

Payer Interface

The Payer Interface is the component that provides the payer with the ability to interface with the Payment Mediator and Payment App. This allows these components to receive payer input to their processes if the implementation and deployment supports it.

Example: in a Web Browser this may take the form of a rendered HTML UI.

Payee Interface

The Payee Interface is the component that interfaces with the payee. This may be in the form of an API that the payee calls to request a payment.

Example 1: in a Web browser this would be a WebIDL API.
Example 2: in the case of a machine to machine implementation and deployment it may be a Web API, accessed via HTTP.

Previous section: A Payments Initiation Architecture for the Web.

Next section: How it Works.