- From: Nick Shearer <notifications@github.com>
- Date: Sun, 13 Nov 2016 14:51:46 -0800
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Message-ID: <w3c/browser-payment-api/pull/292/c260219174@github.com>
Yes, I think the callbackURL requires further discussion. I agree with Zach's point re: the merchant generating the ID. I am not massively keen on the browser generating the transaction ID, certainly as it's currently written. "Unique" is not a conformance key word. Do we mean globally unique? Unique to the merchant? What's its format? Requiring user agents to generate a unique identifier and then not defining the parameters of that unique identifier will cause problems. Developers may make assumptions (like the length, encoding, use of non ASCII chars) about the format. They might assume, say, the user agent will always return a 128-bit UUID and make that into their database, based on what the major user agents are doing. Then that user agent subsequently changes it to be a 256-bit UUID, *which is within the specification* - but the developer now has a broken implementation. So my preference would be to simply drop the requirement for the user agent to generate a transaction ID if none exists. But if we do keep it, the specification should at the very least provide a clear definition of what that ID should be made up of (not necessarily the formula, but length, permitted characters, etc). -- 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-260219174
Received on Sunday, 13 November 2016 22:52:19 UTC