The QR Code is standardised thought-out the global and lcoal payment rails for both sender and receiver.
The QR code is designed to be able to process payments across the widest possible range of mobile devices to ensure inclusivity to all, offline Coin based payments without the need for a mobile phone, or network are also supported, this standard is focused on online mobile phone based QR codes.
The Global payments infrastructure does not need any infrastructure, networks or POS terminals, a mobile phone with camera is all that is required, to support frictionless, instant global and local payments without any fees, or spread. Typical local payments are sub 500ms, and cross currency area < 1 second people-to-people with legal finality anywhere on the planet.
Introduction
The QR Code is generated, displayed and read by the consumer device, however the exact size of a QR code is device and display dependent and there is no standardised device procedures or device specifications which are out of scope of this specification. Requirements other than the QR Code Data and Image Standards within this section are informative descriptions and included to assist developers in understanding the functional requirements of QR Code within the global payment rail.
Normative
QR Data Standard
The QR code data is always generated by the payment infrastructure
The payload is always an RFC 7519 token
The data is always Base64Url compact encoded string
The specifics of the JwToken claims can be viewed publicly via any JwToken decoder such as jwt.io
QR Image Standard
All images produced by all application shall be ISO compliant with ISO/IEC 18004:2015 Information – Automatic identification and data capture techniques – QR Code barcode symbology specification.
Non-normative
The QR Code Encoding procedure to convert Base64Url encoded data into a QR Code can be accomplished by performing the following steps in the order shown.
Convert the resultant base64 data string into a QR Code symbol as defined in [ISO 18004], using the following parameters and options:
Mode: use the default Extended Channel Interpretation (ECI) and Byte mode.
Error Correction: use Error Correction Level L, M, Q, or H and the value of p as defined in [ISO 18004] Table 9—Error correction characteristics for QR Code 2005.
Symbol Version: use the smallest QR Code version that accommodates the data. • Data Masking: perform data masking as defined in [ISO 18004].
Orientation and Reflectance: use normal orientation and normal reflectance arrangement.
The QR Code Reader shall be able to read QR Codes as defined in [ISO 18004] including the default ECI which is [ISO 8859-1].
Readers may support the following [ISO 18004] features:
Micro QR Code
Structured Append
ECIs other than the default ECI
Mirror Imaging/Orientation
Reflectance Reversal
Verify QR Code
If any of the following [in the order presented] is true, then the data is not encoded per this specification and subsequent processing is outside the scope of this specification:
The data received from the QR Code Reader is not base64Url encoded.
Following base64 decoding, the resulting UTF8 data is not RFC 7519 coded.
The data passes the RFC 7519 defined validation procedures
The QR Code Reader shall support recovery of at least 512 bytes from the QR Code. The QR Code Reader may support recovery of more than 512 bytes.
The QR Code read by the QR Code Reader is the baseUrl64 encoded QR Code Payload and shall be sent to the Infrastructure as defined in the Payment Rail API specification.
All other QR Code Reader and device hardware requirements are outside the scope of this specification, QR Code Reader behavior in response to any error that occurs during this processing is outside the scope of this specification.
Example
JWToken for QR Code payload.
The full specification is contained within the Global Payment Rail API specification and the latest version should be consulted.