Re: [w3c/browser-payment-api] What is the extensibility mechanism for the payment request and response messages? (#146)

@adrianhopebailie,

I would prefer a design where the payment request message is passed, untouched, through the browser API. The payment request message is the set of information that encompasses all data required to initiate a payment via a payment app and any additional machine-readable information that could enhance the user's experience via a payment app, such as offers, links to product information, taxation rules, links to other offers should additional choices be made, options to add donations to third parties, rebates, whatever anyone could possibly conceive of.

The user agent needn't concern itself with just about all of that. All it needs to do is ensure that it helps the user select a payment app that can process that payment request message using the one of the acceptable methods listed within it.

Now, if we want to create a browser API that has to repeat that most basic information outside of the payment request so that we can meet some Web IDL restrictions, then so be it. However, this should not place an undue burden on the ability for people to innovate and extend the payment request message itself in any way. When I hear about people "adding extension points", what I hear is "let's restrict how you can extend these messages to whatever this small group of people can imagine." That's a mistake. I don't know what patterns people will come up with in the future or what cleverness will arise. I certainly don't want to place restrictions on the evolution of this ecosystem because of Web IDL.

Instead, define the parts of the message that we *do* know about and say what the conformance is. Everything else, leave untouched. We need to figure out the best way to accomplish this with the user agent API, given its restrictions, in consultation with user agent implementers. However, those implementers need to understand that the vision for this ecosystem is larger than a user agent UI that improves the checkout experience. Decisions regarding the shape of the browser API should not impede that vision nor, do I think, should they ignore the fact a design that put payments first allows us to have a more consistent model for how things like Payment Apps work -- regardless of the variety of APIs we provide to allow people to interface with them.

The approach that the WPCG API took was to do just that -- and to let the user agent just read particular parts of the payment request message. Instead, we've opted to pull those parts that the user agent needs out of the message and pass them, on their own, into the API. I understand that these are the only parts that are important to the user agent, and that user agents may want to receive them in a particular way.

However, the user agent is just playing one role here -- there is much more going on than just making a request through the browser, there is everything that happens at the endpoints and in between as well. I don't want any restrictions placed on the data that is passed to Payment Apps other than what is minimally required for interoperability. I also would like us to recognize that we can have a much more powerful, interoperable design if we ensure that the messages that Payment Apps receive always follow the same format, regardless of *how* they get there. Sure, a user agent may be responsible for getting a message to a Payment App, when someone is using a browser on the Web. But the message could also get there another way! (e.g. HTTP).

Let's design Payment Apps so that they receive payment request messages and then return payment response messages. Then we can say how a user agent will hand one over. If we want to make it such that user agents don't read those messages at all to find totals, acceptable payment methods, or other information -- but rather we want to pull that information out and repeat it in the browser API, so be it. I don't think that's the best way to do it, but I'll accept it. But let's make sure we pass the payment request message, untouched, along side that information. And let's define what that message is in another spec -- that all APIs can depend on.

I do not agree with:

* Chopping the message up into pieces because that's preferable (and is it really?) for one particular API
* Making it hard to bundle everything together and digitally-sign it for integrity/non-repudiation
* Completely punting on finding a unified vision and integration of messages with multiple APIs
* Starting from a point of divergence with the various APIs instead of convergence and only diverting when necessary

---
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/146#issuecomment-212469203