{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/browser-payment-api/issues/146","repository_url":"https://api.github.com/repos/w3c/browser-payment-api","labels_url":"https://api.github.com/repos/w3c/browser-payment-api/issues/146/labels{/name}","comments_url":"https://api.github.com/repos/w3c/browser-payment-api/issues/146/comments","events_url":"https://api.github.com/repos/w3c/browser-payment-api/issues/146/events","html_url":"https://github.com/w3c/browser-payment-api/issues/146","id":149732897,"number":146,"title":"What is the extensibility mechanism for the payment request and response messages?","user":{"login":"adrianhopebailie","id":49902,"avatar_url":"https://avatars.githubusercontent.com/u/49902?v=3","gravatar_id":"","url":"https://api.github.com/users/adrianhopebailie","html_url":"https://github.com/adrianhopebailie","followers_url":"https://api.github.com/users/adrianhopebailie/followers","following_url":"https://api.github.com/users/adrianhopebailie/following{/other_user}","gists_url":"https://api.github.com/users/adrianhopebailie/gists{/gist_id}","starred_url":"https://api.github.com/users/adrianhopebailie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adrianhopebailie/subscriptions","organizations_url":"https://api.github.com/users/adrianhopebailie/orgs","repos_url":"https://api.github.com/users/adrianhopebailie/repos","events_url":"https://api.github.com/users/adrianhopebailie/events{/privacy}","received_events_url":"https://api.github.com/users/adrianhopebailie/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/browser-payment-api/labels/Extensibility","name":"Extensibility","color":"fad8c7"},{"url":"https://api.github.com/repos/w3c/browser-payment-api/labels/help%20wanted","name":"help wanted","color":"159818"}],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/w3c/browser-payment-api/milestones/2","html_url":"https://github.com/w3c/browser-payment-api/milestones/Priority:%20Medium","labels_url":"https://api.github.com/repos/w3c/browser-payment-api/milestones/2/labels","id":1657715,"number":2,"title":"Priority: Medium","description":"","creator":{"login":"mattsaxon","id":11351127,"avatar_url":"https://avatars.githubusercontent.com/u/11351127?v=3","gravatar_id":"","url":"https://api.github.com/users/mattsaxon","html_url":"https://github.com/mattsaxon","followers_url":"https://api.github.com/users/mattsaxon/followers","following_url":"https://api.github.com/users/mattsaxon/following{/other_user}","gists_url":"https://api.github.com/users/mattsaxon/gists{/gist_id}","starred_url":"https://api.github.com/users/mattsaxon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mattsaxon/subscriptions","organizations_url":"https://api.github.com/users/mattsaxon/orgs","repos_url":"https://api.github.com/users/mattsaxon/repos","events_url":"https://api.github.com/users/mattsaxon/events{/privacy}","received_events_url":"https://api.github.com/users/mattsaxon/received_events","type":"User","site_admin":false},"open_issues":23,"closed_issues":1,"state":"open","created_at":"2016-03-21T15:50:21Z","updated_at":"2016-04-20T12:17:40Z","due_on":null,"closed_at":null},"comments":2,"created_at":"2016-04-20T10:45:28Z","updated_at":"2016-04-20T15:09:36Z","closed_at":null,"body":"Forked from #40 \r\n\r\nThe concept of \"messages\" has been raised in numerous issues and PRs but not clearly defined. \r\n\r\nThere is a requirement for websites to be able to construct a payment request message (a JSON-serialized object) that is passed to the API and passed, unchanged by the browser, to the payment app that processes the payment request.\r\n\r\nLikewise, there is a requirement for payment apps to be able to construct a payment response message (a JSON-serialized object) that is passed back unchanged to the website that made the original request.\r\n\r\nThe need for JSON serialization of these messages is driven by a requirement to pass them across process and network boundaries. Until such a mechanism exists there will be no standard for interfacing with payment apps which implies they will either be built into the browser or their integration will be entirely proprietary. Put differently, the current API spec has no conformance criteria imposed on browsers to support third-party payment apps.\r\n\r\nIt is unclear how the current API would cater for this requirement to pass an unaltered payment request message on to the payment app as the current design does not allow for a complete message to even be passed to the API.\r\n\r\nThere is a proposal to address this #133 BUT this issue assumes that this will be resolved (either through that or some other proposal) and that what is being discussed here is how this message can be extended.\r\n\r\nIn #40 @triblondon (in his review for the TAG) made the observation:\r\n\r\n> AFAICT, the merchant doesn't know about payment apps, only payment methods, so it's hard to see how custom data not tied to a payment method could be useful.\r\n\r\nThis suggest that it's not necessary (and would be very difficult) to facilitate extensibility of the whole payment request message.\r\n\r\nHowever, there was also a previous resolution by the group at https://github.com/w3c/webpayments/issues/83 to include the following text in the API spec once a companion document was available describing how the API parameters could be extended:\r\n\r\n> The JSON-LD Payment Extension specification (linked to the document) explains how to extend the parameters used with this API using JSON-LD.\r\n\r\nThis suggests that the requirement is to define a standardized format for the payment request message which maps directly to the WebIDL definition of one of the input parameters to the API and includes extension points for the custom payment method data."},"comment":{"url":"https://api.github.com/repos/w3c/browser-payment-api/issues/comments/212469203","html_url":"https://github.com/w3c/browser-payment-api/issues/146#issuecomment-212469203","issue_url":"https://api.github.com/repos/w3c/browser-payment-api/issues/146","id":212469203,"user":{"login":"dlongley","id":168137,"avatar_url":"https://avatars.githubusercontent.com/u/168137?v=3","gravatar_id":"","url":"https://api.github.com/users/dlongley","html_url":"https://github.com/dlongley","followers_url":"https://api.github.com/users/dlongley/followers","following_url":"https://api.github.com/users/dlongley/following{/other_user}","gists_url":"https://api.github.com/users/dlongley/gists{/gist_id}","starred_url":"https://api.github.com/users/dlongley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dlongley/subscriptions","organizations_url":"https://api.github.com/users/dlongley/orgs","repos_url":"https://api.github.com/users/dlongley/repos","events_url":"https://api.github.com/users/dlongley/events{/privacy}","received_events_url":"https://api.github.com/users/dlongley/received_events","type":"User","site_admin":false},"created_at":"2016-04-20T15:09:36Z","updated_at":"2016-04-20T15:09:36Z","body":"@adrianhopebailie,\r\n\r\nI 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.\r\n\r\nThe 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.\r\n\r\nNow, 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.\r\n\r\nInstead, 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.\r\n\r\nThe 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.\r\n\r\nHowever, 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).\r\n\r\nLet'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.\r\n\r\nI do not agree with:\r\n\r\n* Chopping the message up into pieces because that's preferable (and is it really?) for one particular API\r\n* Making it hard to bundle everything together and digitally-sign it for integrity/non-repudiation\r\n* Completely punting on finding a unified vision and integration of messages with multiple APIs\r\n* Starting from a point of divergence with the various APIs instead of convergence and only diverting when necessary"}}