Various payment systems use restricted character sets. An application that processes 'payto' URIs MUST
convert characters that are not allowed by the respective payment systems into allowable characters using either an encoding or a replacement table. This conversion process MAY
be lossy, except for the instruction field. If the value of the instruction field would be subject to lossy conversion, modification, or truncation, the application SHOULD
refuse further processing of the payment until a different value for the instruction is provided.
To avoid special encoding rules for the payment target identifier, the userinfo component [RFC 3986
] is disallowed in 'payto' URIs. Instead, the payment target identifier is given as an option, where encoding rules are uniform for all options.
Defining a generic way of tagging the language of option fields containing natural language text (such as "receiver-name", "sender-name", and "message) is out of the scope of this document, as internationalization must accommodate the restrictions and requirements of the underlying banking system of the payment target type. The internationalization concerns SHOULD
be individually defined by each payment target type.