BKM (Card Payments) TR QR Code Technical Principles and Rules Guide

May 2022
Version 1.1

For Service Use

CENTRAL BANK OF THE REPUBLIC OF TÜRKİYE

Change Date	Change Description	Version
December 2020	First Version	1.0
May 2022	In case the card issuing institution and the institution providing mobile application service are different, new flows required for performing transactions with QR code were defined.	1.1

1 Introduction

This document, which contains the detailed technical principles and rules regarding the use of TR QR Code in transactions to be carried out through Card Payments, has been created based on the Regulation on the Generation and Use of TR QR Code in Payment Services (Regulation) and the TR QR Code Principles and Rules (Technical Document).

2 Purpose, Scope and Basis

The purpose of this Guide is to define the specifications for the regulation of the QR code structure to be used in card payments in compliance with the Regulation and the Technical Document. Transactions where the payment is carried out via QR code through a debit card, credit card or a prepaid card within the scope of the Law No. 6493 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions (Law) are considered card payments in terms of this Guide.

The flows described in this Guide shall be valid for the following terminal and QR code types.

EFTPOS
Shared EFTPOS
POS
ATM
QR codes generated for card payments in mobile applications of payment service providers
Static QR codes
Virtual POS

This document has been prepared based on the first paragraph of Article 6 of the Regulation.

3 Definitions and Abbreviations

In this Guide;

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

BKM SQF: The Short QR Code Format created for card payments in accordance with this Guide,

BKM LQF: The EMVCo-compliant Long QR Code Format created for card payments in accordance with this Guide,

BKM Routing System (Switch): The routing system operated by BKM that mediates the routing of clearing-eligible transactions executed through ATM and POS terminals to the relevant Card Issuing Institution for authorization purposes, ensures the transmission of the Card Issuing Institution's positive-negative response to the Card Accepting Institution,

EFTPOS: PCI1 compliant single POS terminal,

EMVCo2 : The association consisting of American Express, Discover, JCB, Mastercard, UnionPay and Visa,

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

[1] These are data security standards accepted at international level in the card payments industry.

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

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

QR Code Routing System (KYS): The infrastructure that enables the transfer of QR codes and the information contained therein between payment service providers and is established and operated by BKM in accordance with the Regulation,

Card Issuing Institution: Institutions that establish a debit card or credit card system and are authorized to issue cards according to this system, and institutions authorized to issue cards in the nature of payment instruments that can be issued within the scope of the Law,

Card Issuing Institution Key: The AES 256-bit key used by the Card Issuing Institution to encrypt the card and other transaction information selected by the cardholder from the mobile application,

Card Accepting Institution: Institutions that establish a debit card or credit card system and are authorized to make merchant agreements according to this system, and institutions authorized to accept cards in the nature of payment instruments that can be issued within the scope of the Law,

Card Accepting Institution Key: The AES 256-bit key used by the Card Accepting Institution to encrypt the card and other transaction information selected by the cardholder from the mobile application,

MHSK: The third-party institution providing mobile application service,

Shared EFTPOS: PCI compliant shared POS terminal,

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 recipient,

POS: Payment recording device integrated with or connected to a POS application,

Guide: The BKM (Card Payments) TR QR Code Technical Principles and Rules Guide,

TCMB: The Central Bank of the Republic of Türkiye Joint Stock Company,

TR QR Code: Refers to the QR code created in accordance with the procedures and principles set out in the TR QR Code Principles and Rules document and which can be used in payments within the scope of the Law.

4 General Principles

1. Within the scope of the Regulation, all payment services to be performed using QR code for card payments are carried out with QR codes created in accordance with the rules set out in this Guide. All kinds of TR QR Code transactions to be performed with card payments (not subject to clearing, subject to clearing, and using or not using KYS) shall use the specifications in this Guide.

2. Payment service providers that wish to offer their users the possibility of payment using QR code in card payments shall make the necessary developments in their infrastructures to generate and accept QR codes.

3. QR code generators shall ensure that QR codes are generated in accordance with the rules set out in this Guide, in line with the requests of the merchants for which they provide services for card payments.

4. The QR code generator; when it creates any QR code for card payments or adds any other data to an already created QR code, is responsible for ensuring that all data contained therein is complete and accurate and that the QR codes fully comply with the requirements in the QR code formats in this Guide.

5. In payments to be made using QR codes for card payments, all parties, especially payment service providers, continue to be obliged to fulfill all other obligations arising from the Law and other relevant legislation and not otherwise specified in this Guide.

6. In QR code transactions, PIN entry can only be made from the following types of PCI-compliant terminals.

EFTPOS
ÖKC
ATM
PCI SPOC approved terminals
PIN entry cannot be made in transactions made with static QR codes or dynamic QR codes generated on mobile devices that are not PCI SPOC compliant.

5 QR Code Usage Models for Card Payments

In card payment transactions, the workflows in cases where the KYS is used are shared below.

5.1 Reading the QR Code Generated from POS/ATM with the Mobile Application of the Card Issuing Institution That Issued the Card to Be Used for the Transaction

5.1.1 Payment Flow Starting by Generating BKM Long QR Code Format from POS

Figure 1 shows the card payment workflow regarding the use of BKM UKF offered by the merchant.

Figure 1: Payment Flow Starting by Reading BKM UKF with the Mobile Application of the Card Issuing Institution

Flow steps in which the transaction amount is determined by the merchant:

1. The transaction amount is determined on the terminal and the QR code generation process is initiated.

2. The terminal generates the QR code containing the payment details in accordance with the BKM UKF structure.

3. The cardholder reads the QR code generated on the terminal via their mobile application. The transaction amount and merchant name in the transaction data obtained from the QR code are displayed in the application.

4. The cardholder selects the card to be used for the transaction from the mobile application.

5. The card number of the card selected by the cardholder, the expiry date, the customer verification method (CVM type), the electronic commerce indicator (ECI value) and the QR code value read from the POS terminal are transmitted to the KYS by the Card Issuing Institution. These data are encrypted with the AES key between the Card Issuing Institution and the KYS.

6. The KYS encrypts the incoming card information and the data within the QR code value under the AES key belonging to the Card Acquiring Institution and routes them to the Card Acquiring Institution.

7. The terminal creates an authorization message with the incoming data and routes the transaction to the Card Acquiring Institution's system. If the Card Issuing Institution has requested a PIN as the customer verification method (CVM) type, it requests the PIN from the cardholder and also adds the PIN block data to the authorization message.

8. The Card Acquiring Institution transmits the transaction to the BKM Switching System upon the request from the terminal.

9. The BKM Switching System routes the transaction to the Card Issuing Institution.

10. In addition to providing an authorization response, the Card Issuing Institution also transmits the approval or rejection information as a notification to the mobile application that initiated the QR code transaction.

11. The terminal completes the transaction in accordance with the authorization response received via BKM.

5.1.2 Payment Flow Starting by Generating BKM Short QR Code Format from POS

Figure 2 shows the card payment workflow regarding the use of BKM KKF offered by the merchant.

Figure 2: Payment Flow Starting by Reading BKM KKF with the Mobile Application of the Card Issuing Institution

Flow steps in which the transaction amount is determined by the merchant:

1. The transaction amount is determined on the terminal and the QR code generation process is initiated.

2. The terminal generates the QR code containing the payment details in accordance with the BKM KKF structure.

3. The cardholder reads the KKF QR code generated on the terminal via their mobile application.

4. The short QR code value read by the mobile application is transmitted to the Card Issuer's system.

5. The Card Issuer transmits the KKF value to the KYS.

6. The KYS routes the incoming QR code content to the Card Acceptor.

7. The Card Acceptor returns the data relating to the transaction of the KKF QR code to the KYS.

8. The KYS routes the QR code information received from the Card Acceptor to the Card Issuer.

9. The Card Issuer displays the transaction information in its mobile application. The cardholder selects the card to be used for the transaction.

10. The card selected by the cardholder, the expiry date, the customer verification method (CVM type), the Electronic Commerce Indicator (ECI) and the QR code value read from the terminal are transmitted by the Card Issuer to the KYS. These data are encrypted with the AES key between the Card Issuer and the KYS.

11. The KYS routes the data within the incoming card and QR code value to the Card Acceptor, encrypted under the AES key belonging to the Card Acceptor.

12. The terminal creates an authorization message with the incoming data and routes it to the Card Acceptor's system. If the Card Issuer has requested a PIN as the customer verification method (CVM type), the terminal requests the PIN from the cardholder and also adds the PIN block data to the authorization message.

13. The Card Acceptor routes the transaction to the BKM Routing System.

14. The BKM Routing System routes the transaction to the Card Issuer.

15. The Card Issuer transmits the approval or decline information as a notification to the mobile application that initiated the QR code transaction.

16. The transaction is completed at the terminal in accordance with the authorization response received via BKM.

5.1.3 Cancellation / Refund Flow Starting with BKM Long QR Code Format Generated from POS

Figure 3 shows the card-based cancellation / refund workflow regarding the use of BKM LQF provided by the merchant.

Figure 3: Cancellation / Refund Flow Starting with Scanning of the BKM LQF with the Card Issuer's Mobile Application

1. At the terminal; the cancellation / refund transaction is initiated by methods such as entering the reference number on the card transaction slip. The sales transaction is queried in the Card Acceptor's system.

2. The terminal generates the cancellation / refund QR code in accordance with the BKM LQF structure. The QR code reference code (QR code id) fields of the sales transaction and the cancellation / refund transaction must be the same.

3. The cardholder reads the QR code generated at the terminal via the mobile application. The transaction amount and merchant name of the sales transaction within the transaction data obtained from the QR code are displayed in the application. The cardholder confirms the cancellation / refund transaction. (The cardholder does not need to select the card used for the transaction from the mobile application.)

4. The mobile application transmits the cardholder's cancellation / refund request to the Card Issuer's system.

5. The cardholder's cancellation / refund request is transmitted by the Card Issuer to the KYS together with the QR code value read from the terminal.

6. The KYS routes the incoming information and the data within the QR code value to the Card Acceptor.

7. The Card Acceptor generates a cancellation/refund message and routes the transaction to the BKM Routing System.

8. The BKM Routing System routes the transaction to the Card Issuer.

5.1.4 Cancellation / Refund Flow Starting with BKM Short QR Code Format Generated from POS

Figure 4 shows the card-based cancellation / refund workflow regarding the use of BKM SQF provided by the merchant.

Figure 4: Cancellation / Refund Flow Starting with Scanning of the BKM SQF with the Card Issuer's Mobile Application

2. The terminal generates the cancellation / refund QR code in accordance with the BKM Short QR Code structure. The QR code reference code (QR code id) fields of the sales transaction and the cancellation / refund transaction must be the same.

3. The cardholder reads the QR code generated at the terminal via the mobile application.

4. The mobile application transmits the short QR code value it read to the Card Issuer's system.

5. The Card Issuer transmits the short QR code value to the KYS.

6. The KYS routes the incoming QR code to the Card Acceptor.

7. The Card Acceptor returns the information relating to the transaction of the KKF QR code to the KYS.

8. The KYS routes the QR code information received from the Card Acceptor to the Card Issuer.

9. The transaction amount and merchant name of the sales transaction within the transaction data obtained from the QR code are displayed in the application. The cardholder confirms the cancellation / refund transaction. (The cardholder does not need to select the card used for the transaction from the mobile application.)

10. The cardholder's cancellation/refund request is transmitted by the Card Issuer to the KYS together with the QR code value read from the terminal.

11. The KYS routes the incoming information and the data within the QR code value to the Card Acceptor.

12. The Card Acceptor generates a standard cancellation/refund message and routes the transaction to the BKM Routing System.

5.1.5 ATM QR Code Transaction Flow

Figure 5 shows the general workflow regarding ATM QR Code usage.

Figure 5: ATM QR Code Transaction Flow

1. The cardholder reads the QR code at the ATM via the mobile application. Selects the card and amount.

2. The terminal continues to wait in the main screen (IDLE) state.

3. The ATM QR Code value read by the mobile application is transmitted to the Card Issuer's system.

4. The Card Issuer transmits the card selected by the cardholder, the expiry date, the location of the mobile application and the QR code value read from the terminal to the KYS. These data are encrypted with the AES key between the Card Issuer and the KYS.

5. KYS encrypts the data within the incoming card and QR code value under the Card Accepting Institution's AES key and forwards it to the Card Accepting Institution.

6. The Card Accepting Institution checks the location information of the cardholder and the ATM.

7. The Terminal transmits the commission inquiry message to the Card Accepting Institution system.

8. The Card Accepting Institution transmits the commission inquiry message to the BKM Routing System.

9. The BKM Routing System transmits the commission inquiry message to the Card Issuing Institution. It transmits the response returned from the Card Issuing Institution to the Card Accepting Institution.

10. The commission information is displayed on the Terminal. The cardholder confirms the commission amount on the Terminal.

11. The Card Accepting Institution routes the transaction to the BKM Routing System.

12. The BKM Routing System routes the transaction to the Card Issuing Institution.

13. The Card Issuing Institution transmits the approval or decline information as a notification to the mobile application that initiated the QR code transaction.

14. The Terminal generates the card transaction receipt in accordance with the authorization response received via BKM, and the transaction ends.

5.2 Scanning of the QR Code Generated from POS with a Third-Party Mobile Application

5.2.1 Payment Flow Starting with Generation of the BKM Long QR Code Format from POS

Figure 6: Payment Flow Starting with Scanning of the BKM LQCF with a Third-Party Mobile Application

1. The transaction amount is determined on the Terminal and the QR code generation process is initiated.

2. The Terminal generates a QR code containing the payment details in accordance with the BKM LQCF structure.

3. The cardholder scans the QR code generated on the Terminal via their mobile application. The transaction amount and merchant name in the transaction data obtained from the QR code are displayed in the application.

4. The cardholder selects the card to be used for the transaction from the mobile application.

5. The card number of the card selected by the cardholder, the expiration date, and the QR code content read from the POS terminal are transmitted by MHSK to the KYS via the informIssuer service. These data are encrypted with the AES key between MHSK and KYS.

6. KYS encrypts the incoming card information and the data within the QR code under the AES key belonging to the Card Issuing Institution and forwards them to the Card Issuing Institution via the informIssuer service.

7. The Card Issuing Institution calls the startQRTransaction service using the incoming data and transmits card, eci, cvm etc. information to the KYS.

8. KYS transmits the data received via startQRTransaction to the Card Accepting Institution.

9. The Terminal creates an authorization message with the incoming data and routes the transaction to the Card Accepting Institution's system. If the Card Issuing Institution has requested PIN as the customer verification method (CVM) type, it requests the PIN from the cardholder and also adds the PIN block data to the authorization message. Based on the request from the Terminal, the Card Accepting Institution either processes the transaction itself or transmits it to the BKM Routing System, depending on who the card issuing institution is.

10. The BKM Routing System routes the transaction to the Card Issuing Institution.

11. In addition to providing an authorization response, the Card Issuing Institution also transmits the approval or decline information as a notification to the mobile application that initiated the QR code transaction via the KYS (see 5.2.5).

12. The Terminal completes the transaction in accordance with the authorization response received via BKM.

5.2.2 Payment Flow Starting with Generation of the BKM Short QR Code Format from POS

Figure 7: Payment Flow Starting with Scanning of the BKM SQCF with a Third-Party Mobile Application

1. The transaction amount is determined on the Terminal and the QR code generation process is initiated.

2. The Terminal generates a QR code containing the payment details in accordance with the BKM SQCF structure.

3. The cardholder scans the QR code generated on the Terminal via their mobile application.

4. The QR code read in the Mobile Application is scanned and its format is determined. If it is a short QR code, the flow continues as follows.

5.1. The MHSK calls the KYS getKKFInfo service and requests detailed information about the QR code.

5.2. The KYS requests detailed information about the QR code from the card acceptor institution via the getKKFInfo service.

5.3. After the transaction data returned as a result of the getKKFInfo service is displayed by the MHKS on the wallet screen and approval is obtained, the number of the card selected by the cardholder, its expiry date, and the QR code value read from the POS terminal are transmitted by the MHSK to the KYS using the informIssuerKKF service. This data is encrypted with the AES key between the MHSK and the KYS.

6. The KYS encrypts the data received via the informIssuerKKF service under the AES key belonging to the Card Issuer Institution and routes it to the Card Issuer Institution.

7. The Card Issuer Institution calls the KYS startQRTransaction service by also adding the incoming data and values such as eci, cvm.

8. The KYS transmits the data received via startQRTransaction to the Card Acceptor Institution.

9. The terminal creates an authorization message with the incoming data and routes the transaction to the system of the Card Acceptor Institution. If the Card Issuer Institution has requested PIN as the cardholder verification method (CVM) type, it requests the PIN from the cardholder and also adds the PIN block data to the authorization message. The Card Acceptor Institution, based on the request coming from the terminal and depending on who the card issuer institution is, either processes the transaction itself or transmits it to the BKM Routing System.

10. The BKM Routing System routes the transaction to the Card Issuer Institution.

11. In addition to providing an authorization response, the Card Issuer Institution also transmits the approval or decline information as a notification via the KYS to the mobile application that initiated the QR code transaction (see 5.2.5).

12. The terminal completes the transaction in accordance with the authorization response coming via BKM.

5.2.3 Cancellation / Refund Flow Initiated by Generating the BKM Long QR Code Format from the POS

Figure 8: Cancellation/Refund Flow Initiated by Reading the BKM LQF with a Third-Party Mobile Application

1. On the terminal, the cancellation / refund process is initiated by methods such as entering the reference number on the card transaction slip. The sales transaction is queried in the Card Acceptor Institution system.

2. The terminal generates the cancellation / refund QR code in accordance with the BKM LQF structure. The QR code reference code (QR code id) fields of the original sales transaction and the cancellation / refund transaction must be the same.

3. The cardholder reads the QR code generated on the terminal via their mobile application.

4. The transaction amount, transaction type, and merchant name in the transaction data obtained from the QR code are displayed in the application, and the cardholder approves the cancellation/refund transaction.

5. The card information in the original transaction and the QR code value read from the POS terminal are transmitted by the MHSK to the KYS via the informIssuer service. This data is encrypted with the AES key between the MHSK and the KYS.

6. The KYS encrypts the incoming card information and the data within the QR code value under the AES key belonging to the Card Issuer Institution and routes it to the Card Issuer Institution via the informIssuer service.

7. The Card Issuer Institution calls the startQRTransaction service using the incoming data and transmits information such as card, eci, cvm, etc. to the KYS.

8. The KYS transmits the data received via startQRTransaction to the Card Acceptor institution.

10. The BKM Routing System routes the transaction to the Card Issuer Institution.

12. The terminal completes the transaction in accordance with the authorization response coming via BKM.

5.2.4 Cancellation / Refund Flow Initiated by Generating the BKM Short QR Code Format from the POS

Figure 9: Cancellation/Refund Flow Initiated by Reading the BKM SQF with a Third-Party Mobile Application

3. The cardholder reads the QR code generated on the terminal via their mobile application.

4. The format of the QR code read with the Mobile Application is determined. If it is a short QR code, the flow continues as follows.

5.1. The MHSK calls the KYS getKKInfo service and requests detailed information about the QR code.

5.2. The KYS requests detailed information about the QR code from the organization accepting the KYS Card via the getKKInfo service.

5.3. The transaction amount and merchant name in the transaction data are displayed in the application and the cardholder approves the transaction.

5.4. The card information and other QR code data in the original transaction are transmitted to the KYS by the MHSK using the informIssuerKKF service. This data is encrypted with the AES key between the MHSK and the KYS.

6. The KYS encrypts the data received via the informIssuerKKF service under the AES key belonging to the Card Issuing Institution and forwards it to the Card Issuing Institution.

7. The Card Issuing Institution calls the KYS startQRTransaction service by also adding the incoming data and values such as eci, cvm.

8. The KYS transmits the data received via startQRTransaction to the Card Accepting Institution.

9. The terminal creates an authorization message with the incoming data and routes the transaction to the Card Accepting Institution's system. If the Card Issuing Institution has requested PIN as the customer verification method (CVM) type, it requests the PIN from the cardholder and also adds the PIN block data to the authorization message.

The Card Accepting Institution, based on the request from the terminal, either processes the transaction itself depending on who the card issuing institution is or transmits it to the BKM Routing System.

10. The BKM Routing System routes the transaction to the Card Issuing Institution.

11. The Card Issuing Institution, in addition to providing an authorization response, also transmits the approval or rejection information as a notification to the mobile application that initiated the QR code transaction (see 5.2.5).

12. The terminal completes the transaction in accordance with the authorization response received via BKM.

5.2.5 Notification of the Authorization Result to the Mobile Application

The authorization result is transferred from the card issuing institution to the MHSK via the KYS, and the MHSK transmits the incoming response to the mobile application; the mobile application may display the authorization result to the user.

Figure 10: Notification of the Authorization Result

1. The card issuing institution transmits the authorization result to the KYS with informTxnResult.

2. The KYS transmits the authorization result to the MHSK with informTxnResult.

3. The mobile application presents the authorization result data received from the MHSK to the user on the screen.

6 QR Code Specifications for BKM Card Payments

6.1 QR Code Data Organization and Naming Rules

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

[3] An object that is not located under any data template.

[4] The relevant information is taken from the document "TR QR Code Principles and Rules", which is an annex to the Regulation.

Figure 11: QR Code Data Structure Organization

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

Field code: Consists of two digits between "00" and "99" and specifies the identity of the object. Within a QR code, all field names have a unique value at the root level or within the data template in which they are located. 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 field code "62" refer to different data.
Length: A two-digit number indicating the length of the data value belonging to the object in characters and 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 shown in the form "020820200530".

The data value of the objects within the QR code supports the following data types:

Character String (K): A data type containing characters created in accordance with UTF-8 5 character encoding.
Special Alphanumeric (ÖAN): A data type containing digits from '0'-'9', letters in the alphabet and punctuation marks. It is a subset of the Character String data type.
Numeric (N): A data type containing digits from '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 desired to be present in the QR code, the presence statuses of these objects are 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 the type of the QR code suitable for its usage model and, accordingly, the structure, representation and version of the remaining data. Applications parse all the data by first reading this object in the QR code.

In this section, definitions of QR code data structures for the BKM UKF, summary security (hash) value, BKM Short QR Code and ATM QR Code usage models provided by the merchant to be used for card payments are given.

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

6.1.1 BKM UKF Structure Provided by the Merchant

The BKM UKF structure has been rearranged to comply with the Technical Document and its data organization is shown in Table 1.

Table 1: BKM UKF Data Organization Provided by the Merchant

Field Name	Field Code	Subfield Code-Name	Data Type	Length	Presence Status	Example Data Value	Description and Values
QR Code Format Indicator	00		N	02	Z	000201	000201: QR code presented by the merchant in EMV format
QR Code Type	01		N	02	Z	010211	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	26		ÖAN	Variable up to 99	Z	2668	ID and length information for this field
		00- Universally Unique Identifier	ÖAN	10	Z	0010TR.COM.BKM	BKM's reverse domain name
		06- Transaction Type	N	01	Z	06011	Transaction type associated with the QR code 1: Sale 2: Installment Sale 3: Cancellation 4: Refund
		08 - Summary Security Value	ÖAN	Variable up to 32	Z	0820012 3456789 0123456 789	Summary Security (Hash) Value The Summary Security value is designed to check whether the QR code was actually generated by this system when the transaction is entered into the Card Acceptor Institution system. The Card Acceptor Institution may fill this field with a value of its own determined length when generating the QR code, or may assign random values.
		09 - Schemes	ÖAN	Variable up to 10	Z	0910TDV MAUJ000	Supported schemes (Troy, Discover, Amex, Visa, Mastercard, Unionpay, JCB) (There is no specific order for filling the field. It is sufficient to indicate supported schemes with the scheme code and unsupported ones with the value “0”.

						In the Card Issuer Institution's mobile application, cards belonging to the schemes indicated as supported in the QR code must be listed.)
10 - Brand	ÖAN	01	Z	1001N	Brand POS indicator (B/M/W/A/None) A:Axess B:Bonus F:ParaPuan M:Maximum P:Paraf W:World Z:Bankkart Combo N:No Brand Support
11 – Number of installments	N	02	İ	110203	Number of installments
13- RRN	N	16	K	1316012 3456789 012345 Or 0000123 4567891	Used in refund transactions, the RRN value of the sale transaction. Values shorter than 16 digits will be completed with the '0' character on the left side. Example 0000123456789123
Merchant Account Information	27	Reserved for future use for BKM.
Merchant Account Information	28	Reserved for future use for BKM.
Merchant Account Information	29	Reserved for future use for BKM.
Merchant Account Information	30-31	Used for FAST.
Merchant Account Information	32	Used for mobile payments.
Merchant Code	49	N	10	Z	4910002 3415672	The unique reference number of the merchant in the Merchant Registry System. Values shorter than 10 digits will be completed with the '0' character on the left side.
Location	50	N	Variable between 16-34	İ	For latitude 39.93942 3 and longitude 32.85179 1, the location value: 5016399 3942332 851791	It is the location information that can be used for payment transactions with QR code and is created according to the 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 in it. The number of 'e' and 'b' digits is equal, and the precision to be used

						can be at least 6 and at most 15 depending on the degree.
QR Code Identity Information Template	51		Variable up to ÖAN 99	Z	5191	It is the QR code identity template generated by the QR code producer. The ID and length information of this field are calculated and written together with the sum of the subfields.
	00-Version Number	N	02	Z	For the data organization in this guide (version 1.0): 000210	It is the TR QR code version number complied with. For the version number "S.s", the data value is created as "Ss" without using a punctuation mark.
	02-QR Code Producer Code	N	04	Z	02040001	The code required to generate a TR QR code. Payment Service Providers and payment system operators deemed appropriate by the TCMB will be able to obtain a QR code producer code by applying to BKM for registration in order to generate a TR QR code. 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.
	03-QR Code Reference Number	Variable up to ÖAN 12	Z	030823451017	It is the unique reference number generated for the QR code. The transaction reference number within the QR code cannot be generated sequentially, it must be a random value. It is provided by the merchant application or the QR code producer and is used in processes such as end-to-end verification, transaction recording or receipt generation. It can be specified by the merchant within the QR code or can be a marker 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.
	04-Terminal Type	N	02	İ	For POS device: 040202	Type of device that generated the QR code. 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
05- Terminal Device Serial Number	Variable up to ÖAN 23	İ	0523123 4567890 1234567 890ABC	Distinctive value belonging to the QR code generating device or terminal (for example, terminal number and/or terminal serial number).
06- Creation Time	N	12	Z	For 29 May 2020 at 14.01:59: 0612200 5291401 59	It is the time information when the QR code was generated. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24 hours), DD: minute, ss: Second
07- Last Validity Time	N	12	K	For 29 May 2020 at 15.01:59: 0712200 5291501 59	It is the last time information that the QR code is valid. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24 hours), DD: minute, ss: Second Optional for static QR codes, mandatory for dynamic QR codes.
Merchant Category Code	52	N	04	Z	5204123 4	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	K	5412000 0000001 23	If the payment amount is requested to be entered into the application by the customer, this field is not included. Otherwise, this field is present. It 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.). To complete the amount to 12

						digits, “0” is added to the left side.
Tip or Other Amount Indicator	55	N	02	İ		It is the 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 fixed other amount or other amount. “03”: Indicates that the percentage specified in the field with code “57” will be taken from the customer as tip or other amount.
Tip or Other Amount Value (Fixed)	56	N	12	K		It indicates 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.). To complete the amount to 12 digits, “0” is added to the left side.
Tip or Other Amount Value (Percentage)	57	N	05	K	For the value %3,25, 00325	Indicates the percentage tip or other amount quantity. 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 quantity. To complete the rate to five digits, “0” is added to the left side.
Country Code	58	ÖAN 02	Z	5802TR		The 2-digit country code of the workplace as specified in ISO 3166-1 alpha 2. For Türkiye, “TR”.
Workplace Name	59	ÖAN up to 25 variable	Z	5906ABC DEF		Workplace name.
Workplace City	60	ÖAN up to 15 variable	Z	6008ISTA NBUL		The city name of the workplace.
Postal Code	61	ÖAN up to 10 variable	İ	6105347 46		Workplace postal code
Additional Data Fields Template	62	K	variable up to 99	İ	6250	Contains additional data needed by the workplace for card payments. Since the total length of the field belonging to the 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.
01 - Invoice Number	ÖAN	up to 25 variable	İ	0111TLK 0123040 5	Contains the invoice number.
02 - Customer's Phone Number	ÖAN	up to 15 variable	İ	0212902 1235079 00	Customer's mobile phone number.
03 - Store Label	ÖAN	up to 25 variable	İ	0306AV MSTR	A label information that can be used to distinguish a particular store from others.
04 - Customer Loyalty Number	ÖAN	up to 25 variable	İ	0410231 5634123	Customer's loyalty card number.
06 - Customer Number	ÖAN	variable up to 25	İ	0610051 8894111	Tag value used specifically for the customer. For example, it may be the customer's membership number for a membership.
08- Payment purpose	ÖAN	2	İ		It will not be used for card payments.
09 - Additional Consumer Data	ÖAN	variable up to 3	İ		It will not be used for card payments.
Merchant Language Information Template	64	K	variable up to 99	İ	6430	Merchant information is specified in an alternative language.
00-Preferred Language	ÖAN	02	Z	0002TR	Two-character language code compliant with ISO 639-1. "TR": Turkish "EN": English This is the code of the (usually local) language used to resolve the name of the merchant and the city where it is located, encoded in the "01" and "02" coded subfields of this template. It is a mandatory field if the template is used.
01-Merchant Name in Alternative Language	K	variable up to 50	Z	0108AĞA ÇA.Ş.	The name of the merchant encoded in the language specified in the "00" field.
02-Merchant City Name in Alternative Language	K	variable up to 25	İ	0208İSTA NBUL	The name of the city where the merchant is located, encoded in the language specified in the "01" field.

		K	variable up to 99	-		Reserved by EMVCo for future use.
EMVCo. Reserved fields	65-79	K	variable up to 99	İ		Reserved by EMVCo for future use.
Free Templates	80-99	N	variable up to 99	İ		These are fields reserved for future use within the scope of TR QR Code. Application must be made to the CBRT for use.
CRC	63	ÖAN 04	Z	6304C2B6	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 CRC value must be calculated using ISO/IEC 13239, polynomial '1021', initial value 'FFFF'. All data in the QR code is included in the calculation with ID, length and values in the same order. The ID and length information of the CRC value is included, the CRC value is not included, the calculated value is written.

An example plain text value formed in the BKM UKF structure may be as follows:

00020101021126680010TR.COM.BKM060110820012345678901234567890910TDVMAUJ0001001N1102 03491000234156725195000210020400010312180904121314040202052312345678901234567890ABC0 612200529140159071220052915015952041234530394954120000000001235802TR5906ABCDEF6008IS TANBUL6304C2B6

The QR code image generated for this plain text is shown in Figure 12.

Figure 12: Example BKM Long QR Code Image

6.1.2 Summary Security (Hash) Value

The summary security (hash) value in the QR code is used by the Card Acceptor Institution to check that the QR code is one it generated itself before directing the authorization transaction to the BKM Routing System.

The recommended method is as follows:

1. A summary security (hash) value of a value signed with a symmetric or asymmetric industry standard algorithm (DES, TDES, RSA, ECC etc.) with different keys in the breakdown of merchant, merchant group, channel or QR code client is calculated and written to the QR code.

2. This value is not taken into account by the Card Issuer Institution application.

3. The Card Acceptor Institution system checks the merchant and terminal that generated the QR code using the summary security (hash) value in the QR code sent by the terminal before starting the online authorization transaction. If it is incorrect, the transaction is aborted. If the summary security (hash) value is verified, the transaction continues.

6.1.3 BKM Short QR Code Structure

Table 2 shows the BKM Short QR Code data organization presented by the merchant.

Table 2: BKM Short QR Code Data Organization

Field Name	Presence Status	Data Type	Length	Example Data Value	Description
QR Code Format Indicator	Z	N	"02"	99	Determines the data structure in line with the usage model. "99": BKM KKF format "96": FAST KK and BKM KKF format6
QR Code Generator Code	Z	N	"04"	0800	Code required to generate TR QR code
QR Code Reference Number	Z	ÖAN	"12"	1234567890 12	Unique transaction reference number on the basis of the Card Acceptor Institution, generated in a non-sequential manner.
Summary Security (Hash) Value	Z	K	"32"	0123456789 0123456789 0123456789 12	Field to be determined specific to the Card Acceptor Institution. The Card Acceptor Institution can use this field to check that the QR code data is a QR code it generated itself.
CRC	Z	ÖAN	"04"	6304	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 CRC value must be calculated using ISO/IEC 13239, polynomial '1021', initial value 'FFFF'. All data in the QR code is included in the calculation with ID, length and values in the same order. The ID and length information of the CRC value is included, the CRC value is not included, the calculated value is written.

An example plain text value formed in the BKM Short QR Code structure may be as follows:

[6] It is the short QR code indicator that both payment infrastructures (FAST and card payments) are supported by the merchant and the merchant bank, and the customer can choose between these payment infrastructures.

9908001234567890120123456789012345678901234567891280BE The QR code image generated for this plain text is shown in Figure 13.

Figure 13: Sample BKM Short QR Code Image

6.1.4 ATM QR Code Structure

Table 3 shows the ATM QR Code data organization.

Table 3: ATM QR Code Data Organization
Field Name	Presence Status	Data Type	Length	Sample Data Value	Description
QR Code Format Indicator	Z	N	"02"	98	The value '98' is used for the ATM QR Code Format.
QR Code Generator Code	Z	N	"04"	0800	The code required to generate a TR QR Code
ATM Data	Z	ÖAN	Variable up to 214		Created by the Card Accepting Institution according to its own standards.

When an example plain text value in the ATM QR Code structure is '98080012345678901201234567890123456789', the QR code image consisting of this plain text value is shown in Figure 14.

Figure 14: Sample ATM QR Code Image

7 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
Unicode: Unicode Standard, specifically the UTF-8 encoding form
EMVCo QR Code Specification for Payment Systems, Merchant Presented Mode, Version 1.0, July 2017
Regulation on the Generation and Use of TR QR Code in Payment Services, Official Gazette, 21 August 2020, No: 31220
QR Code Routing System Reference Document

BKM (Card Payments) TR QR Code Technical Principles and Rules Guide, Version 1.1