Re: [w3c/browser-payment-api] API flow (#177)

I think it would helpful to describe the functions of each actor/component underlying the flows, and highlight where changes are in comparison with legacy.
For instance
- store customer data
today, it can be the Merchant and/or the Merchant PSP (shipping address, card data) allowing such thing as the "one-click payment" of Amazon)
with the API, storage is done on the device where the payment app is managed (mobile phone wallet, browser wallet...)
- create the payment form and send it to the browser
today, Merchant and/or his PSP
with the API, the API does it via the browser
- fill the form
today, pre-filled with stored data, or filled by the payer
with the API, the API does it via the mediator, so there is no manual data entry
- send the payment data to the Merchant PSP
today, as the payment page is provided by the Merchant or his PSP, it is their responsibility
with the API, the API interacts with the PSP
- send the payment data to the issuer (payer PSP or Scheme or Scheme+payer PSP)
today, done by the Merchant's PSP
with the API : hum, could be the same, but maybe the Merchant could do it himself, 
- get in return the approval from the Issuer or Scheme+Issuer
done by the Merchant'PSP in both cases
...
I am not sure to have the good answers !!

By the way (this is not a flow problem, but an important ulterior thought) this would help providing responses to merchants and acquiring PSP who have important strategic questions as: I want to know what I need to change on my site, which interface I should use, can I find here a strategic advantage and so on.
If things get easier, a direct consequence is that all this will accelerate the dis-involvement of banks from the payment processing market, and give room to many kinds of new actors.



---
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/pull/177#issuecomment-220827250