> I am hearing people want to be able to use non-4217 codes with PR API. Limited supported today, so long as the code adheres to the ISO4217 format (with the known limitations/ambiguities you mentioned). Once we know what the new format is going to be (length, allowed chars), we should incorporate that. > If ISO is likely (but not guaranteed) to use a letter-based code system, would it be appropriate for authors that wish to specify a non-4217 code (or other future ISO registry) to use a non-letter prefix (e.g., "-")? Would this enable the browser to help the user distinguish "potential error" from "seeming intentional use of a non-standard code"? We definitely don't want to go down this path. That's HTTP's "x-frame-options" etc. and vendor prefixing all over again. If we do "-Whatever", then that's the standards. > Would this enable the browser to help the user distinguish "potential error" from "seeming intentional use of a non-standard code"? No. We don't do that today either. We just check the format (e.g. "YXA" is a perfectly valid currency code, which doesn't exist). > Should there be consistent display guidance to browser implementations for non-standard codes? (e.g., if the merchant-provided code is -BTC, display "BTC")? Or should the browser be free to show other symbols? It should use standardized symbols, defecto symbols knows to the UA, or ¤ otherwise. > How are other errors handled (e.g., a string of 47 characters)? RangeError. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/w3c/payment-request/pull/694#issuecomment-378831273
Received on Thursday, 5 April 2018 06:18:06 UTC