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

Apologies if I was unclear.  I ABSOLUTELY believe that the transaction ID has a domain that is the merchant and a range that is whatever the merchant chooses.  Of course the merchant should generate a meaningful transaction ID.  The point of an API-generated one is to provide traceability in the event that the merchant fails to provide one.  There does not seem to be support for just requiring a Transaction ID from the merchant, so this is a reasonable compromise IMHO.

As to things like data type, encoding, size, etc...  I am okay saying it is a UTF-8 encoded string that is no more than some number of octets long (256?).  That will assist people who have databases, etc.  However, since we have no control over merchants unless things like size limits are enforced, I would be okay requiring there be an exception thrown if the Transaction ID from the merchant does not match the requirements.  Better kill it on the front end than start passing it along and break something elsewhere in the ecosystem.

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