Re: [w3c/browser-payment-api] Should a payment request be just data, or a programmable object? (#47)

This issue has nothing to do with events vs promises which is all your comment discussed.

This issue has to do with the idea of "messages" and the need to encapsulate the full content of a payment request as a single JSON-serializable object that can be passed across process or network boundaries.

The current design splits all of the data that must be passed to the payment app among a variety of parameters so it is unclear how a JSON-serialized payment request would be created from a PaymentRequest object or what it would look like.

The question at hand is whether or not it would be better for there to be a clear separation of concerns in the API so that the payment request is constructed entirely by the website as a single pure data object and passed to the PaymentRequest constructor in the same form the website expects to be passed on to the payment app.

I don't consider the other functions of the PaymentRequest object (such as emitting events) as the issue at hand because, as you say, that's the design we have chosen to adopt.

---
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/47#issuecomment-211558544