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

A few thoughts:

* For the callback_url, I'm concerned that since it's the payment method that's going to be returning data to that URL, we won't have any control over the response. It's difficult to build a server-side endpoint when you're not sure of the response. We can recommend something, but we can't make any guarantees.
* At least at the beginning, payment methods that already have their own system for callback support and going to continue to maintain their current systems. This means some methods will support this generic callback_url, and some won't, which is a bit of a pain for developers I would imagine.

Something that @adrianba brought up that I thought was interesting: why not let the merchant create the transaction id and pass it into PR? They're already doing this anyway for non PR-based transactions, and they're going to have to continue doing this since not all browsers will support PR, so it seems easier on the merchant to let them create.

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