Components
The following components make up the architecture of a an abstract system required to perform the payment initiation functions defined in the Web Payments WG flows.
###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. It is capable of facilitating a payment on behalf of the payer using one or more payment methods.
The Payment App is defined by an app manifest which identifies the payment methods and terms that the payment app supports. This information is used by the Payment Mediator to filter the installed Payment Apps upon receiving a payment request from the payee.
Payment Apps will often need to render a user interface and/or take advantage of one or more other IO channels for payee or 3rd party (e.g. payment service provider) interaction in facilitating a payment.
This may not always be the case however. Where the payment method supports it, the payment app may be able to facilitate a payment with no user interaction from the payer.
The composition of the 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 3rd 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.
###Payment App Host
The Payment App requires an execution environment in which to run. Depending on the implementation this 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.
###Payment Mediator
Whenever a payee requests a payment via the Payee Interface the request will go to the Payment Mediator whose primary role is to co-ordinate the flow of messages between the Payee Interface, Payer Interface and the selected Payment App.
The Payment Mediator will evaluate the supported payment methods and terms provided by the payee in the payment request against those of the installed Payment Apps. It will use an algorithm (likely involving some user interaction from the payer) to select a single Payment App to facilitate the payment and then pass the necessary payment request data to that Payment App.
In some implementations the Payment Mediator will also facilitate interaction between the Payment App and the Payer Interface.
TODO
TODO
