Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338)

> Hmm, OK, that makes sense! So I think the flow in terms of algorithms is that this spec should call into the payment method specs, which can then delegate to whatever payment app is currently registered to handle that payment method.

Hmm, I don't think that quite fits with the architecture. The flow is like this, at a high level:

1. The merchant website invokes `show()` on a PaymentRequest and gets a Promise.
2. The user agent shows the user all of the Payment Apps that could be used to fulfill the PaymentRequest.
3. The user selects the Payment App they want to pay with.
4. The user agent sends the serialized data to the Payment App. Note: How the data gets to the Payment App depends on its type. It may be a Web-based Payment App, which is a ServiceWorker and the data will be passed through an event to it. It may be a native app or some built-in app (or something else proprietary) and the user agent will figure out how to get the data to it on its own.
5. The Payment App, which implements the payment method (based on its particular spec), does whatever it needs to do to produce a PaymentResponse, which is sent back through the Mediator (user agent) to resolve the Promise.

-- 
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/338#issuecomment-267157564