Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)

> 1) it requires the developer to be keenly aware of state changes

Not really. In most implementations, the developer doesn't even really need to check it. It actually emerged because there are certain actions you just can't take in particular states. For example, let's say that we've now opened up a third party application and the developer tries to abort or cancel. This isn't really possible, as it's not outside the control of the user-agent, at least on particular platforms. So a developer could, if they wanted, check the state before calling cancel, but if they don't, the system will just throw an exception.

> 2) it hangs functionality off of the PaymentRequest object that, arguably, complicates how a developer has to manage it.

Not sure I understand how this is a point separate from point 1. What it does provide is functionality that is necessary if we support the collection of shipping address and the necessary complexity that comes with that.

> As an aside, @bifurcation is Richard B.?

Yep.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/64#issuecomment-174214567