The format of a Merchant-Presented Code is composed of domain name, standard identifier, version and general payload.

A code format is defined as follows:

HTTPS://<DOMAIN_NAME>/<STANDARD_IDENTIFIER>/<VERSION>/<GENERAL_PAYLOAD>

In the format, you can find the following elements, which are explained in detail:

• Domain name
• Standard identifier
• Version
• General payload

Domain name, also known as network domain, is the name of a computer or group of computers on the Internet. Domain name is presented as a string of dot-separated names. It can be used to identify internet resources, such as computers, networks, and services.

This parameter is a string type with a variable length, and the value is defined by the code issuer.

Example:

Below is an example of domain name：

QR.SAMPLEDOMAIN.COM

String type. The value of this parameter is defined as MPM, which means the code complies with the format defined in this standard.

Numeric type. This parameter represents the version of a code format.

The value of this parameter is defined as 3, which means the code complies with the version format defined in this standard.

The Payload is made up of three fields as depicted in Figure 2.3. The first field is the payload identifier which is defined as GPLD in this standard. The second field is a length field which is a 3-digit numeric value. The value in the length field indicates the total number of characters included in the value field. The data in the value field is a combination of different data objects.

Figure 2.3 Payload data structure

Each data object is made up of three fields, where:

• The first field is a 4-character identifier assigned to identify the data object. The identifiers are defined indata object.
• The second field is a length field which is a 3-digital numeric type. It indicates the number of characters included in the value field of this data object.
• The third field is the value field, which has a minimum length of one character.

A data object may be a primitive data object or a complex data object. For primitive data objects, for example, the payload version PLVS, there's no subdata object. For complex data objects, there are subdata objects. For example, below is a data structure of the sub data objects of CDSD in the Code Directory Service Data:

Figure 2.4 CDSD subdata structure in a payload

The subdata object (value field) of the CDSD data object is made up of three fields:

• The first field is a 2-digital number with a value ranging from 01 to 99 which is assigned to identify the subdata object.
• The second field is a length field which is a 2-digital numeric type, and it indicates the number of characters included in the value field of this data object.
• The third field is the value field, which has a minimum length of one character and maximum length of 99 characters.

The data representation requirements in a payload are described as below:

a)     The value of a data object encoded in the payload is represented by a numeric type, an alphanumeric type and a string type.

b)     For conversion of a character to its binary representation, this standard uses UTF-8 encoding as defined by the Unicode Standard.

c)     The length of the payload should not exceed 512 alphanumeric characters.

d)     The General Payload shall be converted to base64, and the URL special characters of forward slash(/)，plus sign(+) and equal sign(=) shall be URL-encoded as "%2F"，"%2B" and "%3D" respectively.

The data objects in this standard are listed in table 2.1.1 below:

Table 2.1.1 Defined data objects

The data object ID CDSD indicates the code directory service data which can be used by multiple digital wallets to obtain the acquiring information of a merchant from a CDS platform. It includes subdata objects, as defined in Table 2.1.2.

A merchant can be registered on a CDS platform and assigned with a merchant index number by the platform which indicates a merchant record storing the merchant-supported acquiring information on the platform. If the data object exists in the General Payload, the CDS platform identifier and the merchant index number shall be included in this data object. For more information, see the table below:

Table 2.1.2 Code directory service data structure

The subdata objects 04~06 are used for privacy protection of acquiring information on a CDS platform.

The data object ID CIRD indicates the reference data used by the coder issuer, including subdata objects defined in Table 2.1.3:

Table 2.1.3 Code issuer reference data structure

The value of business type is defined in Table 2.1.4 below:

Table 2.1.4 Enumeration definitions of Business Type Identifier

The data object ID TSVD indicates the transaction value information for a transaction, including subdata objects defined in Table 2.1.5:

Table 2.1.5 Transaction value data

The data object ID AMAD indicates other identification information of the merchant which can be used by the partners of code issuers to identify the merchant directly. The value of each subdata object represents a partner representation of the merchant, and the format of each representation is defined by the code issuer or the partner for private use.

Table 2.1.6 AMAD data

Table 2.1.7 AMAD subdata object template

For example, if the code issuer agrees to put identification information of the merchant, such as a merchant identifier into the code, it can use one subdata object of AMAD for a record.

The data object ID OADD indicates additional data which cannot be included in other data objects, including subdata objects defined in Table 2.1.8.

Table 2.1.8 Other additional data

For more information, see the following topics:

Merchant-Presented Mode

Code Issuer List

Code Sample

Interaction Process

Terminology

Contact Us