Re: [w3c/browser-payment-api] Introduce transaction_id and server callback (#292)

@ianbjacobs,

That is the original intent of the messages spec -- to be able to say how these messages are modeled and appear so that you can reuse them with a variety of different protocols. That's exactly the reason for the abstraction.

That being said, that doesn't meant we don't need a spec to say "If you want to send messages around using HTTP, here's how you do it". The same goes for "If you want to send messages using the payment request API, or with push notifications, or with X, or Y ... here's how you do it." We should only (ideally) need to define the messages once (in the messages spec) and then, when necessary, we can define specifications for using particular protocols for communicating those messages. We should be careful that we don't get too far off topic here though.

In this particular case, we want to make sure we tell app developers what they're supposed to do with the callback URL the merchant provides to them. Since the intent is to use it to communicate information over HTTP, it seems prudent to define that interaction in the HTTP spec as a feature a server can provide (and a client/payment app can take advantage of). Then, here in the payment request API, we can just define where the merchant would specify the callback in order for the payment app to find it.

-- 
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/pull/292#issuecomment-255245755