Re: [w3c/browser-payment-api] PROPOSAL: A new document structure for this API (#138)

Thanks Manu and Dave, diagrams are helpful. I've attached an alternative view.
![paymentarch201604](https://cloud.githubusercontent.com/assets/2948484/14541153/29a63522-024e-11e6-9385-e7689acbfb04.png)

Here's a text description of the relationships as I conceive of them:

* Applications will enable users to initiate payments. In a browser context, Web applications will use
the paymentRequestAPI. In other contexts, applications will use the HTTP API.
* Payment requests will either be routed through a Mediator to enable the user to choose a Payment App. I can also imagine that in some contexts people may wish to route requests directly to a Payment App. The information that is sent to the Payment App (directly or through the Mediator) will depend on the payment method.
* Payment methods will be identified with Payment Method Identifiers. Payment Method specifications  will describe the input and output data that will flow from the payee to the payer and back.

Thus:
* All the specs will depend on the Payment Method Identifier spec
* Both of the API specs (paymentRequest, HTTP) will rely on the Mediator and App specs for handing off payment requests and receiving responses.
* The paymentRequest API and HTTP API specifications could end up sharing a parameter definition spec; I hope they do but I'd like to see each one mature before we factor that out.

Ian


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/138#issuecomment-210117861