21 August 2020 FRIDAY Official Gazette Issue: 31220

REGULATION

From the Central Bank of the Republic of Turkey:

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

PART ONE

Purpose, Scope, Basis and Definitions

Purpose and scope

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

(2) This Regulation covers payment transactions that fall within the scope of payment services under the Law No. 6493 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions dated 20/6/2013 and that are carried out using QR code.

Basis

ARTICLE 2 – (1) This Regulation has been prepared based on the third and sixth paragraphs of Article 12 and the sixth paragraph of Article 18 of Law No. 6493.

Definitions

ARTICLE 3 – (1) In this Regulation;

a) Recipient: The real or legal person to whom the fund subject to the payment transaction is intended to reach,

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

c) BKM: The Interbank Card Center Joint Stock Company,

ç) Dynamic QR code: The QR code that is generated specifically for the payment transaction to be used and is single-use,

d) Sender: The real or legal person who gives a payment order from their own payment account or without having a payment account,

e) Merchant: The real or legal person who accepts, as the recipient party, that the payment for a good or service price be made using QR codes generated within the scope of the Technical Document,

f) QR code presented by the merchant: The QR code model based on the principle that customers read the QR code presented by the merchant through the application they use and initiate the payment transaction,

g) QR code: The two-dimensional code created to be used in payment transactions by scanning method; storing 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 reader, and having black and white modules in the form of square black-white dots or pixels,

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

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

ı) User: The real or legal person who makes a payment using QR code,

i) Payment order: The instruction given by the payment service user to the payment service provider for the purpose of carrying out the payment transaction,

j) Payment service: The services specified in Article 12 of Law No. 6493,

k) Payment service provider: The institutions specified in Article 13 of Law No. 6493,

l) Payment transaction: The activity of depositing, transferring or withdrawing funds carried out upon the instruction of the sender or the recipient,

m) Payment card: The bank cards and credit cards issued within the scope of the Law No. 5464 on Bank Cards and Credit Cards dated 23/2/2006 and the cards in the nature of payment instruments issued within the scope of Law No. 6493,

n) Payment system: The structure that provides the infrastructure necessary for clearing and settlement transactions carried out to ensure the realization of fund transfers arising from transfer orders between three or more participants and that has common rules,

o) Payment system operator: The legal person responsible for the daily operation of the payment system and holding the activity license required for system operation,

ö) Static QR code: The QR code whose content is fixed and which can be used in more than one payment transaction,

p) Technical Document: The document titled "TR QR Code Principles and Rules" annexed to this Regulation, which sets out the basic principles and rules to be followed when generating QR codes for all kinds of transactions that fall within the scope of payment services under Law No. 6493 and that are carried out using QR code,

r) TR QR Code: The QR code created in accordance with the procedures and principles set out in the Technical Document and which can be used in payments within the scope of Law No. 6493,

s) TR QR Code transaction: The payment transaction carried out using a QR code created in accordance with the procedures and principles set out in the Technical Document,

shall mean.

PART TWO

TR QR Code and QR Code Routing System

Payments to be made with TR QR Code

ARTICLE 4 – (1) In every payment transaction that falls within the scope of payment services under Law No. 6493 and that is carried out using QR code, TR QR Code shall be used.

(2) The Bank may set an upper limit on payment transactions that can be carried out using TR QR Code.

(3) The Bank is authorized to request the necessary information and documents from parties involved in making payments with QR code, such as payment service providers, system operators where TR QR Code transactions are carried out, merchants, external service providers, and to conduct on-site inspections when necessary.

(4) The liabilities of the payment service provider, merchants, sender, recipient and other relevant parties arising from other legislation to which they are subject depending on the nature of the realized payment transaction regarding payment transactions initiated through TR QR Code are reserved.

TR QR Code generation and QR Code Generator Code

ARTICLE 5 – (1) TR QR Code shall be generated by the payment service provider holding the QR Code Generator Code and by the payment system operator deemed appropriate by the Bank.

(2) The TR QR Code to be generated within the scope of the first paragraph shall be generated in accordance with the principles and rules set out in the Technical Document.

(3) The payment service provider may procure external services for the generation of TR QR Code.

(4) The QR Code Generator Code shall be determined by BKM upon the request of the payment service provider and the payment system operator deemed appropriate by the Bank and shall be announced in the list to be created on its website.

Technical Principles and Rules Guide

ARTICLE 6 – (1) The Technical Principles and Rules Guide, which also includes the workflows regarding transactions to be carried out through a specific payment system using TR QR Code, shall be determined by the Bank upon the application of the relevant system operator. The Bank is authorized to prepare the Technical Principles and Rules Guide containing the workflows for transactions to be carried out using the TR QR Code for a specific type of payment service, if it deems necessary for the development of the payments field.

(2) The distribution and sharing procedure of the Technical Principles and Rules Guide to be prepared in accordance with the first paragraph shall be determined by the Bank.

QR Code Routing System

ARTICLE 7 – (1) In cases where it is necessary in the processes related to payment services to be carried out with the TR QR Code, the QR Code Routing System shall be established and operated by BKM in order to ensure the transfer of the QR code and the information contained therein between payment service providers.

(2) All kinds of procedures and principles regarding the implementation of this article, including the operating rules of the QR Code Routing System, participation conditions and the fee principles according to the cost principle, shall be determined by the Bank and announced on its website.

THIRD PART

Rights and Obligations of the Parties

Authorities and responsibilities of the payment service provider in TR QR Code transactions

ARTICLE 8 – (1) The payment service provider is obliged to ensure that the QR code is created in accordance with the Technical Document in relation to the payment services it will provide using the TR QR Code, and to take the necessary measures for the secure and problem-free execution of payments to be made with the TR QR Code.

(2) The payment service provider may set an upper limit for payment transactions to be made using the TR QR Code, provided that it does not exceed the limits determined within the scope of the second paragraph of Article 4.

(3) The payment service provider shall take care to ensure that the QR code quality and readability are as high as possible during the generation of the TR QR Code and shall ensure the preservation of the QR code integrity.

(4) The payment service provider is responsible for ensuring that payment transactions to be made using the TR QR Code are carried out in compliance with the information contained in the QR code and for preserving the integrity of the information contained in the QR code while the payment transaction is being carried out.

(5) In payment transactions to be made using a static QR code, the payment service provider shall exercise the necessary diligence to take the measures needed to protect the physical security and readability of the QR code and shall include the necessary provisions in the framework contract regarding the taking of the necessary measures by the merchant.

(6) In the event that the payment service provider receives external services for QR code generation, the provisions regarding the use of external services in the legislation to which the payment service provider is subject shall be complied with according to the nature of the payment transaction carried out.

(7) In TR QR Code transactions, after the payment transaction is carried out, the payee's payment service provider is obliged to provide information to the payee, and the payer's payment service provider to the payer, as soon as possible by appropriate methods such as telephone, short message or application, that the transaction has been carried out.

Responsibilities of the merchant in TR QR Code transactions

ARTICLE 9 – (1) The merchant that will enable payment to be made using the TR QR Code is obliged to inform payment service users that the payment transaction can be made with the QR code. The information to be provided within the scope of this paragraph shall be made in accordance with the display format to be determined by the Bank.

(2) The merchant that will enable payment to be made using the TR QR Code shall exercise the necessary diligence to ensure that TR QR Code transactions are carried out in compliance with the information contained in the QR code and to preserve the integrity of the information contained in the QR code while the payment transaction is being made, and shall take the necessary measures to protect the physical security and readability of the QR code in payment transactions made using a static QR code.

FOURTH PART

Miscellaneous and Final Provisions

Transactions containing a foreign element

ARTICLE 10 – (1) The use of the TR QR Code is not mandatory for QR code payment transactions made domestically using payment instruments issued under foreign country legislation, where one of the parties to the transaction is resident abroad and the infrastructure of a payment service provider resident abroad is used for the payment transaction.

Implementation principles

ARTICLE 11 – (1) The Bank is authorized to interpret the provisions of this Regulation, to decide on matters not included in this Regulation or on which there is no clarity by also taking into account the general provisions, and to issue communiqués, circulars and instructions in order to regulate and guide the implementation.

Transitional provisions

PROVISIONAL ARTICLE 1 – (1) Payment service providers that enable payment by QR code are obliged to make the QR codes used and their related infrastructures compatible with this Regulation, the Technical Document and, in cases where the payment service they offer requires a transaction to be carried out through a payment system, the Technical Principles and Rules Guide to be prepared in relation to the payment system in question, by 31/12/2021 at the latest. The Bank is authorized to extend this period by no more than one year.

(2) Payment service providers that enable merchants to accept payments through payment cards or payment systems operated by the Bank are obliged to establish, at the merchants with which they have agreements, by 31/12/2021 at the latest, the infrastructure that allows payment to be made using the dynamic QR code method presented by the merchant as set out in the Technical Document. The Bank is authorized to extend this period by no more than one year.

(3) In the event that merchants use different devices and applications in addition to the payment infrastructure offered by payment service providers when accepting payments through payment cards or payment systems operated by the Bank, the owners of the additional devices and applications used shall also take the necessary measures to establish, at the merchant, by 31/12/2021 at the latest, the infrastructure that allows payment to be made using the QR code method presented by the merchant as set out in the Technical Document. The Bank is authorized to extend this period by no more than one year.

(4) The Bank is authorized to request the payment service provider to stop the payment infrastructure services it provides to the merchant who does not endeavor to take the necessary measures within the scope of the third paragraph without providing a reasonable justification.

Effectiveness

ARTICLE 12 – (1) This Regulation enters into force on the date of its publication.

Execution

ARTICLE 13 – (1) The President of the Central Bank of the Republic of Turkey executes the provisions of this Regulation.

CENTRAL BANK OF THE REPUBLIC OF TURKEY

Annex: TR QR Code
Principles and Rules

August 2020

Version 1.0

Confidential

Version and Change History

Change Date	Change Description	Version
August 2020	First Version	1.0

1. PURPOSE and SCOPE

This document, prepared within the scope of determining the national QR code (TR QR Code) principles and rules, aims to ensure interoperability among the actors in the ecosystem by creating a standard QR code structure and common rules and language for the payments field, to support innovative initiatives, and thus to contribute to the dissemination of QR code usage in payment services.

This document aims to establish a common infrastructure for the provision of best practices in the acceptance of QR code payments to all relevant stakeholders, particularly QR code producers, acceptors, payment service providers, technical service providers, and payment service users.

With TR QR Code, it is aimed to ensure QR code standardization for retail payments by increasing cashless payments at all levels in Turkey, and thus to support the goal of using less cash. With the common QR code rules, users of different payment service providers will be given the opportunity to make payments with QR code, payments between different payment schemes, digital wallets, and payment service providers will be facilitated, and the adoption of QR code as a payment method in merchants, including small-scale businesses, will be encouraged.

Within the framework of the Law on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions dated 20/6/2013 and numbered 6493 (the Law), compliance with the procedures and principles set out in this document is mandatory in all kinds of transactions within the scope of payment services and made using QR code.

The possible parties to the payment transaction to be carried out with the QR code to be determined within the scope of this document are as follows:

• Producers of the QR code to be used for payments,

• Merchants and customers - payment service users - who will accept the produced QR codes,

• Acquirer payment service providers,

• Payment systems that transfer funds between payment service providers to enable payments made using QR code,

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

TR QR Code includes the specifications that enable the use of the data coding technology known as "QR Code" 1 for the payments field.

The QR code has the main function of providing the information necessary for the realization of a payment transaction, such as the identity, account, and card information of one of the parties in a payment transaction. During the realization of the payment transaction, the QR code is shown by one of the parties to the transaction and scanned by the other.

Within the scope of the principles and rules set out in this document, the characteristics of QR code technology, the encoding of data objects, data types and formats, QR code data organization according to the business model used, and the properties of data objects are defined.

TR QR Code will be used for all payments to be made using QR code within the scope of the Law. In this context, merchant-presented, consumer-presented, person-to-person payment QR codes, and the short QR code specifications presented by the merchant that include a limited amount of information in the QR code are determined within the scope of this document.

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

The defined specifications support static QR codes, where the code always contains the same information and can be used in multiple transactions, and dynamic QR codes, which have a unique reference information for each transaction and are generated specifically for a single transaction.

2. DEFINITIONS and ABBREVIATIONS

2.1. Definitions

Within the scope of this document;

Recipient: The real or legal person to whom the fund subject to the payment transaction is intended to reach,

BKM: Interbank Card Center Joint Stock Company,

BKM KKF: Interbank Card Center Short QR Code Format,

BKM UKF: Interbank Card Center EMVCo Compatible Long QR Code Format,

Dynamic QR code: The QR code generated specifically for the payment transaction to be used and which is single-use,

EMVCo: The union consisting of American Express, Discover, JCB, Mastercard, UnionPay, and Visa,

Electronic communication operator: The operator defined within the framework of the Electronic Communication Law dated 5/11/2008 and numbered 5809,

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

Sender: The real or legal person who gives a payment order from their own payment account or without having a payment account,

Merchant: The real or legal person who accepts, as the recipient party, that the payment for a good or service is made using QR codes generated within the scope of this document,

Merchant-presented QR code: The QR code model based on the principle that customers scan the QR code presented by the merchant through the application they use and initiate the payment transaction,

Law: The Law on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions dated 20/6/2013 and numbered 6493,

QR code: The two-dimensional code created to be used in payment transactions by scanning method; storing 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 reader, and having black and white modules in the form of square black-white dots or pixels,

QR code producer code: The code required to generate TR QR Code,

KYS: QR Code Routing System,

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

Short QR Code: A QR code with limited data content used in cases where all data required for the payment transaction cannot be stored or it is not preferred that information belonging to the person displaying the QR code be explicitly included in the QR code,

User: Real or legal persons who make payments 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: The services specified in Article 12 of the Law,

Payment service provider: The institutions specified in Article 13 of the Law,

Payment transaction: The activity of depositing, transferring or withdrawing funds carried out upon the instruction of the sender or the recipient,

Payment system: The structure that provides the necessary infrastructure for clearing and settlement operations to ensure the realization of fund transfers arising from transfer orders between three or more participants and that has common rules,

Payment system operator: The legal person responsible for the daily operation of the payment system and holding the activity license required for system operation,

Static QR code: A QR code with fixed content that can be used in multiple payment transactions,

TCMB: Türkiye Cumhuriyet Merkez Bankası Anonim Şirketi,

TR QR Code: A QR code created in accordance with the procedures and principles set out in this document and that can be used in payments within the scope of the Law,

National Merchant Registry System: The system in which information regarding merchants accepting electronic payments is kept at BKM, for the purpose of facilitating the processes related to payment transactions made with TR QR Code and preventing fraud and malicious use activities in the field of payments,

shall mean.

3. GENERAL PRINCIPLES

The following general principles have been taken into account in determining the TR QR Code rules for payments.

• The long QR code specification presented by the merchant in this document is compatible with the EMVCo standard 2.

• QR codes created with the rules in this document can be used as static or dynamic depending on use and support various payment forms such as mobile payments, invoice payments, online payments and payments made at the point of sale.

• All payment services to be carried out using QR codes within the scope of the Law are performed with QR codes created in accordance with the rules set out in this document.

• Payment service providers wishing to offer their users the opportunity to make payments using QR codes shall make the necessary developments in their infrastructures to generate and accept QR codes.

• QR code generators shall ensure that QR codes are generated in accordance with the rules set out in this document, in line with the requests of the merchants or users to whom they provide services.

• QR codes to be generated within the framework of the rules in this document shall be created in compliance with the ISO/IEC 18004 standard.

• When a QR code generator creates any QR code or adds any other data to an already created QR code, it is responsible for ensuring that all data contained therein is complete and accurate and that the QR codes fully comply with the technical document and requirements regarding the TR QR Code in force.

• In payments made with QR codes, all parties, especially payment service providers, shall continue to be obliged to fulfill their other obligations arising from the Law and other relevant legislation and not otherwise specified in this document.

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

4. QR CODE USAGE MODELS FOR PAYMENTS

This section presents the usage models of QR codes in the field of payments. First, QR code classes are addressed according to their reusability, and then they are examined according to usage models.

4.1. According to Reusability

QR codes supporting a wide variety of payment services such as e-commerce, in-store physical payments, institution/invoice payments are divided into two classes as static QR code and dynamic QR code according to their content variability and reusability.

The QR code rules in this document support both classes (static and dynamic QR code).

4.1.1. Static QR Code

The content of static QR codes is fixed and they can be used in multiple transactions. Static QR codes, which are generally preferred for use by small businesses and vendors (simit seller, florist, kiosk, etc.), are obtained by the merchant from a QR code generator and basically contain the merchant's account information. The customer scans this QR code in their purchases through their mobile applications, views the transaction information contained in the QR code and initiates the payment transaction.

4.1.2. Dynamic QR Code

Dynamic QR codes, on the other hand, are generated specifically for the transaction to be used and are single-use.

For this purpose, dynamic QR codes contain a unique reference information specific to themselves, and preferably in addition to the merchant information contained in the static QR code, payment-specific information (amount, invoice number, etc.) can also be included in the dynamic QR code.

4.2. According to Usage Method

4.2.1. QR Code Presented by the Merchant

4.2.1.1 Long QR Code Presented by the Merchant

The QR code usage model presented by the merchant is based on the customer scanning the QR code generated at the merchant through their application (payment service provider's application or third-party application) and initiating the payment transaction.

Figure 1 shows an example general workflow regarding the use of the long QR code presented by the merchant.

Figure 1: Example Workflow of Long QR Code Presented by the Merchant

1. The merchant initiates the QR code generation process by entering the amount information related to the purchase transaction.

2. The merchant generates the QR code containing the merchant account information and payment details.

2a. In case a dynamic QR code is used, within the framework of the merchant's preference and the business model it has established, it is possible for the QR code to be generated by the merchant's payment service provider, transmitted online to the merchant's device and displayed on the screen of the merchant's payment device.

3. The customer scans the QR code from the screen via the application they use. In case a static QR code is used, the customer enters the amount information and, if any, additional information regarding the payment (for example, invoice number, payment reference information) via the application.

4. The customer checks the payment information and, by approving the transaction, directs it to the payment service provider.

5. The customer's payment service provider checks the payment request and the customer's balance, creates the payment message and transmits it to the payment system.

6. The payment system performs the verification of the payment between the payment service providers and, if the payment method requires it, the reconciliation.

7. Payment result notification:

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

7b. The merchant's payment service provider sends information messages to the merchant, and the customer's payment service provider sends information messages to the customer, regarding the completion of the payment transaction.

It is possible for the workflows, examples of which are given above, to change depending on the method to be used.

4.2.1.2 Short QR Code Presented by the Merchant

The short QR code (KK) is a QR code with limited data content used in cases where all the data required for the payment transaction cannot be stored or where it is not preferred for the information belonging to the one presenting the QR code to be explicitly included in the QR code for various reasons such as security concerns.

In the KK workflow presented by the merchant, the generated QR code contains a unique reference number (and optionally summary information that can be added) created by the QR code generator (the merchant's payment service provider) instead of the information pertaining to the payment transaction. The customer who scans the KK with their application obtains the information on which the payment is based from the merchant's payment service provider via their payment service provider using this reference number, and after this stage initiates the actual payment transaction.

Figure 2 shows an example general workflow regarding the use of the KK presented by the merchant.

Figure 2: Example Workflow of Short QR Code Presented by the Merchant

1. The merchant initiates the KK creation process by entering the amount information related to the purchase transaction.

2. The merchant's payment service provider generates the KK and transmits it to the merchant:

2a. The merchant transmits the KK creation request containing the payment-related information to the merchant's payment service provider.

2b. The merchant's payment service provider generates the KK containing the transaction-specific reference information and transmits it to the merchant online.

3. The customer scans the KK from the merchant's screen via the application they use.

4. The customer transmits the transaction-specific reference information contained in the KK to their own payment service provider via the application they use.

5. The customer's payment service provider transmits the KK to the merchant's payment service provider via the QR code routing service.

6. The merchant's payment service provider verifies the information contained in the KK, particularly the transaction-specific reference information, and creates the payment and merchant information.

7. The actual payment-related information is transmitted to the customer:

7a. The merchant's payment service provider transmits the payment and merchant information to the customer's payment service provider via the QR code routing service.

7.b. The customer's payment service provider transmits the payment and merchant information to its customer.

8. The customer checks the payment and merchant information in its application and initiates the actual payment transaction.

9. The customer transmits the payment request to its own payment service provider.

10. The customer's payment service provider checks the payment request and its customer's balance, creates the payment message and transmits it to the payment system.

11. The payment system performs the verification of the payment between the payment service providers and, where required by the payment method, the clearing and settlement.

12. Payment result notification:

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

12b. The merchant's payment service provider transmits notification messages regarding the completion of the payment transaction to the merchant, and the customer's payment service provider transmits them to its customer.

The workflows exemplified above may change depending on the method to be used.

4.2.2. QR Code Presented by the Customer

In the QR code usage model presented by the customer, the customer who will make the payment displays the QR code using the QR code generation option in its application, and the payment process begins with this QR code being scanned by the merchant's QR code reader. The generated QR code contains the information of the account or card selected by the customer (or indicators that will address this information).

Since the data transfer via the QR code is from the customer's device to the merchant's device, the QR code does not contain any information belonging to the merchant.

Figure 3 shows an example general workflow for the QR code usage presented by the customer.

Figure 3: Example Workflow for QR Code Presented by the Customer

1. The customer selects the account or card to be used for payment in its application and generates a QR code corresponding to its selection.

2. The merchant scans the QR code on the customer's screen with its QR code reader.

3. The merchant's application transmits the payment request it creates with the QR code information to the merchant's payment service provider.

4. The merchant's payment service provider transmits the payment request to the customer's payment service provider via the QR code routing service.

5. Customer notification and approval:

5a. The customer's payment service provider sends an approval message regarding the payment request, which includes the amount, payee information, etc., to its customer via tools such as the application or SMS.

5b. The customer checks the message content and gives approval.

6. The customer's payment service provider, having received the approval, creates the payment message and transmits it to the payment system.

7. The payment system performs the verification of the payment between the payment service providers and, where required by the payment method, the clearing and settlement.

8. Payment result notification:

8a. The payment system transmits the result of the payment to the relevant payment service providers. 8b. The merchant's payment service provider transmits notification messages regarding the completion of the payment transaction to the merchant, and the customer's payment service provider transmits them to its customer.

The workflows exemplified above may change depending on the method to be used.

4.2.3. QR Code Presented in Person-to-Person Payments

In person-to-person payment transactions, it is a QR code model presented by the payee in order to transfer the payee's account information to the payer. The payment process begins with the payee displaying a QR code containing the information of the account to which the payment will be made, using the QR code generation option in its application, and this QR code being scanned by the payer. The generated QR code contains the information of the card selected by the payee, account information, or indicators that will address the account information.

Since the data transfer via the QR code is from the payee's device to the payer's device, the QR code does not contain any information belonging to the payer.

Figure 4 shows an example general workflow for the QR code usage presented in person-to-person payments.

Figure 4: Example Workflow for QR Code Presented in Person-to-Person Payments

1. The payee selects the target account or card to which it wants the payment to be made in its application and generates a QR code corresponding to its selection.

2. The payer scans the QR code displayed by the payee via its application and checks the payee's information.

3. The payer transmits the payment request it creates with the payee's account information contained in the QR code to the payment service provider.

4. The payer's payment service provider checks the payment request and its customer's (the payer's) balance, creates the payment message and transmits it to the payment system.

5. The payment system performs the verification of the payment between the payment service providers and, where required by the payment method, the clearing and settlement.

6. Payment result notification:

6a. The result of the payment is transmitted to the relevant payment service providers.

6b. The payer's payment service provider transmits notification messages regarding the completion of the payment transaction to the payer, and the payee's payment service provider transmits them to the payee.

The workflows exemplified above may change depending on the method to be used.

5. QR CODE SPECIFICATIONS FOR PAYMENTS

5.1. QR Code Data Organization and Naming Rules

The data within a QR code are organized in a tree structure as objects, and are divided into two main classes: simple data objects and data template objects, under the root3 part of this structure. While simple data objects can store a single piece of information such as date, amount, reference number, data template objects can contain one or more simple data objects and other data template objects (Figure 5).

Figure 5: QR Code Data Structure Organization

Each object within the QR code has a data structure consisting of three parts4:

• Field code: consists of two digits between "00" and "99" and indicates the identity of the object. In a QR code, all field names have a unique value at the root level or within the data template they belong to. For example, the object indicated by the field code “01” under the root and the object indicated by the field code “01” under a data template with the field code “62” refer to different data.

• Length: A two-digit number indicating the length in characters of the data value belonging to the object, having a value between “01” and “99”.

• Data value: The value of the data with a length of at least one character and at most 99 characters.

Example:

An object with field code “02”, length “08” and data value “20200530” is represented in the form “020820200530”.

The data values of the objects contained in the QR code support the following data types:

• Character String (K): A data type containing characters created in accordance with UTF-85 character encoding.

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

[4] Due to limited data capacity, the field name and length section are not present in the objects within the short QR code content offered by the workplace.

[5] UTF-8 (8-bit Unicode Transformation Format) is the name of the general standard that enables the representation of all universally available characters using a variable number of bytes ranging from 1 to 4.

• Special Alphanumeric (ÖAN): A data type containing digits between ‘0’-‘9’, letters of the alphabet, and punctuation marks. It is a subset of the Character String data type.

• Numeric (N): A data type containing digits between ‘0’-‘9’. It is a subset of the Special Alphanumeric data type.

The following notation is used for the presence status of objects within the QR code data organization:

• Mandatory (Z): The relevant data object must always be present in the QR code.

• Optional (İ): The presence of the relevant data object in the QR code is optional.

• Conditional (K): The presence of the relevant data object in the QR code depends on certain conditions. For example, if only one of two data objects is required to be present in the QR code, the presence status of these objects is specified as conditional. The necessary condition information is included in the descriptions of the relevant objects.

The QR Code Format Indicator, which is the first data object of the QR code, specifies its type according to the usage model of the QR code and, accordingly, the structure, representation, and version of the remaining data. Applications parse all data by first reading this object in the QR code.

The content following the QR code format indicator constitutes the data section of the QR code in accordance with this indicator. In this section, data organization definitions are presented for the specifications “Long QR Code Offered by the Workplace”, “Short QR Code Offered by the Workplace”, “QR Code Offered by the Customer”, and “QR Code Offered in Person-to-Person Payments” (Table 1).

Table 1: Format Indicators According to QR Code Types

QR Code
Format Indicator
QR Code Type Description
“000201”
Long QR Code
Offered by the
Workplace
“00”: Field code
“02”: Field length
“01”: The version number of the EMVCo standard with which the QR code data organization is compatible. For the data organization contained in this document, it is the fixed value “01”6 is the version number of the standard. The data contained in this document is the fixed "01" value for the organization6 . “9u” Short QR Code Offered by the Workplace "9": Field code indicator u: Application indicator (See Table 7 QR Code Format Indicator) "8502ss" QR Code Presented by the Customer "85": Field code "02": Field length ss: TR QR Code Version number. For the data organization contained in this document (version 1.0), it contains the fixed value "10". "7502ss" QR Code Presented in Person-to-Person Payments "75": Field code "02": Field length ss: TR QR Code Version number. For the data organization contained in this document (version 1.0), it contains the fixed value "10".

[6] The TR QR Code version number is different from the version number of the compatible EMVCo standard and is located in the "Version Number" subfield with code "00" of the "QR Code Identity Information Template" with field code "51".

5.2. QR Code Structures Presented by the Merchant

5.2.1. Long QR Code Structure Presented by the Merchant

The content of the long QR code presented by the merchant, an example workflow of which is given in Section 4.2.1.1, includes the following information:

• QR Code Format Indicator: Indicates the usage model, the data structure of the QR code related thereto, and the version number of the EMVCo standard with which the TR QR Code is compatible.

• QR Code Type: Specifies the static or dynamic classification of the QR code.

• Merchant Account Information: This field, whose format and content are determined specifically for the payment system, contains the account information of the merchant. A separate data object is used for each payment system.

• QR Code Identity Information: Identity information enabling the identification of the QR code (for example; TR QR Code version number, QR code producer, unique reference number, creation time, etc.).

• Additional information specific to the merchant (for example; location, merchant code, merchant name, country, city, etc.).

• Additional information of the merchants related to payment and not included in the defined fields of the QR code (for example, product information, bill, etc.).

• Information pertaining to the payment transaction (amount, currency, other amount or tip, etc.).

• Additional information specific to the payment transaction according to various payment scenarios (for example, invoice number, customer phone number, payment purpose, etc.).

• Information storing the summary information calculated for the purpose of integrity verification of the entire QR code (Eng. Cyclic Redundancy Check, "CRC").

The CRC, which is the last field of the QR code, is calculated according to the ISO/IEC 13239 standard using the '1021' (hex) polynomial and the 'FFFF' (hex) initial value. In the calculation, all data within the QR code (field name, length information and values) are included in the same order (the CRC field name and length are also included in the calculation, but the CRC value is not included). Each 'hex' digit of the calculated 2-byte value is converted to a special alphanumeric character and added to the relevant field as the CRC value. For example, a CRC calculated as '097B' (hex) is included in the QR code as "6304097B".

Table 2 shows the QR code data organization presented by the merchant. The subfields of the data template objects in the table ("26"- "46", "51", "62" and "64") are shown in the following tables.

Table 2: QR Code Data Organization Presented by the Merchant

Field Name	Field Code	Data Type	Length	Presence Status	Sample Data	Description
QR Code Format Indicator	00	N	02	Z	000201	It is the value used for the QR code data organization provided by the merchant. The last two digits (data value) indicate the version number of the EMVCo standard with which the QR code data organization is compatible and have the fixed value “01”.
QR Code Type	01	N	02	Z	For Static QR code: 010211 For Dynamic QR code: 010212	Used to distinguish between Static and Dynamic QR Codes. Data value: “11”: Static QR Code where the same QR code is used for multiple transactions. “12”: Dynamic QR Code where a different QR code is used for each transaction.
Merchant Account Information	02-46	ÖAN	Variable up to 99	Z	For FAST: 30uuVD	Merchant account information must be created under the field code of the payment system to be used and in compliance with the QR code data template of the said payment system (see Table 3). The use of at least one of the fields “26-27”, “30-31” and “32” is mandatory. VD: Data value of the template. uu: Total length of the data value (VD) of the template in characters.
	02-03				Reserved for VISA.	These are fields 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				Used by BKM.	For subfields see “BKM - TR QR Code Technical Principles and Rules Guide”
	28-29				Reserved for BKM.
	30-31				Used by FAST.	For Subfields see “FAST - TR QR Code Technical Principles and Rules Guide”
	32				Used for mobile payments.	For Subfields see “Mobile Payments - TR QR Code Technical Principles and Rules Guide”
	33-40				Reserved for TCMB
	41-46				Reserved for other payment systems in Türkiye.	Payment system operators who wish to use these field codes must apply to the TCMB.
Merchant Free Templates	47-48	ÖAN	Variable up to 99	İ	47uuVD 48uuVD	Businesses may freely use these fields in the form of simple data and/or data template to carry additional information related to payment and not defined in other fields of the table (for example, product information, bill, etc.) in the QR code

Field Name	Field Code	Data Type	Length	Presence Status	Sample Data	Description
						VD: Data value of the relevant template. uu: Total length of the data value (VD) of the relevant template in characters.
Business Code	49	N	10	M	49100023415672	It is the unique reference number of the business in the National Business Registry System. Values shorter than 10 digits will be completed with '0' character on the left side.
Location	50	N	Variable between 16-34	M	For latitude 39.939423 and longitude 32.851791, the location value: 50163993942332 851791	It is the location information that can be used for QR code payment transaction and created according to Decimal Degrees (DD) format. The location value consists of two parts of equal length, the first being latitude and the second being longitude. For Latitude: LL.llllll and Longitude: GG.gggggg, the location value is specified as LLllllllGGgggggg and no separator such as '.', ',', etc. is used. The number of 'l' and 'g' digits are equal and can be at least 6 and at most 15 depending on the precision level to be used.
QR Code Identity Information Template	51	VAN	Variable up to 99	Z	51uuVD	It is the QR code identity template generated by the QR code producer. The sub-fields of the identity information are shown in Table 4. VD: Data value of the template. uu: Total length of the data value (VD) of the template in characters.
Business Category Code	52	N	04	Z	52045499	It is the Merchant Category Code (MCC) of the transaction in compliance with ISO 18245:2003. Examples of these 4-digit codes are '5661' (shoe seller) or '5499' (markets). If this field is not used, the value '0000' must be written.
Currency	53	N	03	Z	5303949	It is the currency code of the transaction in compliance with ISO 4217: TRY: '949', USD: '840', EUR: '978', etc.
Amount	54	N	12	M	For 1,23, 54120000000001 23	Indicates the amount of the payment transaction. The tip or other amount in the field with code '55' is not included. The last two digits indicate the decimal part (kuruş, etc.). '0' is added to the left to complete the amount to 12 digits. If the amount value in this field is not available, the payment amount must be entered into the application by the customer. Additionally,

Field Name	Field Code	Data Type	Length	Presence Status	Sample Data	Description
						whether the payment is entered into the application by the customer can be checked with an indicator in the relevant payment system template in the business account information.
Tip or Other Amount Indicator	55	N	02	İ	550201	Indicator for the use of tip or other amount: “01”: The customer's application prompts the customer to enter the tip or other amount. “02”: Indicates that the amount specified in the field with code “56” will be taken from the customer as a fixed other amount or other amount. “03”: Indicates that a tip or other amount will be taken from the customer up to the percentage specified in the field with code “57”.
Tip or Other Amount Value (Fixed)	56	N	12	K	5612000000000250 for 2,50	Specifies the fixed tip or other amount. If the value of the field with code “55” is “02”, this field must be filled. The last two digits indicate the decimal part (kuruş, cent, etc.). “0” is added to the left side to complete the amount to 12 digits.
Tip or Other Amount Value (Percentage)	57	N	05	K	570500325 for the value %3,25	Specifies the percentage tip or other amount. If the value of the field with code “55” is “03”, this field must be filled. The last two digits give the decimal part. The percentage value given in this field of the amount specified in the field with code “54” constitutes the other amount. “0” is added to the left side to complete the ratio to five digits.
Country Code	58	ÖAN	02	Z	5802TR	The 2-digit country code of the workplace as specified in ISO 3166-1 alpha 2. “TR” for Türkiye.
Workplace Name	59	ÖAN	Variable up to 25	Z	5907ABCKAFE	The account name of the workplace. It may be displayed on the customer's device screen during the transaction.
Workplace City	60	ÖAN	Variable up to 15	Z	6008İSTANBUL	The city name of the workplace.
Postal Code	61	ÖAN	Variable up to 10	İ	610534100	The postal code of the workplace
Additional Data Fields Template	62	K	Variable up to 99	İ	62uuVD	Contains the additional data required by the workplace for the payment system used. The subfields of the template are shown in Table 5. VD: The data value of the template. uu: The total length of the data value (VD) of the template in characters.

Field Name	Field Code	Data Type	Length	Presence Status	Sample Data	Description
Merchant Language Information Template	64	K	Variable up to 99	İ	64uuVD	If this data template is present, the merchant information is specified in an alternative language in its content. The subfields are shown in Table 6. VD: Data value of the template. uu: Total length of the data value (VD) of the template as characters.
EMVCo Reserved Fields	65-79	K	Variable up to 99	İ	-	Reserved for future use by EMVCo.
Free Templates	80-99	K	Variable up to 99	İ	-	These are fields reserved for future use within the scope of TR QR Code. Application to the CBRT is required for use.
CRC	63	ÖAN	04	Z	63040D9E	It is the integrity check value calculated over the entire QR code (excluding the CRC value in this field). It is the last field of the QR code.

The merchant account information fields with codes “26”-“27” and “30”-“31” in Table 2 are used by BKM and the FAST system, and the field with code “32” is used for mobile payments. Matters regarding the subfields and workflows within the relevant fields are determined by the technical principles and rules guides of the said systems.

The merchant account information template contains data regarding the identity and account information of the merchant. Payment system operators may define data structures specific to themselves for merchant account information in the field allocated for them. One or more merchant account information templates may be present in the same QR code, each belonging to a different payment system. In this case, the customer will have the opportunity to choose the payment system (Credit card, FAST, mobile payment) they wish to use through the application that scans the QR code.

The use in Turkey of the fields with codes “26”-“51”, which are outside the “02”-“25” fields allocated for EMVCo members and allocated by EMVCo for the use of countries' payment systems, will be as follows:

26-27: Used for BKM-TR QR code.

28-29: Reserved for BKM's future use

30-31: Used for FAST-TR QR code.

32 : Used for mobile payments.

33-40: Reserved for the CBRT's future use

41-46: Reserved for other payment systems in Turkey. Payment system operators who wish to use these field codes must apply to the CBRT.

47-48: These are fields reserved for merchants to use as simple data and/or data templates in order to carry additional information related to payment and not defined in other fields of the table (for example, product information, bill, etc.) within the QR code.

49: Used for the unique reference number of merchants in the National Merchant Registry System.

50: Reserved for the location information of the merchant.

51: Used as the “QR Code Identity Information Template” carrying the identity information of the generated QR code (see Table 4).

Table 3: Merchant Account Information Template (Field Code: “26”-“46”)

Subfield
Name
Sub
Field
Code
Data
Type
Length
Presence
Status
Sample Data
Value
Description
Universal
Unique Identifier 00 ÖAN to 32 up to variable İ 0016TR.GOV.TC MB.FAST It can be one of the following:
Payment System Application
Number
Payment system's Internet
Engineering Task Force (IETF) RFC
4122 defined universal unique identifier number (UUID) Payment system's reverse domain name Payment System Specific Fields 01-99 ÖAN to 99 up to variable Z - It constitutes fields containing the payment system-specific account information of the merchant.

The identity information regarding the generated QR code is specified in the template with field code "51" (Table 4).

Table 4: QR Code Identity Information Template (Field Code: "51")

Sub Field Name	Sub Field Code	Data Type	Length	Presence Status	Sample Data Value	Description
Version Number	00	N	02	Z	For the data organization in this document (version 1.0): 000210	It is the TR QR code version number. For version number "S.s", the data value is created as "Ss" without using a punctuation mark.
QR Code Producer Code	02	N	04	Z	02040064	The code of the QR code producer. Payment Service Providers and payment system operators deemed appropriate by the CBRT will be able to obtain a QR code producer code by applying to BKM for registration in order to generate TR QR codes. Banks will use their EFT codes and do not need to register separately. Values shorter than 4 digits will be completed with the '0' character on the left side.
QR Code Reference Number	03	ÖAN	variable up to 12	K	030823451017	It is the unique reference number generated for the QR code. It is provided by the merchant application or the QR code generator and is used in processes such as end-to-end verification, transaction recording or receipt generation. It may be specified by the merchant within the QR code or may be an indication for the consumer to enter the reference information into the mobile application they use. It is mandatory for dynamic QR codes and optional for static QR codes.
Terminal Type	04	N	02	İ	For POS device: 040202	The type of device on which the QR code is generated. Defined values: “01”: Static QR code “02”: POS/mPOS/ÖKC/Kiosk etc. payment acceptance software and hardware “03”: ATM “04”: Merchant application “05”: Web “06”: Payment service provider’s merchant application
Terminal Device Serial Number	05	ÖAN	Variable up to 23	İ	0523123456789012 34567890ABC	The distinguishing value belonging to the QR code generating device or terminal (for example, the terminal number and/or the terminal’s serial number).
Creation Time	06	N	12	Z	For 29 May 2020 at 14.01:59: 0612200529140159	It is the time information when the QR code was generated. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24-hour), DD: minute, ss: Second
Last Validity Time	07	N	12	K	For 29 May 2020 at 15.01:59: 0712200529150159	It is the last time information when the QR code is valid. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24-hour), DD: minute, ss: Second It is optional for static QR codes and mandatory for dynamic QR codes.

Additional information regarding the payment is included in the “Additional Data Fields” template with field code “62”, and the subfields of the template are given in Table 5.

Since the total length of the field belonging to this template is at most 99 characters, the subfields whose presence status is “optional” must be determined in a way that does not exceed this limit and the QR code must be generated accordingly.

Table 5: Additional Data Fields Template (Field Code: “62”)

Subfield Name	Subfield Code	Data Type	Length	Presence Status	Example Data Value	Description
Invoice Number	01	ÖAN	Variable up to 25	İ	01085460 980A	Invoice number. In invoice payments, it may be specified by the merchant within the QR code or may be an indication for the consumer to enter the invoice number into the application they use.
Customer’s Phone Number	02	ÖAN	Variable up to 15	İ	02129031 25075000	The customer’s phone number. It may be specified by the merchant within the QR code or may be an indication for the consumer to enter the phone number into the application they use.
Store Label	03	ÖAN	Variable up to 25	İ	0306AVMSTR	A label information that can be used to distinguish a specific store from others. It may be specified by the merchant within the QR code or may be an indication for the consumer to enter the store label into the application they use. The consumer’s application that reads the QR code may display this store information on the screen.
Customer's Loyalty Number	04	ÖAN	Variable up to 25	İ	0410231563 4123	Customer's loyalty card number. It may be specified by the merchant within the QR code or may be a prompt for the consumer to enter the loyalty number into the application they use.
Customer Number	06	ÖAN	Variable up to 25	İ	0610051889 4111	The tag (subscriber number) value used specifically for the customer and transmitted end-to-end. For example, it may be the customer's membership number for a membership. It may be specified by the merchant within the QR code or may be a prompt for the customer to enter the tag number into the application they use.
Payment Purpose	08	ÖAN	Variable up to 5	İ	080206	Code indicating the purpose of the payment transaction. It may be specified by the merchant within the QR code or may be a prompt for the customer to enter the payment purpose information into the application they use. Appropriate values should be used according to the definitions in the guidelines of the payment system used.
Additional Consumer Data	09	ÖAN	Variable up to 3	İ	0901M	Contains indicators for additional data expected to be provided by the customer's mobile application in order for the payment transaction to be completed. This data is provided by the application without the need for customer approval. One or more of the following characters (without repeating the same character) may be present in the field: "A": Customer's address, "M": Customer's mobile phone number, "E": Customer's e-mail address. If more than one character is used, each relevant data item is required for the payment transaction to be initiated.
	10-49					Reserved by EMVCo.
	51-99					These are free fields specific to the payment system.

If the merchant wishes to carry and show the customer its trade name and the city it is located in within the QR code in a language different from the one used in the fields coded "59" and "60", it may use the "Merchant Alternative Language" template ("64") whose subfields are given in Table 6.

Table 6: Merchant Alternative Language Template (Field Code: "64")

Subfield Name
Sub
Field
Code
Data
Type
Length
Presence
Status
Sample Data
Value
Description
Preferred
Language 00 ÖAN 02 Z 0002TR
ISO 639-1 compliant two-character language code.
"TR": Turkish
"EN": English
In the subfields coded "01" and "02" of this template, the code of the (usually local) language used to resolve the encoded merchant name and the city information where it is located.
It is a mandatory field if the template is used.
Merchant
Alternative
Language and Name
01 K
50’e kadar değişken
Z 0108AĞAÇA.Ş. The name of the workplace coded in the language specified in the “00” field. kodlanmış adı.
İşyeri
Alternatif
Language and City
Name
02 K
25’e kadar değişken
İ 0208İSTANBUL The name of the city where the workplace is located, coded in the language specified in the “01” field. the name of the city where it is found in coded form.
EMVCo tarafından ayrılmış alanlar
03-99 K
99’a kadar değişken

• -
  Reserved by EMVCo for future use. için ayrılmıştır.

5.2.2. Short QR Code Structure Provided by the Workplace

Short QR codes (KK) are used to obtain payment information via an online connection between payment service providers using a reference number transmitted within the QR code in cases where payment information cannot be included in the QR code due to insufficient capacity of the device displaying the QR code or where it is not preferred to carry it directly within the QR code for various reasons such as security concerns (see Section 4.2.1.2.).

The following points regarding the KK, whose data organization is given in Table 7, should be noted:

• In the KK data organization, due to limited data capacity, the field names and lengths are not included within the data objects.

• The lengths of the data objects (except for the “Other Data” field, which is the last object and the remaining data of the QR code) are fixed to the values shown in the table. If the length of the value belonging to an object (except for the last object, “Other Data”) is shorter than the length shown in the table, the data value is determined by aligning it to the left and adding space characters to complete the allocated length. The “Other Data” field, which is the last data object of the QR code, can optionally be used with variable length.

• As in the long QR code, in the CRC calculation of the KK, the ‘1021’ (hex) polynomial and the ‘FFFF’ (hex) initial value are used according to the ISO/IEC 13239 standard. In the calculation, all data objects (values) of the QR code, including the “Other Data” field if present, are included in their order, except for the value for which the CRC is to be calculated. Each ‘hex’ digit of the calculated 2-byte value is converted to a special alphanumeric character and added to the relevant field as the CRC value. For example, the CRC value calculated as ‘097B’ (hex) appears as “097B” in the QR code.

Table 7: Short QR Code Data Organization
Field Name
Data
Type
Length
Presence
Status
Sample Data
Value
Description
QR Code
Format
Indicator
N 02 Z
FAST KK için: 97
This is the value used for the KK data organization. Usage cases:
“99”: BKM KK
“98”: ATM QR Code
“97”: FAST KK
“96”7
: FAST KK ve BKM KK
94-95: Reserved for TCMB and BKM.
90-93: Other KK
QR Code
Producer
Code
N 04 Z 0064
KK producer's code. It will be given and registered by BKM.
For banks, the bank's EFT code will be used.
Values shorter than 4 digits will be padded with “0” characters on the left side.
QR Code
Reference
Number
ÖAN 12 K
AB3456789
012
A unique transaction reference number on the basis of the payment service provider, created in a non-sequential manner.
Optional for “98: ATM QR Code”, mandatory for others.
Summary
Security
Value
(Hash)
ÖAN 32 İ
702324AB9
00DD34EF7
FB67723AE
4C0FC
The security summary (hash) value calculated specific to the QR code generated by the QR code producer. The QR code producer may use this field to verify that the QR code data is the QR code it generated itself.
CRC ÖAN 04 İ 7D41 This field is the integrity check value calculated over all fields of the QR code except this field.
Other
Data ÖAN up to
214 variable
İ - KK producer may create according to its own standards.

[7] It is the short QR code format indicator that both payment systems are supported by the merchant and the merchant's bank, and the customer can choose between these payment systems.

5.3. Customer-Presented QR Code Structure

The content of the customer-presented QR code, for which an example workflow is given in Section 4.2.2, includes the following information:

• QR Code Format Indicator: Indicates the usage model, the data structure of the QR code related thereto, and the TR QR Code version number. The field with code “85” indicating the customer-presented QR code model constitutes the first data object of the QR code.

• Information specific to the generated QR code:

  o QR Code Type indicating the static or dynamic classification of the QR code.

  o QR Code Producer Code.

  o In case a dynamic QR code is used, the unique Reference Number specific to the QR code.

  o Commercial Transaction Indicator showing whether the payment is a commercial transaction.

  o QR Code Creation Time and Last Validity Time.

  o Summary Security Information (Hash).

• Mobile Payment Template (field with code “32”): This is the field that can be used in payment transactions where the approval for the payment transaction is given by the sender through an information or electronic communication device and the payment is made to an information or electronic communication operator acting solely as an intermediary between the user and the provider of goods or services. In case this field is used, the use of the application template with code “61” is not mandatory.

• Application Template (field with code “61”): Contains information belonging to the customer and data specific to the application used by the customer. Within an application template, at most one of the subfields of account information (IBAN) with code “01”, card number with code “02”, and easy address type with code “04” may be used.

Since the total length of the field belonging to this template is at most 99 characters, the subfields whose presence is “optional” must be determined in a way that does not exceed this limit and the QR code must be generated accordingly.

In case the Mobile Payment Template (field with code “32”) is used, the use of one or more application templates may optionally be created, whereas in case the Mobile Payment Template is not used, more than one application template may be included in the same QR code, with at least one being mandatory.

• CRC storing the summary information calculated for the purpose of integrity verification of the entire QR code.

The CRC, which is the last field of the QR code, is calculated according to the ISO/IEC 13239 standard using the ‘1021’ (hex) polynomial and the ‘FFFF’ (hex) initial value. In the calculation, all data within the QR code (field name, length information and values) is included in the same order (the CRC field name and length are also included in the calculation, but the CRC value is not included). Each 'hex' digit of the calculated 2-byte value is converted to a special alphanumeric character and added to the relevant field as the CRC value. For example, a CRC calculated as '097B' (hex) is included in the QR code as "6304097B".

The QR code data organization provided by the customer is shown in Table 8.

Table 8: QR Code Data Organization Provided by the Customer

Field Name	Field Code	Subfield Code:Name	Data Type	Length	Presence Status	Sample Data Value	Description
QR Code Format Indicator	85	-	N	02	Z	For the data organization in this document (version 1.0): 850210	This is the value used for the QR code data organization provided by the customer. The last two digits (data value) indicate the version number of the TR QR Code data organization. For version number "S.s", the data value is formed as "Ss" without using a punctuation mark.
QR Code Type	01	-	N	02	Z	For static QR code: 010211 For dynamic QR code: 010212	Used to distinguish between Static and Dynamic QR Codes. Data value: "11": Static QR Code where the same QR code is used for multiple transactions. "12": Dynamic QR Code where a different QR code is used for each transaction.
QR Code Producer Code	02	-	N	04	Z	02040064	The code of the QR code producer. Payment Service Providers and payment system operators deemed appropriate by the CBRT will be able to obtain a QR code producer code by applying to BKM for registration in order to generate TR QR Codes. Banks will use their EFT codes and do not need to register separately. Values shorter than 4 digits will be padded with '0' characters on the left.
QR Code Reference Number	03		ÖAN	Variable up to 12	K	030823451017	It is a unique reference number created specifically for the QR code. It is mandatory if created as a dynamic QR code, optional for static QR codes.
Commercial Transaction Indicator	04		N	01	İ	For a commercial transaction: 04011	Indicates whether the payment made using the QR code is a commercial transaction: "0": Not a commercial transaction "1": Commercial transaction
Creation Time	06		N	12	İ	For 29 May 2020 at 14.01:59: 061220052914 0159	It is the time information when the QR code was generated. YYYYMMDDHHmmss YY: Year, MM: Month, DD: Day, HH: Hour (24-hour), mm: minute, ss: Second
Expiration Time	07		N	12	İ	For 29 Mayıs 2020 saat 15.01:59: 071220052915 0159	It is the information of the last time the QR code is valid. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24 hours), DD: minute, ss: Second

Field Name	Field Code	Sub Field Code:Name	Data Type	Length	Presence Status	Sample Data Value	Description
Mobile Payment Template	32		ÖAN	variable up to 99	İ	32uuVD	It is the data template that can be used for the customer to perform mobile payment. For sub fields see. "Mobile Payments - TR QR Code Technical Principles and Rules Guide" VD: Data value of the template. uu: Total length of the data value (VD) of the template as characters.
Application Template 61			ÖAN	variable up to 99	K	61uuVD	Template containing customer account information or account information indicator. If the mobile payment template is used, one or more application templates can optionally be used. If the mobile payment template is not used, more than one application template can be used, at least one of which is mandatory. VD: Data value of the template. uu: Total length of the data value (VD) of the template as characters
		01: Account Number (IBAN)	ÖAN	26	K	0126TR1234 5678901234 5678901234	The account number (IBAN) that the customer will use to make the payment. At most one of this field, the card number field with code "02" and the easy address type field with code "04" can be filled.
		02: Card Number	ÖAN	variable up to 16	K	0216510112 3456789012	The card number that the customer will pay to. It is created without spaces in between. At most one of this field, the account number (IBAN) field with code "01" and the easy address type field with code "04" can be filled.
		03: Card Expiration Date	N	04	K	For Temmuz 2021: 03042107	If the field with code "02" (card number) is used, it indicates the expiration date of the card in YYAA format: YY: year AA: month
		04: Easy Address Type	K	01	K	For phone number use: 0401T	If an easy address is used, it indicates which type of easy address will be used. According to the defined values below, the relevant easy address must be in the field with code "05" (For current values, the "FAST Easy Addressing Service Reference Document" must be consulted): "T":Phone number
							"K":TCKN "V":VKN "Y":YKN "E":E-mail At most one of this field, the account number (IBAN) field with code "01" and the card number field with code "02" can be filled.
		05: Easy Address Value	ÖAN	variable up to 50	K	For phone number: 0512903121 234567	If there is a valid value in the easy address type field with code "04", it contains the easy address value suitable for it.
		06: Customer Number	ÖAN	variable up to 25	İ	0605A2451	Label that can be used for end-to-end customer identification (subscriber number, membership number, etc.).
		07: Customer's Name and Surname	ÖAN	Variable between 2-26	K	0711HASANY ILDIZ	Customer's name and surname in the application. It is mandatory if field "01" (IBAN) is selected, optional in other cases.
		10-20	ÖAN	Variable up to 25	İ	-	These are free fields that can be used for information not defined in other fields of the QR code.
Summary Security Value (Hash)	20		ÖAN	Variable up to 32	İ	2032A23ED34A EAE0F712AEFC B9054ED180EC	Summary security (hash) value calculated by the application that generates the QR code. The application used can use this field to verify the QR code.
Location	50		N	Variable between 16-34	İ	For Latitude: 39.939423 Longitude: 32.851791: 50163993942 332851791	Location information that can be used for QR code payment transaction and created according to Decimal Degrees (DD) format. The location value consists of two parts of equal length, the first being latitude and the second being longitude. For Latitude: EE.eeeeee and Longitude: BB.bbbbbb, the location value is specified as EEeeeeeeBBbbbbbb and no separator such as '.', ',', etc. is used. The number of 'e' and 'b' digits are equal and can be at least 6 and at most 15 depending on the precision level to be used.
CRC	63	-	ÖAN	04	Z	63040D9E	Integrity check value calculated over the entire QR code (excluding the CRC value). It is the last field of the QR code data.

5.4. QR Code Presented in Person-to-Person Payments

The QR code shown by the recipient of the payment in person-to-person payments, for which an example workflow is given in Section 4.2.3, contains the following information:

• QR Code Format Indicator: Indicates the usage model, the data structure of the QR code related to this, and the TR QR Code version number. The field with code "75" indicating the QR code model presented in person-to-person payments constitutes the first data object of the QR code.

• QR code-specific information:

  o QR Code Type indicating the static or dynamic classification of the QR code.

  o QR Code Generator Code.

  o Unique Reference Number specific to the QR code in case a dynamic QR code is used.

  o QR Code Creation Time and Last Validity Time.

  o Amount of the payment transaction.

  o Summary Security Information (Hash).

• Application Template (field with code '61'): Contains information belonging to the recipient and data specific to the application used by the recipient in person-to-person payments. In an application template, at most one of the subfields of account information (IBAN) with code "01", card number with code "02", and easy address type with code "04" can be used.

Since the total length of the field belonging to this template is at most 99 characters, the subfields whose presence is "optional" must be determined in a way that does not exceed this limit and the QR code must be created accordingly.

Multiple application templates can be present in the same QR code, with at least one being mandatory.

• CRC storing the summary information calculated for the purpose of integrity verification of the entire QR code.

The CRC, which is the last field of the QR code, is calculated according to the ISO/IEC 13239 standard using the '1021' (hex) polynomial and 'FFFF' (hex) initial value. In the calculation, all data within the QR code (field name, length information, and values) are included in the same order (the CRC field name and length are also included in the calculation, but the CRC value is not included). Each 'hex' digit of the calculated 2-byte value is converted to a special alphanumeric character and added to the relevant field as the CRC value. For example, the CRC calculated as '097B' (hex) is placed in the QR code as "6304097B"

The QR code data organization presented in person-to-person payments is shown in Table 9.

Table 9: QR Code Data Organization Presented in Person-to-Person Payments

Field Name	Area Code	Sub-Area Code:Name	Data Type	Length	Presence Status	Sample Data Value	Description
QR Code Format Indicator	75		N	02	Z	For the data organization in this document (version 1.0): 750210	This is the value used for the QR code data organization presented in person-to-person payments. The last two digits (data value) indicate the version number of the TR QR Code data organization. For version number "S.s", the data value is formed as "Ss" without using a punctuation mark.
QR Code Type	01		N	02	Z	For static QR code: 010211 For dynamic QR code: 010212	Used to distinguish between Static and Dynamic QR Codes. Data value: "11": Static QR Code where the same QR code is used for more than one transaction. "12": Dynamic QR Code where a different QR code is used for each transaction.
QR Code Issuer Code	02		N	04	Z	02040067	The code of the QR code issuer. Payment Service Providers and payment system operators deemed appropriate by the TCMB will be able to obtain a QR code issuer code by applying to BKM for registration in order to generate TR QR Codes. Banks will use their EFT codes and do not need to register separately. Values shorter than 4 digits will be padded with the '0' character on the left side.
QR Code Reference Number	03	ÖAN	Variable up to 12	K	030823451017	Unique reference number created specifically for the QR code. Mandatory if created as a dynamic QR code, optional for static QR codes.
Creation Time	06		N	12	İ	For 29 May 2020 at 14.01:59: 061220052914 0159	Time information when the QR code was generated. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24 hours), DD: minute, ss: Second
Last Validity Time	07		N	12	İ	For 29 May 2020 at 15.01:59: 071220052915 0159	Last time information when the QR code is valid. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24 hours), DD: minute, ss: Second
Amount	54		N	12	İ	For 1,23: 541200000000 0123	Indicates the amount of the payment. The last two digits indicate the decimal part (kuruş, etc.). To complete the amount to 12 digits, "0" is added to the left side.
Application Template	61	ÖAN	Variable up to 99	Z	61uuVD	More than one application template may be used, provided that at least one of them is mandatory. VD: The data value of the template.

Field Name	Field Code	Sub-Field Code:Name	Data Type	Length	Presence Status	Sample Data Value	Description
							uu: The total length of the data value (VD) of the template in characters
		01: Account Number (IBAN)	ÖAN	26	K	0126TR123456 789012345678 901234	The account (IBAN) number that the recipient of the payment wants to use to receive the payment. At most one of this field, the card number field with code “02” and the easy address type field with code “04” may be filled.
		02: Card Number	N	16	K	021651015678 32141234	The card number that the recipient of the payment wants to use to receive the payment. It is created without any spaces in between. At most one of this field, the account number (IBAN) field with code “01” and the easy address type field with code “04” may be filled.
		04: Easy Address Type	K	01	K	For phone number use: 0401T	Specifies which type of easy address the recipient of the payment wants to use if they wish to make the payment using an easy address. According to the defined values below, the relevant easy address must be present in the field with code “05” (For current values, the “FAST Kolay Adresleme Servisi Referans Dokümanı” document must be consulted): “T”:Phone number “K”:TCKN “V”:VKN “Y”:YKN “E”:E-mail At most one of this field, the account number (IBAN) field with code “01” and the card number field with code “02” may be filled.
		05: Easy Address Value	ÖAN	Variable up to 50	K	For phone number: 051290530123 4567	If there is a valid value in the easy address type field with code “04”, it contains the easy address value corresponding to it.
		07: Name and Surname of the Payment Recipient	ÖAN	Variable between 2-26	K	0711HASANYIL DIZ	The name and surname of the payment recipient. If the field with code “01” (IBAN) is selected, it is mandatory; in other cases, it is optional.
		10-20	ÖAN	Variable up to 25	İ	-	These are free fields that can be used for information not defined in the other fields of the QR code.
Summary Security Value (Hash)	20		ÖAN	Variable up to 32	İ	2032A23ED34A EAE0F712AEFCB 9054ED180EC	The summary security (hash) value calculated by the application that generates the QR code. The application used may use this field to verify the QR code.
Location	50		N	Variable between 16-34	İ	Latitude: 39.939423 Longitude: 32.851791 for: 5016399394233 2851791	It is the location information that can be used for payment transaction with QR code and created according to Decimal Degrees (DD) format. The location value consists of two parts of equal length, the first being latitude and the second being longitude. For Latitude: LL.llllll and Longitude: GG.gggggg, the location value is specified as LLllllllGGgggggg and no separator such as '.', ',', etc. is used in it. The number of 'l' and 'g' digits is equal and can be at least 6 and at most 15 depending on the precision level to be used.
CRC	63	-	ÖAN	04	Z	63040D9E	It is the integrity check value calculated over the entire QR code (excluding the CRC value in this field). It is the last field of the QR code data.

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

• BKM – TR QR Code Technical Principles and Rules Guide

• FAST – TR QR Code Technical Principles and Rules Guide

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

• FAST Easy Addressing Service Reference Document