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

@adrianba it's unclear to me how your comment relates to the question being asked. I assume you mean that the current design is required because it uses events to notify the website of user choices with regard to things like the shipping address and therefore an event emitting object is required.

I don't dispute that, I agree that we do need a valid event emitter to support the current design.

However, my understanding of the crux of this question is whether:
 1. The website should construct the payment request data in the exact form that it will be passed to the payment app OR
 1. The website will pass data to the PaymentRequest object in the form of constructor arguments and/or through property setters (i.e. in fragments) and the payment request that is passed to the payment app is some serialized version of the PaymentRequest object.

In my proposal in PR #133 I have used your existing model of a PaymentRequest object but made a clear separation between data passed in that is consumed and used by the user agent (`options`) and the payment request that is passed on to the payment app (`data`). So, I think we can still have the API shape you have designed but pass the core payment request (minus the shipping data etc) as pure JSON data.

---
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-211547122