Re: [w3c/browser-payment-api] PaymentDetails should include a transaction ID (#287)

+1 to @adamroach's  proposal. We support the addition of a top-level request identifier to the specification, and see it as absolutely necessary to allow payees to reconcile with payment apps for both for success and (more importantly) for failure cases. Additionally, payment apps may provide webhook notifications back to the merchant to report the outcome of the transaction. The merchant needs an easy way to match the webhook event to a payment request which they initiated.

>Option 1 has the drawback that it imposes the unnecessary task of generating a unique ID on the myriad payee apps, to no benefit.

Admittedly, my initial preference was for a merchant/payee generated ID, since most payees are already accustomed to doing so.

While still +1 to the proposal, my only concern with the browser-generated UUID is if the merchant’s site goes offline in the seconds or minutes  _after_ it has served up the page, but _before_ the user has initiated the payment request, because they were still busy looking at the page content. However, you could argue that this could be an implementation detail by the payee (i.e. abort if the UUID cannot be  properly communicated back to the merchant server)

-- 
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/287#issuecomment-252265655