REGULATION ON THE GENERATION AND THE USE OF THE TR QR CODE IN PAYMENT SERVICES

Publication Date/No: 21.8.2020 / 31220

SECTION ONE Objective, Scope, Legal Basis and Definitions

Objective and scope

ARTICLE 1 - (1) The objective of this Regulation is to regulate the procedures and principles regarding the generation and use of the TR QR code in payment services.

(2) This Regulation shall apply to payment transactions that are made via QR code and fall within the scope of payment services as per the Law No. 6493 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions dated 20/06/2013 .

Legal Basis

ARTICLE 2 - (1) This Regulation has been prepared with respect to the third and sixth paragraphs of Article 12 and the sixth paragraph of Article 18 of the Law No. 6493.

Definitions

ARTICLE 3 - (1) The following terms shall have the meanings indicated below:

a) Payee: Natural or legal person who is intended to receive the fund subject to a payment transaction,

b) Bank: The Central Bank of the Republic of Turkey Joint Stock Company,

c) BKM: Interbank Clearing Center Joint Stock Company,

ç) Dynamic QR code: A single-use QR code generated specifically for the payment transaction in process,

d) Payer: Natural or legal person who gives a payment order either from his/her payment account or without having a payment account,

e) Merchant: A natural or legal person, who -as the receiver party- accepts a payment transaction for a good or service fee using QR codes generated within the scope of the Technical Document,

f) Merchant presented QR code: A QR code model based on the principle that consumers scan the QR code presented by the merchant via their application and initiate the payment transaction,

g) QR code: A two-dimensional code that stores alphanumeric data, characters and symbols, consisting of three square pattern markers in the lower left corner, upper left corner and upper right corner according to the viewer and has black and white modules in the form of square black and white dots or pixels, generated to be used in payment transactions by scanning method,

ğ) QR Code Generator ID: The code required to generate the TR QR Code,

h) QR Code Switching System: The infrastructure that enables the transfer of QR codes and the information contained between payment service providers,

ı) User: Natural or legal person making a payment using a QR code,

i) Payment order: Instruction given by the payment service user to his payment service provider for the purpose of executing a payment transaction,

j) Payment service: Services stated in Article 12 of the Law No. 6493,

k) Payment service provider: Institutions stated in Article 13 of the Law No. 6493,

l) Payment transaction: Act of depositing, transferring or withdrawing funds upon the order of payer or payee,

m) Payment card: Bank cards and credit cards issued within the scope of the Bank Cards and Credit Cards Law No. 5464 dated 23/2/2006 and cards that are payment instruments issued pursuant to the Law No. 6493,

n) Payment system: The structure that has common rules and provides the infrastructure required for clearing and settlement transactions carried out in order to realize fund transfers arising from transfer orders among three or more participants,

o) Payment system operator: Legal person responsible for the daily operations of the system and holds the required license for operating a system,

ö) Static QR code: A QR code with a fixed content and which can be used in more than one payment transactions,

p) Technical Document: The document titled "TR QR Code Principles and Rules" attached to this Regulation, which determines the main principles and rules to be followed when generating QR code for all kinds of transactions within the scope of payment services in accordance with Law No. 6493,

r) TR QR Code: The QR code generated in accordance with the rules and principles in the Technical Document and that can be used in payments under the Law No. 6493,

s) TR QR code transaction: The payment transaction carried out using the QR code generated in accordance with the procedures and principles in the Technical Document.

SECTION TWO TR QR Code and QR Code Switching System

The payments that will be carried out by using the TR QR Code

ARTICLE 4- (1) The TR QR Code shall be used in all payment transactions that fall within the scope of the Law No. 6493 and are made through a QR code.

(2) The Bank may impose an upper limit on payment transactions that can be conducted using a TR QR Code.

(3) The Bank shall be authorized to request necessary information and documents from payment service providers and the parties whose activities are closely related with QR code payment transactions such as system operators, merchants, outsourcing institutions where TR QR Code transactions are carried out, and conduct on-site inspections, when necessary.

(4) The responsibilities of the payment service provider, merchants, payer, payee and other relevant parties regarding payment transactions initiated through TR QR Code, arising from other legislation, which is applicable depending on the nature of the realized payment transaction, shall be reserved.

Generation of TR QR Code and the QR Code Generator ID

ARTICLE 5- (1) TR QR Code shall be generated by payment service providers and the payment system operator which is approved by the Bank, both of which owns TR QR Code Generator ID.

(2) TR QR Code to be generated under the first paragraph shall be subject to the principles and rules laid down in the Technical Document.

(3) The payment service provider may outsource the TR QR Code generation.

(4) The TR QR Code Generator ID shall be determined by the BKM at the request of the payment service provider and the payment system operator approved by the Bank and shall be announced on the list to be published on its website.

Guidelines for Technical Rules and Principles

ARTICLE 6- (1) Guidelines for Technical Principles and Rules , which contain workflows of the transactions to be carried out through a specific payment system using a TR QR Code, shall be determined by the Bank upon the application of the relevant system operator. If deemed necessary for the improvement of the field of payments, the Bank shall be authorized to prepare Guidelines for Technical Principles and Rules for a certain type of payment service which includes workflows of the transactions to be carried out using a TR QR Code.

(2) Distribution and sharing procedures for the Guidelines for Technical Principles and Rules Guidance to be prepared under the first paragraph shall be determined by the Bank.

QR Code Switching System

ARTICLE 7 – (1) The BKM shall establish and operate the QR Code Switching System to transfer a QR code and its information content between the payment service providers, if required in the processes related to payment services carried out using TR QR Code.

(2) All procedures and principles regarding the implementation of this article including operating rules, conditions for participation and cost-based pricing principles of the QR Code Switching System shall be determined by the Bank and announced on its website.

SECTION THREE Rights and Obligations of the Parties

Powers and responsibilities of the payment service providers in TR QR Code transactions

ARTICLE 8 – (1) The payment service provider shall be obliged to ensure that the QR code is generated in accordance with the Technical Document for payment services it will provide using TR QR Code and to take the necessary measures for safe and secure realization of payments using TR QR Code.

(2) The payment service provider may determine an upper limit for the payment transactions to be carried out using TR QR Code provided that they do not exceed the limits specified in the second paragraph of Article 4.

(3) While generating TR QR Code, the payment service provider shall mind that the QR code quality and readability are as high as possible and shall ensure that the QR code integrity is preserved.

(4) The payment service provider shall be responsible for conducting the payment transactions to be made using TR QR Code in accordance with the information on the QR code and preserving the integrity of the information of QR code while the payment transaction is being processed.

(5) The payment service provider shall pay due attention in adopting required measures to safeguard the physical security and readability of QR code in payment transactions using TR QR Code and shall include provisions needed in the framework contract for the merchant to take necessary measures .

(6) In the case that the payment service provider outsources the QR code generation, provisions for outsourcing laid down in the legislation, which the payment service provider is subject to according to the nature of the payment transaction, shall apply.

(7) Regarding TR QR Code transactions, following the completion of payments both the payee and the payer shall be informed immediately by their own payment service providers about the realization of the transaction via the most convenient means such as telephone, text message or application.

Responsibilities of the merchant concerning TR QR Code transactions

ARTICLE 9 – (1) The merchant that accepts payments through TR QR Code shall be obliged to inform the payment service users that the payment transaction can be carried out via a QR code. The information to be provided under this paragraph shall be made in accordance with the display format to be determined by the Bank.

(2) The merchant that accepts payments by the TR QR Code shall pay due attention for the fulfillment of TR QR Code transactions in accordance with the information in the QR code and preservation of the integrity of the information in the QR code while conducting the payment and shall safeguard the physical security and readability of the QR code in the payment transactions realized via a static QR code.

SECTION FOUR Miscellaneous and Final Clauses

Transactions including a foreign element

ARTICLE 10 – (1) It shall not be compulsory to use a TR QR Code in domestic payment transactions carried out through payment instruments issued according to the legislation of a foreign country, in which one of the parties is located abroad and for which the infrastructure of a payment service provider located abroad is used.

Implementation principals

ARTICLE 11 – (1) The Bank is authorized to construe the provisions of this Regulation, to make a decision about the issues which are not mentioned or not explicit in this Regulation by taking into account the general provisions, to public communiques, circulars and mandates to regulate and direct the implementation.

Transitional provisions

PROVISIONAL ARTICLE 1 – (1) Payment service providers facilitating payments via QR code shall make their QR codes and respective infrastructures compatible with this Regulation, the “Technical Document” and- in the case that the payment service they provide requires a transaction through a payment system, the “Guidelines for Technical Principles and Rules” to be prepared for that payment system no later than 31/12/2021. The Bank is authorized to extend this period for a maximum of one year.

(2) Payment service providers, which offer the facility of acceptance of payments through payment cards or payment systems operated by the Bank shall be obliged to establish the infrastructure facilititating payments through using merchant presented dynamic QR code as stated in the Technical Document to be accepted by the contracted merchants no later than 31/12/2021. The Bank is authorized to extend this period for a maximum of one year.

(3) If merchants use different devices and applications in addition to the payment infrastructure offered by the payment service provider during payment acceptance through payment cards and payment systems operated by the Bank, owners of these additional devices and applications shall also be required to take measures to establish infrastructure that facilitates payments to be realized viaMerchant presented dynamic QR code as stated in the Technical Document to be accepted in the Merchant by 31/12/2021 at the latest. The Bank is authorized to extend this period for a maximum of one year.

(4) The Bank is authorized to require the payment service provider to cease the payment infrastructure services offered to any merchant that does not provide a reasonable justification for not making effort to take the necessary measures under the third paragraph.

Entry into force

ARTICLE 12 – (1) This Regulation shall enter into force on the day of its publication.

Execution

MADDE 13 – (1) The provisions of this Regulation shall be enforced by the Governor of the Central Bank of the Republic of Turkey.

TR QR Code Technical Principles and Rules

Version 1.0
August 2020

TÜRKİYE CUMHURİYET MERKEZ BANKASI

Revision History

Date	Amendment Description	Version
August 2020	First Release	1.0

1. Purpose and Scope

The purpose of this document, which was prepared within the scope of defining the national QR Code (TR QR Code) principles and rules, is to ensure interoperability between the actors in the ecosystem by creating a standard QR code structure and common rules and language for the field of payments, support innovative initiatives and thus, contribute to the widespread use of QR Code in payment services.

With this document, a common infrastructure has been established that aims to provide the best practice in the acceptance of payments with the QR code to all stakeholders, especially QR code generators and acceptors, payment service providers, technical service providers, and payment service users.

TR QR Code is intended to ensure QR code standardization in retail payments by promoting cashless payment at all levels, and eventually to support the use of less cash in Turkey. By means of these common rules, users of different payment service providers will be able to make payments with QR Code, and payments between different payment schemes, digital wallets and payment service providers will be facilitated. Also, adoption of the QR code as a payment method will be encouraged in merchants, including small ones.

It is mandatory to comply with the procedures and principles in this document for all transactions that are made using a QR Code and fall within the scope of payment services as per the Law No: 6493 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions dated 20.06.2013.

Potential parties of the payment transactions to be made with a QR Code produced in line with this document (TR QR Code) are as follows:

• Generators of the QR Code to be used for payments,

• Merchants, consumers, payment service users that will scan and accept the generated QR Code,

• Payment service providers,

• Payment systems that transfer funds between payment service providers in order to clear and/or settle payments initiated using a QR Code,

• Third-party service providers that develop QR code-based payment applications/systems.

TR QR Code contains specifications that allow the use of data coding technology, known as "QR Code"1, in the field of payments in Turkey.

A QR code has the main function of providing the necessary information such as identity, account or card information of one of the parties in a payment transaction. During the execution of a payment transaction, the QR Code is presented by one of the parties and scanned by the other.

Within the scope of the principles and rules in this document, the features of the QR Code technology, the encoding of the data objects, the data types and formats, the QR Code data organization according to the business models used, and the characteristics of the data objects are described.

TR QR Code will be used for all payments with a QR Code within the scope of the Law. In this context, the specifications for the Merchant Presented QR Code, the Consumer Presented QR Code, the QR Code for Person-to-Person Payments, and the short QR Code, which stores a limited amount of information, are defined in this document.

These specifications support both static QR codes that can be used in more than one payment with the same information content, and dynamic QR codes that are specifically generated for each single transaction with a unique reference ID.

[1] QR Code is a registered trademark of Denso Wave.

2. Definitions and Abbreviations

2.1. Definitions

In this document, the following terms shall have the meanings indicated below:

Payee/Receiver: The natural or legal person to whom the fund is requested to reach in the payment transaction,

BKM: The Interbank Card Center,

Dynamic QR Code: A single-use QR code generated specifically for the payment transaction in process,

EMVCo: A global technical body owned by American Express, Discover, JCB, Mastercard, UnionPay, and Visa,

Electronic communications operator: The operator defined within the scope of Electronic Communications Law No. 5809 dated 5/11/2008,

FAST: The Instant and Continuous Transfer of Funds System, owned and operated by the CBRT,

Payer/Sender: The natural or legal person who gives a payment order either from their own payment account or without a payment account,

Merchant: A natural or legal person who, as the receiving party, accepts the payment for a good or service using a QR Code generated within the scope of this document,

Merchant Presented QR Code: A QR Code model based on the principle that consumers scan the QR Code presented by the merchant through their application and initiate the payment process,

Law: Law No: 6493 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions dated 20/06/2013,

QR Code: (short for “quick response code”) A two-dimensional barcode, generated to be used in payment transactions via the scanning method, that stores alphanumeric data, characters and symbols, consists of three square pattern markers in the lower left corner, upper left corner and upper right corner depending on the perspective of the viewer, and has black and white modules in the form of square black and white dots,

QR Code Generator ID: The identification code of the entity required to generate the TR QR Code,

QR Code Switch System: The infrastructure that enables the transfer of QR codes and the information contained in them between payment service providers,

Short QR Code: The QR Code with limited data storage, used in cases where all the data required for the payment transaction cannot be stored due to this limited capacity or where it is preferred not to include them in the QR code explicitly,

User: A natural or legal person initiating payments by using a QR Code,

Mobile Payment: The payment service specified in subparagraph (d) of the first paragraph of Article 12 of the Law,

Payment Service: Services specified in Article 12 of the Law,

Payment Service Provider (PSP): Institutions specified in Article 13 of the Law,

Payment transaction: The activity of depositing, transferring or withdrawing funds on the order of the sender or the receiver, Payment system: The structure that has common rules and provides the infrastructure required for the clearing and settlement transactions carried out to realize fund transfers arising from transfer orders among three or more participants,

Payment system operator: Legal person responsible for the daily operation of the payment system who holds the required licence for operating a system,

Static QR Code: A QR Code whose content is fixed and can be used in more than one payment transaction,

CBRT: Central Bank of the Republic of Turkey Joint Stock Company,

TR QR Code: The QR Code generated in accordance with the rules and principles in this document and that can be used in payments under the Law,

National Merchant Registration System: The system owned and operated by the BKM where information about merchants accepting electronic payments is kept in order to facilitate the processes regarding payment transactions made with the TR QR Code as well as to prevent fraud and malicious activities in the field of payments.

3. General Principles

The following general principles have been taken into account in the definitions of the TR QR Code Technical Principles and Rules for payments.

• The Merchant Presented Long QR Code specification complies with the EMVCo standard2.

• The QR codes generated properly in accordance with the specifications in this document can be used statically or dynamically depending on the use cases, and support various forms of payments such as mobile, bill, online, and point-of-sale.

• All payment services made by using a QR code within the scope of the Law shall use the QR codes generated properly in accordance with the specifications in this document.

• Payment service providers who want to offer their users the opportunity to make payments using a QR code shall make the necessary improvements in their infrastructure in order to generate and read these QR codes.

• QR code generators shall ensure that the QR code is generated in accordance with the rules in this document and the demands of the businesses or users they serve.

• QR codes covered by the rules in this document are generated in compliance with the ISO / IEC 18004 standard.

• When a QR code generator generates a QR code or adds new data to an already generated one, it is their responsibility that all the data it contains are complete and accurate, and that the code fully complies with the technical documents and requirements related to the TR QR Code in effect.

• For the payments made with a QR code, all parties, particularly the payment service providers, are liable to fulfill their other obligations arising from the Law and other relevant legislation, which are not specified explicitly in this document.

4. QR Code Types For Use in Payments

In this section, the types of QR codes used in the field of payments are addressed. First, QR codes are classified according to their reusability. Then they are analyzed with respect to their business models.

[2] EMV® QR Code Specification for Payment Systems Merchant Presented Mode, Version 1.0, July 2017

4.1. QR Codes according to their reusability

QR codes that support a wide variety of payment services such as e-commerce, in-store physical payments, and corporate / invoice payments are grouped into two categories as static QR codes and dynamic QR codes according to their content variability and reusability.

The QR code rules in this document cover both static and dynamic QR codes.

4.1.1. Static QR Codes

In static QR codes, the QR code content is fixed, and a single QR code can be used for more than one payment process. A static QR code, which is generally preferred by small businesses and sellers (Simit [Turkish bagel] sellers, florists, kiosks, etc.), is obtained by the merchant from a QR code generator and basically includes the account information of the merchant. The consumer scans this QR code through their mobile applications, views the information about the transaction extracted from the QR code, and initiates the payment process.

4.1.2. Dynamic QR Codes

Dynamic QR codes are generated uniquely for each individual payment and are intended for single-use only.

Accordingly, a dynamic QR code contains a unique reference information specific to itself. The information specific to the payment transaction (amount, invoice number, etc.) may also be included in a dynamic QR code, in addition to the merchant information included in the static QR codes.

4.2. QR Codes according to their business models

4.2.1. Merchant Presented QR Codes

4.2.1.1.Merchant Presented Long QR Code

Merchant presented QR code business flow (both long and short type) is based on the principle of scanning the QR code, generated and presented by the merchant, through the consumer's application (their PSP’s application or third-party application) and initiating the payment process.

Figure 1 depicts an example basic workflow regarding the use of a merchant presented long QR code.

Figure 1: Merchant Presented Long QR Code Example Workflow

1. The merchant starts the process of generating a QR code by entering the amount of the purchase.

2. Merchant generates and displays the QR code containing its account information and payment details.

2a. In the case of dynamic QR code, it is possible for the merchant, depending on their preference and business model, to requesttheir PSP to generate the QR code and display it on their device (e.g. POS) by establishing an online connection.

3. The consumer scans the QR code through the application they use. In the case of static QR code, the consumer may enter the amount of transaction information and, if any, additional information regarding the payment (e.g. invoice number, payment reference information) through the application.

4. The consumer checks the payment information and approves the transaction, and directs it to their PSP.

5. The consumer’s PSP checks the payment request and the customer's balance, creates the payment message, and submits it to the payment system.

6. The payment system validates the payment with the payment service providers, and makes its settlement if required by the payment method.

7. Notification of the payment transaction result:

7a. The payment system submits the result of the payment to the relevant payment service providers.

7b. The merchant’s PSP sends a notification message to the merchant, and the consumer’s PSP to the consumer, informing of the completion of the payment transaction.

The above workflow may vary depending on the method and the business model used.

4.2.1.2.Merchant Presented Short QR Code

A short QR code is a QR code with limited data capacity and content, which is used when all the data required for the payment transaction cannot be stored or it is not preferred to include the information of the QR code user explicitly in the QR code for various reasons such as security concerns.

In the Merchant Presented Short QR Code workflow, fundamentally, there is a unique reference number (and hash value that can be added optionally) created by the QR code generator (merchant’s PSP) instead of the information regarding the payment transaction details. The consumer, who scans the QR code via an application, uses this reference number to obtain the payment-related information from the merchant’s PSP through their own PSP. After this stage, the actual payment process starts.

Figure 2 depicts an example basic workflow regarding the use of merchant presented short QR code.

Figure 2: Merchant Presented Short QR Code Example Workflow

1. The merchant starts the process of generating a short QR code by entering the amount of the purchase.

2. The merchant’s PSP generates the short QR code and sends it to the merchant as follows:

2a. The merchant requests a short QR code from its PSP by sending payment details.

2b. The merchant’s PSP generates the short QR code containing the transaction-specific reference information and sends it to the merchant using its online connection.

3. The consumer scans the QR code through the application they use.

4. The consumer sends the QR code content (i.e. the transaction-specific reference information) to their PSP through the application they use.

5. The consumer’s PSP requests payment details and the merchant’s account information using the QR code content (i.e. the reference number) from the merchant’s PSP that generated that QR code, through the QR Code Switch System.

6. The merchant’s PSP validates the QR code content (including the transaction-specific reference information), and prepares the requested data for the payment and merchant information.

7. Payment details and merchant information approval by the consumer:

7a. The merchant’s PSP sends the requested data to the consumer’s PSP through the QR Code Switch System.

7b. The consumer’s PSP requests confirmation from the consumer to approve the payment details and the merchant information.

8. The consumer checks payment and merchant details and initiates the payment through their application.

9. The consumer submits the payment request to their PSP.

10. The consumer’s PSP checks the payment request and the customer's balance, creates the payment message, and submits it to the payment system.

11. The payment system validates the payment with the payment service providers, and makes its settlement if required by the payment method.

12. Notification of the payment transaction result:

12a. The payment system submits the result of the payment to the relevant payment service providers.

12b. The merchant’s PSP sends a notification message to the merchant, and the consumer’s PSP to the consumer, informing of the completion of the payment transaction.

The above workflow may vary depending on the method and the business model used.

4.2.2. Consumer Presented QR Code

In Consumer Presented QR Code-based payment transactions, the consumer who will make the payment generates and displays the QR Code by selecting the QR code option on their application. The generated QR code contains account details or card details (or an identifier/indicator that will address this information). The merchant scans the QR Code with its QR scanner and initiates the payment transaction.

Since the data transfer will be from the consumer’s device to the merchant’s device, the QR code does not include any merchant related information.

Figure 3 depicts an example basic workflow regarding the use of consumer presented QR code.

Figure 3: Consumer Presented QR Code Example Workflow

1. The consumer generates a QR Code on their application by selecting the QR code option for their account or card that they want to use for the payment.

2. The merchant scans the QR code using their QR scanner device.

3. The merchant’s application prepares the payment request using the payment details and the QR data, and then, sends this request to their PSP.

4. The merchant’s PSP sends this request to the consumer’s PSP through the QR Code Switch System.

5. The consumer's PSP sends a confirmation request to the consumer containing payment and merchant details:

5a. The consumer’s PSP sends the consumer a confirmation message for the payment request (containing information such as the amount, the recipient, etc.), via an SMS or application.

5b. The consumer checks the message content and approves it.

6. The consumer’s PSP checks the payment request, creates the payment message, and submits it to the payment system.

7. The payment system validates the payment with the payment service providers, and makes its settlement if required by the payment method.

8. Notification of the payment transaction result:

8a. The payment system submits the result of the payment to the relevant payment service providers.

8b. The merchant’s PSP sends a notification message to the merchant, and the consumer’s PSP to the consumer, informing of the completion of the payment transaction.

The above workflow may vary depending on the method and the business model used.

4.2.3. QR Code for Person-to-Person Fund Transfer

In this QR Code mode, the recipient of the payment (payee) gives their account information in a QR Code to the sender of the payment (payer) to make person-to-person fund transfers.

The payment process starts when the payee generates and displays the QR Code via their application. The payer, then, scans this QR code and initiates the payment.

The generated QR code contains account details, card details, or an identifier/indicator that will address the account details necessary to initiate the payment.

Since the data transfer will be from the payee’s device to the payer’s device, the QR code does not include any payer-related information.

Figure 4 depicts an example basic workflow regarding the use of QR code for person-to-person fund transfers.

Figure 4: QR Code for Person-to-Person Fund Transfer Example Workflow

1. The payee generates a QR Code on their application by selecting the QR code option for their account or card that they want to use for the fund to be transferred.

2. The payer scans the QR code using their QR scanner device (application).

3. The payer checks the payee details, creates the payment request using the QR Code data and initiates the transfer by submitting the request to their PSP.

4. The payer’s PSP checks the payment request and the payer's balance, creates the payment message, and submits it to the payment system.

5. The payment system validates the payment with the payment service providers, and makes its settlement if required by the payment method.

6. Notification of the payment transaction result:

6a. The payment system submits the result of the payment to the relevant payment service providers.

6b. The payer’s PSP sends a notification message to the merchant, and the payee’s PSP to the payee, informing of the completion of the payment transaction.

The above workflow may vary depending on the method and the business model used.

5. QR Code Specifications For Payments

5.1. QR Code Data Organization and Naming Rules

The data in a QR code are organized as objects in a tree-like structure under the root3. These data objects are basically divided into two classes as primitive data objects and data templates. While primitive data objects can store only one piece of information such as date, amount, reference number, etc., data templates may include one or more primitive data objects and other data templates (Figure 5).

Figure 5: QR Code Data Objects Organization

Each data object in the QR code has a data structure consisting of three fields4 :

• ID code: This is coded as a two-digit numeric value between "00" and "99", and indicates the identity of the object. All data objects in a QR code have a unique ID at the root level or within the data template it is included in. For instance, the data object specified by ID="01" under the root and the data object specified by ID="01" under a data template with ID="62" refer to different data objects.

• Length: A two-digit numeric value between "01" and "99" specifying the length, in characters, of the data value of the object.

• Data value: The value of data that is at least one character and up to 99 characters long as provided in the length field.

Example data object:

A data object with ID=“02”, length=“08” and data value=“20200530” is represented as “020820200530”.

02 08 20200530
ID Length Value

Data values of objects support the following data types:

• String (S): Values represented by any precomposed characters defined in UTF-85.

• Alphanumeric Special (ANS): Values that can be represented by the characters in the alphabet, the digits from “0” to “9”, and punctuation. This is a subset of String.

• Numeric (N): Values that can be represented by all digits from ”0” to ”9”. This is a subset of Alphanumeric Special.

[3] An object that does not appear under any data template.

[4] Due to its limited capacity, ID and length fields are not included in a-merchant presented short TR QR code but only data values with predefined fixed and fixed lengths.

[5] UTF-8: 8-bit Unicode Transformation Format. This refers to the general standard that can represent all universally available characters using one to four one-byte code units.

For the presence of data objects in QR Code data organization, the following notation is used:

• Mandatory (M): The data object shall always be present.

• Optional (O): The data object may be present.

• Conditional (C): The data object shall be present under certain conditions. For example, if only one of two particular data objects shall be present in the QR code, then presence of both of these data objects is specified as conditional. The necessary condition is given in the description of the relevant data object.

The first data object of any TR QR Code shall be the Payload Format Indicator, which specifies the type (business model) of the QR Code, and hence the data organization of the remaining part of the QR content and also its version. This remaining part makes up the data part of the QR code. Applications, after scanning the QR Code and extracting the payload format indicator, should parse this data part accordingly.

In this section, the data organization definitions are presented for the specifications of “Merchant Presented Long QR Code”, “Merchant Presented Short QR Code”, “Consumer Presented QR Code” and “QR Code for Person-to-Person Fund Transfer” (Table 1).

Table 1: Payload Format Indicators by QR Code Business Models

Payload Format Indicator	QR Code Type	Description
“000201”	Merchant Presented Long QR Code	“00”: Field ID “02”: Length “01”: The version number of the EMVCo standard with which the data organization of the QR code is compatible. The constant value for the data organization in this document is "01"6.
“9u”	Merchant Presented Short QR Code	“9”: Field ID u: Application indicator (Also see Payload Format Indicator for application indicators in Table 7)
“8502ss”	Consumer Presented TR Code	“85”: Field ID “02”: Length ss: TR QR Code Version number. The constant value for the data organization in this document (version 1.0) is "10".
“7502ss”	QR Code for Person-to-Person Fund Transfer	“75”: Field ID “02”: Length ss: TR QR Code Version number. The constant value for the data organization in this document (version 1.0) is "10".

[6] TR QR Code version number is different from that of the EMVCo specification and included in data object with sub-ID=“00” (version number) of the data template with ID=“51” (“TR QR Code Identification Data Template”) .

5.2. Merchant Presented QR Code Structures

5.2.1. Merchant Presented Long QR Code Structure

The content of the merchant presented long QR code, as described with an example workflow in section 4.2.1.1, includes the following information:

• Payload Format Indicator (ID=”00”): This first data object of the QR code specifies the type (business model) of the QR code, and hence the data organization of the remaining part of the QR content as well as the version of the EMVCo specification with which it complies.

• Point of Initiation Method (ID=”01”): This specifies whether the QR code can be used only once for a specific transaction (dynamic QR code) or can be used in more than one transaction (static QR code).

• Merchant Account Information (ID=”26”, “30” or “32”): This data template(s) include(s) merchant account information specific to the payment system(s) to be used. For each payment system through which the merchant can accept the payment, the corresponding data template shall be included in this area (“26” for card payments, “30” for FAST payments, and “32” for mobile payments). Note that the merchant may prefer to include one or more of these templates in a single QR code.

• TR QR Code Identification Data (ID=”51”): This template shall contain identification information (such as QR Code version number, QR Code unique reference number, QR code generator ID, QR code creation time, etc.) to uniquely identify the QR code.

• Additional information specific to the merchant such as merchant code, merchant name, country, city, location, etc.

• Merchant’s additional information related to the payment, which are not defined in other parts of the QR code (such as product information, tab, ticket, etc.).

• Information about the payment transaction (amount, currency, tip or convenience fee, etc.).

• Additional information for payment transaction required for various payment flows (such as consumer’s phone number, invoice number, purpose of transaction, etc.).

• Cyclic Redundancy Check (CRC, ID=”63”): This is the calculated checksum used to verify the integrity of the entire QR code.

The CRC, the last data object in the QR code, is calculated according to the ISO / IEC 13239 standard using the '1021' (hex) polynomial and initial value 'FFFF' (hex). The data over which the checksum is calculated shall cover all data objects, including their ID, Length and Value, to be included in the QR code, in their respective order, as well as the ID and the Length of the CRC itself (but excluding its Value).

Following the calculation of the checksum, the resulting 2-byte hexadecimal value shall be encoded as a 4-character Alphanumeric Special value by converting each nibble to the corresponding Alphanumeric character. A nibble with hex value ‘0’ is converted to “0”, a nibble with hexvalue ‘1’ is converted to “1” and so on. Hex values ‘A’ to ‘F’ must be converted to uppercase characters “A” to “F”. For example, a CRC with a two-byte hexadecimal value of ‘097B’ is converted to “097B” and included in the QR code as “6304097B”.

In Table 2, the data organization for merchant presented long QR Code is defined. Data objects (subfields) of the data template objects (with IDs “26” - “46”, “51”, “62” and “64”) are presented in the following tables.

Table 2: Merchant Presented Long QR Code Data Organization

Name	ID	For mat	Length	Presence	Example	Description
Payload Format Indicator	00	N	02	M	000201	Payload Format Indicator for Merchant Presented Long TR QR Code data organization. The fixed ‘01’ value represents the version number of the EMVCo specificationwith which the data organization is compliant.
Point of Initiation Method	01	N	02	M	For Static QR Code: 010211 For Dynamic QR Code: 010212	“11”: Static QR Code, which can be used for more than one transaction. “12”: Dynamic QR Code, which can only be used for a single transaction.
Merchant Account Information	02-46	ANS	varying up to 99	M	For FAST: 30uuVD	Merchant account information templates. The subtemplate(s) for the payment system(s), through which the merchant accepts payment, should be properly created pursuant to rules and principles given in the corresponding technical rules and principle guidance (see Table 3). At least one of the “26-27”, “30-31” and “32” subtemplates shall be included. VD:Template’s data value. uu: Length of the template’s data value (VD).
	02-03	Reserved for VISA				Reserved by EMVCo for EMV members
	04-05	Reserved for Mastercard
	06-08	Reserved for EMVCo
	09-10	Reserved for Discover
	11-12	Reserved for Amex
	13-14	Reserved for JCB
	15-16	Reserved for UnionPay
	17-25	Reserved for EMVCo
	26-27	BKM Card Payments				Refer to “Card Systems (BKM)– TR QR Code Technical Rules and Principles Guidance“ for the data objects of the template
	28-29	Reserved for the BKM
	30-31	FAST				Refer to “FAST – TR QR Code Technical Rules and Principles Guidance“ for the data objects of the template
	32	Mobile Payments				Refer to “Mobile Payments – TR QR Code Technical Rules and Principles Guidance“for the data objects of the template
	33-40	Reserved for the CBRT

Name	ID	Format	Length	Presence	Example	Description
	41-46	Reserved for other payment systems in Turkey				Payment system operators should apply to to the CBRT to use these fields.
Free Templates for merchants	47-48	ANS	varying up to 99	O	47uuVD 48uuVD	Merchants can use these templates for additional payment details that are not defined in the other fields of the QR code (such as product/service name(s), tab, etc.) VD: Template’s data value. uu: Length of the template’s data value (VD).
Merchant Code	49	N	10	O	4910002341567 2	Merchant’s unique reference code registered in the National Merchant Registration System. If the data length is less than 10 digits, ‘0’s are padded to the left of the value to complete it.
Location	50	N	varying betwee n16-34	O	For the location with latitude 39.939423 and longitude 32.851791: 5016399394233 2851791	Location information generated in Decimal Degrees (DD) format. Location data value consists of latitude (first half) and longitude (second half) information with equal length. Location data value for Latitude: EE.eeeeee and Longitude: BB.bbbbbb is coded as EEeeeeeeBBbbbbbb The value shall not include any separators like ‘.’ or ‘,’. The lengths of ‘e’ and ‘b’ are the same and each can be between 6 and 15 according to the prefered accuracy level.
TR QR Code Identification Data Template	51	ANS	varying up to 99	M	51uuVD	QR Code’s identification data template generated by the OR code generator. The data objects of the template are shown in Table 4. VD: Template’s data value. uu: Length of the template’s data value (VD).
Merchant Category Code	52	N	04	M	52045499	This field should indicate Merchant Category Code, MCC, as defined by ISO 18245:2003. If the field is not necessary, use the value “0000”.
Transaction Currency	53	N	03	M	5303949	The transaction currency shall contain 3-digit numeric representation of the currency as defined by ISO 4217. For example: TRY: “949”, USD: “840”, EUR: “978”.

Name	ID	Format	Length	Presence	Example	Description
Transaction Amount	54	N	12	O	For 1.23: 5412000000000 123	This field shall contain the transaction amount. It does not include tip or convenience fees of the field “55”, if present. Amount value consists of only (numeric) digits from “0” to “9” and shall not contain other characters such as “.” or “,”. Rightmost 2 digits represent the decimal part of the amount (kuruş, cent, etc.). If the data length is less than 12 digits, “0”s are padded to the left of the value to complete it. If this field is not present, the application should prompt the consumer to enter the amount to be paid to the merchant, or a subfield in the corresponding payment system’s merchant account information template may have an indicator in order for the consumer to enter the amount.
Tip or Convenience Indicator	55	N	02	O	550201	If present, the tip or convenience indicator shall contain the following values: “01”: if mobile application should prompt the consumer to enter a tip to be paid to the merchant “02”: Indicates inclusion of the data object Value of Convenience Fee Fixed (field ID “56”) . “03”: Indicates inclusion of the data object Value of Convenience Fee Percentage (field ID “57”).
Value of Convenience Fee Fixed	56	N	12	C	For 2.50: 56120000000002 50	The value of convenience fee fixed shall be present and different from zero if the data object with ID “55” is present with a value of “02”. Rightmost 2 digits represent the decimal part of the amount (kuruş, cent, etc.). If the data length is less than 12 digits, “0”s are padded to the left of the value to complete it.
Value of Convenience Fee Percentage	57	N	05	C	For 3.25%: 570500325	The value of convenience fee percentage shall be present if the data object with ID “55” is present with a value of “03”.

Name	ID	Format	Length	Presence	Example	Description
						Rightmost 2 digits represent the decimal part of the percentage. The percentage value of the transaction amount included in the field with ID “54” constitutes the value of convenience fee. The value is completed by padding “0”s in order to get a 5-digit length.
Country Code	58	ANS	02	M	5802TR	Country Code should indicate the country in which the merchant transacts. It should have a value as defined by ISO 3166-1 alpha 2. For Turkey, the code is “TR”.
Merchant Name	59	ANS	varying up to 25	M	5907ABCKAFE	Merchant name should indicate the “doing business as” name for the merchant.
Merchant City	60	ANS	varying up to 15	M	6008İSTANBUL	Merchant city should indicate the city of the merchant’s physical location.
Postal Code	61	ANS	varying up to 10	O	610534100	Merchant postal code, if present, should indicate the postal code of the merchant’s physical location.
Additional Data Field Template	62	S	varying up to 99	O	62uuVD	If present, this template shall contain additional data required by the merchant for the transaction. Refer to Table 5 for data objects that can be used in the template. VD: Template’s data value. uu: Length of the template’s data value (VD).
Merchant Information-Language Template	64	S	varying up to 99	O	64uuVD	If present, this template shall contain merchant’s information ( name, city) in an alternate (usually local) language. The template’s data objects are presented in Table 6. VD: Template’s data value. uu: Length of the template’s data value (VD).
RFU for EMVCo	65-79	S	varying up to 99	O	-	Reserved for EMVCo for future use.
Unreserved Templates	80-99	S	varying up to 99	O	-	Reserved by the CBRT for future use for the TR QR Code.
CRC	63	ANS	04	M	63040D9E	CRC value calculated over all the data which shall cover all data objects (ID, length, value) in their respective order including ID and length of the CRC itself (but excluding its value). CRC is the last data object of the QR Code.

The merchant account information templates with IDs “26”-“27”, “30”-“31” and “32” are allocated for BKM card systems, the FAST system, and mobile payments, respectively. Issues concerning the data objects of these templates and relevant workflows are covered by the corresponding “Technical Rules and Principles Guidance” documents.

The merchant account information template includes data for the merchant’s ID and account information. Payment system operators can define the data structures of their merchant account information in the template allocated for them. One or more merchant account information templates, each belonging to a different payment system, can be included in the same QR Code. In this case, the consumer will have the opportunity to choose the payment system (Credit card, FAST, mobile payment) they want to use through the application that scans the QR Code.

Other than the templates allocated for EMVCo members with IDs "02" - "25", the templates from ID=“26” to ID=“51” are left for the use of the countries’ payment systems. In Turkey, the allocation of these templates are defined as follows:

26-27: Used by Card Systems (BKM)– TR QR Code.

28-29: Reserved for the BKM for future use.

30-31: Used by FAST – TR QR Code.

32 : Used by Mobile Payments – TR QR Code.

33-40: Reserved for the CBRT for future use.

41-46: Reserved for other payment systems in Turkey. Payment system operators who would like to use these templates shall apply to the CBRT.

47-48: Can be used by merchants for their additional information related to the payment which are not defined in other parts of the QR code (such as product information, tab, ticket, etc.) in order to carry these data within the QR code.

49: Used to store the merchant’s unique ID in the National Merchant Registration System.

50: Used to store the merchant’s location information.

51: Used for the data template “TR QR Code Identification Data” of the QR code generated (see Table 4).

Table 3: Data Objects for Merchant Account Information Template (IDs: “26” to “46”)

Name	ID	Format	Length	Presence	Example	Description
Universally Unique ID	00	ANS	varying up to 32	O	0016TR.GOV. TCMB.FAST	An identifier that sets the content of the data that follows. The value is one of the following: • An application identifier (AID) • Universally Unique Identifier (UUID) of the Payment System as defined in the Internet Engineering Task Force (IETF) RFC 4122. • A reverse domain name
Payment Network specific	01-99	ANS	varying up to 99	M	-	Association of data object is specific to the payment system

Data objects in “TR QR Code Identification Data” template with ID=“51” for the QR code generated are defined in Table 4.

Table 4: Data Objects for TR QR Identification Template (ID: “51”)

Name	ID	Format	Length	Presence	Example	Description
Version Number	00	N	02	M	For the data organization in this specification (version 1.0): 000210	TR QR Code Version Number. For version “S.s”,the data value of “Ss” is used without punctuation mark ‘.’
QR Code Generator ID	02	N	04	M	02040064	Generator’s (PSP) unique identifier of the QR Code. Payment service providers, and payment system operators approved by the CBRT can get the TR QR Code generator ID by applying for registration to the BKM, in order to be able to generate the TR QR Code. Banks can use their EFT codes and they do not have to make an additional application. If the data length is less than 4 digits, ‘0’s are padded to the left of the value to complete it.
QR Code Reference Number	03	ANS	varying up to 12	C	030823451017	A unique reference value for the TR QR Code. It can be provided by the merchant application or by the QR Code Generator PSP. It is used for end-to-end validation, transaction recording, producing receipts, etc. This value could be provided by the merchant, or could be an indication for the mobile application to prompt the consumer to input the reference number.This field is mandatory for dynamic QR codes but optional for static ones.
Terminal Type	04	N	02	O	For the POS device: 040202	Device type on which the QR Code is generated and displayed. Predefined values: “01”:Static QR code “02”:POS/mPOS/PaymentRecordingDevices/ Kiosk etc. (payment accepting software and hardware) “03”: ATM “04”: Merchant application “05”: Web “06”: PSP’s merchant application
Terminal Device Serial Number	05	ANS	varying up to 23	O	05231234567890 1234567890ABC	TR QR Code generating/displaying device’s or terminal’s distinguishing value (for example, terminal number and/or terminal serial number).

Name	ID	Format	Length	Presence	Example	Description
QR Code Generation Time	06	N	12	M	For 29 May 2020 14.01:59: 06122005291401 59	QR Code generation time. YYMMDDhhmmss YY: year, MM: Month, DD: Day, hh: Hour (24 hour), mm: Minute, ss: Second
QR Code Expiration Time	07	N	12	C	For 29 May 2020 15.01:59: 07122005291501 59	QR Code expiration time. YYMMDDhhmmss YY: year, MM: Month, DD: Day, hh: Hour (24 hour), mm: Minute, ss: Second This field is mandatory for dynamic QR codes but optional for static ones.

Data objects in “Additional Data Fields” template with ID=“62” for the addional payment information are defined in Table 5.

Since the total size of the template must not exceed the maximum allowed length of 99 characters, the data objects with presence status “optional” should be determined in the QR code in view of this limit, and the QR code should be generated accordingly.

Table 5: Data Objects for Additional Data Fields Template (ID: “62”)

Name	ID	Format	Length	Presence	Example	Description
Bill Number	01	ANS	varying up to 25	O	010854 60980A	Invoice or bill number. This number could be provided by the merchant, or could be an indication for the mobile application to prompt the consumer to input a bill number.
Mobile Number	02	ANS	varying up to 15	O	021290 312507 5000	Consumer’s mobile number. This number could be provided by the merchant, or could be an indication for the mobile application to prompt the consumer to input a mobile number.
Store Label	03	ANS	varying up to 25	O	0306AVMS TR	A distinctive value associated to a store. This value could be provided by the merchant, or could be an indication for the mobile application to prompt the consumer to input a store label. This label may be displayed to the consumer by the mobile application to identify a specific store.
Loyalty Number	04	ANS	varying up to 25	O	04102315 634123	Consumer’s loyalty card number. This value could be provided by the merchant, or could be an indication for the mobile application to prompt the consumer to input their loyalty number.
Customer Label	06	ANS	varying up to 25	O	06100518 894111	Any end-to-end value identifying a specific consumer such as a subscriber ID for subscription services, a student enrolment number, etc. This value could be provided by the merchant (if known), or could be an indication for the mobile application to prompt the consumer to input their customer label.
Purpose of Transaction	08	ANS	varying up to 5	O	080206	Any value defining the purpose of the transaction. This value could be provided by the merchant, or could be an indication for the mobile application to
						prompt the consumer to input a value describing the purpose of the transaction. The purpose of transaction shall have the values defined in the corresponding payment system guidances.
Additional Consumer Data Request	09	ANS	varying up to 3	O	0901M	Contains indications that the mobile application is to provide the requested additional information in order to complete the transaction. The information requested should be provided by the mobile application in the authorization without unnecessarily prompting the consumer. One or more of the following characters may appear in the value (each unique character should appear only once): “A” : Address of the consumer, “M”: Mobile number of the consumer, “E” : E-mail address of the consumer. If more than one character is included, each data object corresponding to the character is required to initiate the transaction.
	10-49	Reserved by EMVCo
	51-99	Payment System Specific Fields

The merchant can indicate its “doing business as” name and the city in which it transacts using an alternate (local) language. If this is the case, the merchant may include the data template “Merchant Information-Language” with ID=”64” in the QR code as defined in Table 6.

Table 6: Data Objects for Merchant Information-Language Template (ID: “64”)

Name	ID	Format	Length	Presence	Example	Description
Language Preference	00	ANS	02	M	0002TR	Language Preference shall contain 2 alphabetical characters coded to a value defined by ISO 639-1. For example: “TR”: Turkish “EN”: English The value should represent the single language used to encode the Merchant Name-Alternate Language (sub field:”01”) and the optional Merchant City-Alternate Language (sub field:”02”). If this template is present, it shall contain the Language Preference.
Merchant Name-Alternate Language	01	S	varying up to 50	M	0108AĞAÇ A.Ş.	The Merchant Name-Alternate Language should indicate the “doing business as” name for the merchant in the merchant’s alternate language (typically the local language).
Merchant City-Alternate Language	02	S	varying up to 25	O	0208İSTA NBUL	The Merchant City-Alternate Language should indicate the city in which the merchant transacts in the merchant’s alternate language.
RFU by EMVCo	03-99	S	varying up to 99	-	-	Data objects reserved for future use by EMVCo.

5.2.2. Merchant Presented Short QR Code Structure

Short QR codes are used to obtain payment details via an online connection between payment service providers by using a unique reference number transmitted within the QR code in cases where the QR presenting device cannot display the payment details due to insufficient resolution and capacity or because the merchant does not prefer to transmit them directly in the QR code for various reasons, including security concerns (see Section 4.2.1.2.).

The following points should be noted for short QR codes whose data organization is defined in Table 7:

• In short QR data organizations, data objects do not have ID and length fields due to the limited data capacity.

• The lengths of data objects, except the last data object named “Other Data”, are fixed by the sizes as given in Table 7. If the size of the value belonging to a data object (except the “Other Data”) is less than its fixed length, then the value of the data object should be padded with spaces (‘ ‘ character) to the right of the value to complete it (so that the data value is formed as left justified). Exceptionally, the last data object named “Other Data” can be used in variable length.

• As in the long QR code, the CRC value is calculated according to the ISO / IEC 13239 standard using the '1021' (hex) polynomial and initital value 'FFFF' (hex). The data over which the checksum is calculated shall cover all the data objects’ values (except the CRC value, including the “Other Data” if any) in their respective order.

• Following the calculation of the checksum, the resulting 2-byte hexadecimal value shall be encoded as a 4-character Alphanumeric Special value by converting each nibble to the corresponding Alphanumeric character. A nibble with hex value ‘0’ is converted to “0”, a nibble with hexvalue ‘1’ is converted to “1” and so on. Hex values ‘A’ to ‘F’ must be converted to uppercase characters “A” to “F”. For example, a CRC with a two hexadecimal value of ‘097B’ is converted to “097B” and placed in the CRC’s defined area in the QR code as “097B”.

Table 7: Merchant Presented Short QR Code Data Organization

Name	Format	Length	Presence	Example	Description
Payload Format Indicator	N	02	M	For FAST Short QR Code: 97	Payload format indicator for short QR Code data organization “99”: BKM Cards System Merchant Presented Short QR Code “98”: ATM QR Code “97”: FAST Merchant Presented Short QR Code “96”7: FAST and BKM Merchant Presented Short QR Code 94-95: Reseverved for CBRT and BKM for future use 90-93: Reserved for other short QR codes
QR Code Generator ID	N	04	M	0064	Generator’s (PSP) unique identifier of the TR QR Code. It will be provided and registered by the BKM. Banks can use their EFT codes. If the data length is less than 4, ‘0’ characters are padded to the left of the value to complete it.

[7] The payload format indicator value where the merchant and merchant’s PSP accepts both BKM card payment and FAST payment. The consumer will have the opportunity to select one of these payment methods after scanning the QR code by their application.

Name	Format	Length	Presence	Example	Description
QR Code Reference Number	ANS	12	C	AB345678 9012	A unique reference value for the TR QR Code created by the merchant’s PSP non-consecutively. Optional for the “98: ATM QR Code” but mandatory for the other short QR codes.
Hash	ANS	32	O	702324AB 900DD34 EF7FB677 23AE4C0F C	Hash value calculated by the QR Code Generator PSP over the selected QR fields and/or any additional data kept by the PSP. The QR Code Generator PSP can check and validate their QR code by making use of this field.
CRC	ANS	04	O	7D41	CRC value calculated over the data which shall cover all data object values in their respective order, excluding this field.
Other Data	ANS	varying up to 214	O	-	The short QR code generator can use this last field freely.

5.3. Consumer Presented QR Code Structure

The content of the consumer presented QR code, as described with an example workflow in section 4.2.2, includes the following information:

• Payload Format Indicator (ID=”85”): This first data object specifies the type (business model) of the QR code (“85” for consumer presented QR code) and TR QR Code version number, hence the data organization of the remaining part of the QR code content.

• QR code-specific information:

  • Point of Initiation Method (ID=”01”), which indicates the QR Code type specifying the static or dynamic classification.

  • QR Code Generator ID (ID=”02”).

  • Unique Reference Number specific to the QR code (ID=”03”) when the QR code is dynamic.

  • Commercial Transaction Indicator specifying whether the transaction is a commercial one or not (ID=”04”).

  • QR code’s creation time (ID=”06”) and expiration time (ID=”07”).

  • Hash value calculated by the QR code generator (ID=”20”).

  • Location (ID=”50”).

• Mobile Payment Template (ID=“32”): This is the data template used for mobile payment transactions in which the consent of the payer to execute a payment transaction is given by means of any telecommunication, digital or IT device and the payment is made to the telecommunication, IT system or network operator that acts only as an intermediary between the payment service user and the supplier of the goods and services. If this data template is present, the use of the application template (ID=”61”) is optional.

• Application Template (ID=”61”): The application template includes information about the consumer and the application they use. In an application template, only one field out of the account number (IBAN) (ID=”01”), card number (ID=”02”) and easy addressing type (ID=”04”) fields can be used.

Since the total size of the template must not exceed the maximum allowed length of 99 characters, the data objects with presence status “optional” should be determined in the QR code regarding this limit, and the QR code should be generated accordingly.

If the mobile payment template (ID=”32”) is present, the use of application template for one or more times is optional. Otherwise, more than one application template can be used within the same QR code, with at least one being mandatory.

• Cyclic Redundancy Check (CRC, ID=”63”): This is the calculated checksum used to verify the integrity of the entire QR code.

The CRC, the last data object of the QR code, is calculated according to the ISO / IEC 13239 standard using the '1021' (hex) polynomial and the initital value 'FFFF' (hex). The data over which the checksum is calculated shall cover all the data objects (ID, length and value) to be included in the QR code in their respective order, as well as the ID and the length of the CRC itself (but excluding its value).

Following the calculation of the checksum, the resulting 2-byte hexadecimal value shall be encoded as a 4-character Alphanumeric Special value by converting each nibble to the corresponding Alpahanumeric character. A nibble with hex value ‘0’ is converted to “0”, a nibble with hexvalue ‘1’ is converted to “1” and so on. Hex values ‘A’ to ‘F’ must be converted to uppercase characters “A” to “F”. For example, a CRC with a two hexadecimal value of ‘097B’ is converted to “097B” and placed in the QR code as “6304097B”.

Table 8 shows the data organization for consumer presented QR Code.

Table 8: Consumer Presented QR Code Data Organization

Name	ID	Sub ID-Name	Format	Length	Presence	Example	Description
Payload Format Indicator	85	-	N	02	M	For the data organization in this document (version 1.0): 850210	Payload Format Indicator for Consumer Presented QR Code data organization. The last 2 digits (value field) represent the version of the TR QR Code data organization. For version “S.s”, the value used in the last 2 digits is “Ss” (without “.” character).
Point of Initiation Method	01	-	N	02	M	For static QR Code: 010211 For dynamic QR Code: 010212	Used to make a distinction between static and dynamic QR codes. Data values are: “11”: Static QR Code, which can be used for more than one transaction. “12”: Dynamic QR Code, which can only be used for a single transaction.
QR Code Generator ID	02	-	N	04	M	02040064	Generator’s (PSP) unique identifier of the QR Code. Payment service providers, and payment system operators approved by the CBRT can get a TR QR Code generator ID by applying for registration to the BKM, in order to be able to generate a TR QR Code. Banks can use their EFT codes and they do not have to make an additional application. If the data length is less than 4 digits, ‘0’ characters are padded to the left of the value to complete it.
QR Code Reference Number	03		ANS	varying up to 12	C	030823451017	A unique reference value for the TR QR Code. This field is mandatory for dynamic QR codes but optional for static ones.
Commercial Transaction Indicator	04		N	01	O	For a commercial transaction: 04011	This field is used as an indicator of whether the payment made by the QR code is a commercial transaction: “0”: Not commercial “1”: Commercial

Name	ID	Sub ID-Name	Format	Length	Presence	Example	Description
QR Code Generation Time	06		N	12	O	For 29 May 2020 at 14.01:59: 061220052914 0159	QR Code generation time. YYMMDDhhmmss YY: year, MM: Month, DD: Day, hh: Hour (24 hours), mm: Minute, ss: Second
QR Code Expiration Time	07		N	12	O	For 29 May 2020 at 15.01:59: 071220052915 0159	QR Code expiration time. YYMMDDhhmmss YY: year, MM: Month, DD: Day, hh: Hour (24 hour), mm: Minute, ss: Second
Mobile Payment Template	32		ANS	varying up to 99	O	32uuVD	Mobile payment data template. Refer to “Mobile Payments – TR QR Code Technical Rules and Principles Guidance“ for the data objects of the template, VD:Template’s data value. uu: Length of the template’s data value (VD).
Application Template	61		ANS	varying up to 99	C	61uuVD	Template for consumer account information or account proxy. This template can be used one or more times if the mobile payment template (ID=”32”) is used. Otherwise, more than one application template can be used, with at least one being mandatory VD: Template’s data value. uu: Length of the template’s data value (VD).
		01: Account Number (IBAN)	ANS	26	C	0126TR1234 5678901234 5678901234	Consumer’s account number (IBAN) to be used in the payment. Only one field, out of this field (ID=”01”), the card number field (ID=“02”) and the easy addressing field (ID=“04”), should be used.
		02: Card Number	ANS	varying up to 16	C	0216510112 3456789012	Consumer’s card number to be used in the payment. The value is created without using spaces and ‘-‘, etc. Only one field, out of this field (ID=”02”), the account number field (ID=“01”) and the easy addressing field (ID=“04”), should be used.
		03: Card Expiry Date	N	04	C	For July 2021: 03042107	If card number (ID=“02”) is present, then this field contains card’s expiry date in the form of YYMM: YY: Year
							MM: Month
		04: Easy Addressing Type	S	01	C	For phone number: 0401T	If easy addressing (KOLAS) is used for the account, then this field indicates the type of easy addressing. According to the following predefined indicator values, a suitable easy addressing value should be provided in ID=”05” (Please refer to “FAST Easy Addressing Reference Document” for up-to-date values): “T”: Phone number “K”: National Identification Number “V”: Tax Identification Number “Y”: Foreigner Identification Number “E”: E-mail address Only one field, out of this field (ID=”04”), the account number field (ID=“01”) and the card number field (ID=“02”), should be used.
		05: Easy Addressing Value	ANS	varying up to 50	C	For phone number: 0512903121 234567	If the easy addressing type field (ID=”04”) is present, this field should include a valid easy addressing value suitable for that type.
		06: Customer Number	ANS	varying up to 25	O	0605A2451	A consumer label transferred end to end to identify the consumer such as a subscription number, a membership number, etc.
		07: Customer Name and Surname	ANS	varying between2-26	C	0711HASAN YILDIZ	Consumer’s name and surname for this application. Mandatory when account number (ID=“01”) is used, optional otherwise.
		10-20	ANS	varying up to 25	O	-	Free data fields not defined in other data objects of the QR code.
Hash	20		ANS	varying up to 32	O	2032A23ED34 AEAE0F712AEF CB9054ED180 EC	Hash value calculated by the QR Code Generator PSP over the selected QR code fields and/or any additional data kept by the PSP. The QR Code Generator PSP can check and validate the QR code by making use of this field.

Name ID
Sub ID-
Name
For mat Length Presence Example Description
Location 50 N varying betwee n16-34
O
For the location with latitude
39.939423 and
longitude
32.851791:
50163993942
332851791
Location information generated in Decimal Degrees format.
Location data value consists of latitude (first half) and longitude (second half) information with equal length.
Location data value for
Latitude: EE.eeeeee and
Longitude: BB.bbbbbb is coded as
EEeeeeeeBBbbbbbb
The value shall not include any separators like ‘.’ or ‘,’.
The lengths of ‘e’ and ‘b’ are the same and each can be between 6 and 15 digits according to the prefered accuracy level.
CRC 63 - ANS 04 M 63040D9E
CRC value calculated over the data which shall cover all data objects (ID, length, value) in their respective order including ID and length of the CRC itself (but excluding its value).
CRC is the last data object of the
QR Code.

5.4. QR Code for Person-to-Person Fund Transfer

The content of the QR code for person-to-person fund transfers, as described with an example workflow in section 4.2.3, includes the following information:

• Payload Format Indicator (ID=”75”): This first data object specifies the type (business model) of the QR code (“75” for QR code for person-to-person fund transfers) and the TR QR Code version number, hence the data organization of the remaining part of the QR code content.

• QR code-specific information:

  • Point of Initiation Method (ID=”01”), which indicates the QR Code type specifying the static or dynamic classification.

  • QR Code Generator ID (ID=”02”).

  • Unique Reference Number specific to the QR code (ID=”03”) when the QR code is dynamic.

  • QR code’s creation time (ID=”06”) and expiration time (ID=”07”).

  • Transaction amount (ID=”54”).

  • Hash value calculated by QR code generator (ID=”20”).

  • Location (ID=”50”).

• Application Template (ID=”61”): The application template includes information about the payee and the application they use. In an application template, only one field out of the account number (IBAN) (ID=”01”), card number (ID=”02”) and easy addressing type (ID=”04”) fields can be used.

Since the total size of the template must not exceed the maximum allowed length of 99 characters, the data objects with presence status “optional” should be determined in the QR code regarding this limit, and the QR code should be generated accordingly.

There may be more than one application template in the same QR code, with at least one being mandatory.

• Cyclic Redundancy Check (CRC, ID=”63”): This is the calculated checksum used to verify the integrity of the entire QR code.

The CRC, the last data object of the QR code, is calculated according to the ISO / IEC 13239 standard using the '1021' (hex) polynomial and the initial value 'FFFF' (hex). The data over which the checksum is calculated shall cover all the data objects (ID, length and value) to be included in the QR code in their respective order, as well as the ID and the length of the CRC itself (but excluding its value).

Following the calculation of the checksum, the resulting 2-byte hexadecimal value shall be encoded as a 4-character Alphanumeric Special value by converting each nibble to the corresponding Alphanumeric character. A nibble with hex value ‘0’ is converted to “0”, a nibble with hexvalue ‘1’ is converted to “1” and so on. Hex values ‘A’ to ‘F’ must be converted to uppercase characters “A” to “F”. For example, a CRC with a two hexadecimal value of ‘097B’ is converted to “097B” and placed in the QR code as “6304097B”.

Table 9 shows the data organization for the QR code for person-to-person fund transfer.

Table 9: Data Organization for the QR Code for Person-to-Person Fund Transfer

Name	ID	Sub ID-Name	Format	Length	Presence	Example	Description
Payload Format Indicator	75		N	02	M	For the data organization in this document (version 1.0): 750210	Payload Format Indicator for the data organization of the QR Code for Person-to-Person Fund Transfer. The last 2 digits (value field) represent the version of the TR QR Code data organization. For version “S.s”, the value used in the last 2 digits is “Ss” (without “.” character).
Point of Initiation Method	01		N	02	M	For static QR Code: 010211 For Dynamic QR Code: 010212	Used to make a distinction between static and dynamic QR codes. Data values are: “11”: Static QR Code, which can be used for more than one transaction. “12”: Dynamic QR Code, which can only be used for a single transaction.
QR Code Generator ID	02		N	04	M	02040067	Generator’s (PSP) unique identifier of the QR Code. Payment service providers, and payment system operators approved by the CBRT can get a TR QR Code generator ID by applying for registration to the BKM, in order to be able to generate a TR QR Code. Banks can use their EFT codes and they do not have to make an additional application. If the data length is less than 4 digits, ‘0’ characters are padded to the left of the value to complete it.
QR Code Reference Number	03		ANS	varying up to 12	C	030823451017	A unique reference value for the TR QR Code. This field is mandatory for dynamic QR codes but optional for static ones.
QR Code Generation Time	06		N	12	O	For 29 May 2020 at 14.01:59: 061220052914 0159	QR Code generation time. YYMMDDhhmmss YY: year, MM: Month, DD: Day, hh: Hour (24 hour), mm: Minute, ss: Second
QR Code Expiration Time	07		N	12	O	29 May 2020 15.01:59: 071220052915 0159	QR Code expiration time. YYMMDDhhmmss YY: year, MM: Month, DD: Day, hh: Hour (24 hours), mm: Minute, ss: Second

Name	ID	Sub ID-Name	Format	Length	Presence	Example	Description
Amount	54		N	12	O	For 1.23: 541200000000 0123	This field shall contain the transaction amount. The amount value consists of only (numeric) digits from “0” to “9” and shall not contain other characters such as “.” or “,”. Rightmost 2 digits represent the decimal part of the amount (kuruş, cent, etc.). If the data length is less than 12 digits, “0”s are padded to the left of the value to complete it.
Application Template	61		ANS	varying up to 99	M	61uuVD	More than one application template can be used, with at least one being mandatory. VD: Template’s data value. uu: Length of the template’s data value (VD).
		01: Account Number (IBAN)	ANS	26	C	0126TR12345 67890123456 78901234	Payee’s account number (IBAN) to accept the payment. Only one field, out of this field (ID=”01”), the card number field (ID=“02”) and the easy addressing field (ID=“04”), should be used.
		02: Card Number	N	16	C	02165101567 832141234	Payee’s card number to accept the payment. The value is created without using spaces and ‘-‘, etc. Only one field, out of this field (ID=”02”), the account number field (ID=“01”) and the easy addressing field (ID=“04”), should be used.
		04: Easy Addressing Type	S	01	C	For phone number: 0401T	If easy addressing (KOLAS) is used for the payee’s account, then this field indicates the type of easy addressing. According to the following predefined indicator values, a suitable easy addressing value should be provided in ID=”05” (Please refer to “FAST Easy Addressing Reference Document” for up-to-date values): “T”: Phone number “K”: National Identification Number “V”: Tax Identification Number “Y”: Foreigner Identification Number “E”: E-mail address Only one field, out of this field (ID=”04”), the account number field

Name	ID	Sub ID-Name	Format	Length	Presence	Example	Description
		05: Easy Addressing Value	ANS	varying up to 50	C	For phone number: 05129053012 34567	(ID=“01”) and the card number field (ID=“02”), should be used. If easy addressing type field (ID=”04”) is present, this field should include a valid easy addressing value suitable for that type.
		07: Payee Name and Surname	ANS	varying between 2-26	C	0711HASANYI LDIZ	Payee’s name and surname for this application. Mandatory when account number (ID=“01”) is used, optional otherwise.
		10-20	ANS	varying up to 25	O	-	Free data fields not defined in other data objects of the QR code.
Hash	20		ANS	varying up to 32	O	2032A23ED34A EAE0F712AEFC B9054ED180EC	Hash value calculated by the QR Code Generator PSP over the selected QR code fields and/or any additional data kept by the PSP. The QR Code Generator PSP can check and validate the QR code by making use of this field.
Location	50		N	varying between 16-34	O	For the location with latitude 39.939423 and longitude 32.851791: 501639939423 32851791	Location information generated in Decimal Degrees format. Location data value consists of latitude (first half) and longitude (second half) information with equal length. Location data value for Latitude: EE.eeeeee and Longitude: BB.bbbbbb is coded as EEeeeeeeBBbbbbbb The value shall not include any separators like ‘.’ or ‘,’. The lengths of ‘e’ and ‘b’ are the same and each can be between 6 and 15 digits according to the prefered accuracy level.
CRC	63	-	ANS	04	M	63040D9E	CRC value calculated over the data which shall cover all data objects (ID, length, value) in their respective order including ID and length of the CRC itself (but excluding its value). CRC is the last data object of the QR Code.

6. References

• ISO 3166-1 alpha 2: Codes for the representation of names of countries and their subdivisions Part 1: Country codes, using two-letter country codes

• ISO 4217: Codes for the representation of currencies and funds

• ISO 18245:2003: Retail financial services — Merchant category codes

• ISO/IEC 13239: Information technology—Telecommunications and information exchange between systems—High-level data link control (HDLC) procedures

• ISO 639-1: Codes for the representation of names of languages—Part 1: Alpha - 2 Code

• ISO/IEC 18004: Information technology—Automatic identification and data capture techniques - QR Code bar code symbology specification

• Unicode: Unicode Standard, specifically the UTF-8 encoding form

• IETF RFC 4122: The Internet Engineering Task Force (IETF) RFC 4122

• EMVCo QR Code Specification for Payment Systems, Merchant Presented Mode, Version 1.0, July 2017

• Card Systems (BKM) – TR QR Code Technical Rules and Principles Guidance

• FAST – TR QR Code Technical Rules and Principles Guidance

• Mobile Payments - TR QR Code Technical Rules and Principles Guidance

• FAST Easy Addresing Service Reference