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

January 2024
Version 1.2

CENTRAL BANK OF THE REPUBLIC OF TÜRKİYE

Date of Change	Description of Change	Version
December 2020	Initial Version	1.0
March 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
January 2024	ATM TR QR Code Cash Deposit Flow and Payment Flows with Customer Verification via Instant Notification Approval by Third Party Mobile Applications were defined.	1.2

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,

ATM: Electronic transaction devices that allow the performance of all or part of other banking transactions in addition to automatic cash withdrawal transactions,

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, and 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 issues a payment order from their own payment account or without having a payment account,

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

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

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

QR Code Routing System (KYS): The infrastructure that enables the transfer of QR codes and the information contained therein between payment service providers, and 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, as well as institutions authorized to issue cards that are 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, as well as institutions authorized to accept cards that are 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: BKM (Card Payments) TR QR Code Technical Principles and Rules Guide,

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

TR QR Code: 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

refer to.

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 carried out with card payments (not subject to clearing, subject to clearing, and using or not using the CYS) shall use the specifications in this Guide.

2. Payment service providers that wish to offer their users the possibility of payment using QR codes in card payments shall make the necessary developments in their infrastructure 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 to 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 it contains 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, shall continue to be obliged to fulfil all their 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 terminals that are PCI compliant.

• 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 CYS is used are shared below.

5.1 Reading the QR Code Generated from POS/ATM with the Mobile Application of the Issuer Institution that Issued the Card to be Used for the Transaction

5.1.1 Payment Flow Starting by Generating the 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 Issuer 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 received 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 by the Issuer Institution to the CYS. These data are encrypted with the AES key between the Issuer Institution and the CYS.

6. The CYS encrypts the incoming card information and the data in the QR code value under the AES key belonging to the Acquirer Institution and routes them to the Acquirer Institution.

7. The terminal creates an authorization message with the incoming data and routes the transaction to the Acquirer Institution's system. If the Issuer 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 Acquirer Institution, upon the request from the terminal, transmits the transaction to the BKM Switching System.

9. The BKM Switching System routes the transaction to the Issuer Institution.

10. The Issuer Institution, in addition to providing the authorization response, 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 the 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 Issuer Institution

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

1. The transaction amount is determined at 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 SKF structure.

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

4. The short QR code value read by the mobile application is transmitted to the Card Issuing Institution system.

5. The Card Issuing Institution transmits the SKF value to the KYS.

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

7. The Card Accepting Institution returns the data of the transaction related to the SKF QR code to the KYS.

8. The KYS routes the QR code information received from the Card Accepting Institution to the Card Issuing Institution.

9. The Card Issuing Institution 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 expiration 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 Issuing Institution to the KYS. These data are encrypted with the AES key between the Card Issuing Institution and the KYS.

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

12. The terminal creates an authorization message with the incoming data and routes it to the Card Accepting Institution system. If the Card Issuing Institution has requested 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 Accepting Institution routes the transaction to the BKM Routing System.

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

15. The Card Issuing Institution 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 the Generation of the BKM Long QR Code Format from the 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 the Scanning of the BKM LQF with the Card Issuing Institution'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 receipt (slip). The sales transaction is queried in the Card Accepting 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 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 Issuing Institution system.

5. The cardholder's cancellation / refund request is transmitted by the Card Issuing Institution to the KYS along 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 Accepting Institution.

7. The Card Accepting Institution 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 Issuing Institution.

5.1.4 Cancellation / Refund Flow Starting with the Generation of the BKM Short QR Code Format from the POS

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

Figure 4: Cancellation / Refund Flow Starting with the Scanning of the BKM SKF with the Card Issuing Institution'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 receipt (slip). The sales transaction is queried in the Card Accepting Institution system.

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 Issuing Institution system.

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

6. The KYS routes the incoming QR code to the Card Accepting Institution.

7. The Card Accepting Institution returns the information of the transaction related to the SKF QR code to the KYS.

8. The KYS routes the QR code information received from the Card Accepting Institution to the Card Issuing Institution.

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 Issuing Institution to the KYS along 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 Accepting Institution.

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

5.1.5 ATM TR QR Code Cash Withdrawal Transaction Flow

Figure 5 shows the general workflow for cash withdrawal with ATM TR QR Code.

Figure 5: ATM TR QR Code Cash Withdrawal Transaction Flow

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

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

3. The ATM TR QR Code value read by the mobile application is transmitted to the Card Issuing Institution 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. The KYS encrypts the data in the incoming card and QR code value under the AES key belonging to the Card Acceptor and forwards them to the originating Card Acceptor.

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

7. The terminal transmits the commission inquiry message to the Card Acceptor system.

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

9. The BKM Routing System transmits the commission inquiry message to the Card Issuer. It transmits the response returned from the Card Issuer to the Card Acceptor.

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

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

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

13. The Card Issuer transmits the transaction result information as a notification to the mobile application that initiated the QR code transaction.

14. In accordance with the authorization response received from BKM, the terminal generates the card transaction receipt and the transaction ends.

5.1.6 ATM TR QR Code Cash Deposit Transaction Flow

Figure 6 shows the general workflow for cash deposit via ATM TR QR Code.

Figure 6: ATM TR QR Code Cash Deposit Transaction Flow

1. The cardholder selects Card/Account via their mobile application and scans the QR code on the ATM.

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

3. The ATM TR QR Code value read by the mobile application is transmitted to the Card Issuer 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. The KYS encrypts the data in the incoming card and QR code value under the AES key belonging to the Card Acceptor and forwards them to the originating Card Acceptor.

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

7. The cash deposit unit of the terminal is opened and the cash deposit transaction is performed. The Cardholder confirms by checking the amount information displayed on the ATM screen.

8. The terminal transmits the commission inquiry message to the Card Acceptor system.

9. The Card Acceptor transmits the commission inquiry message to the BKM Routing System.

10. The BKM Routing System transmits the commission inquiry message to the Card Issuer. It transmits the response returned from the Card Issuer to the Card Acceptor.

11. The commission information is displayed on the terminal. The cardholder confirms the commission amount on the terminal.

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

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

14. The Card Issuer transmits the transaction result information as a notification to the mobile application that initiated the QR code transaction.

15. In accordance with the authorization response received from BKM, the terminal generates the card transaction receipt and the transaction ends.

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

In TR QR Code transactions to be carried out by reading the QR code generated from the POS with a third-party mobile application, the TR QR Code payment flow changes according to the customer verification method to be used by the Card Issuing Institution. Although the customer verification method is decided by the relevant Card Issuing Institutions within the framework of the regulations to which the Card Issuing Institutions are subject, the flows in cases where customer verification is not preferred or where the customer is preferred to be verified using a PIN are addressed in sections 5.2.1 and 5.2.3; and the flows in cases where customer verification is preferred to be performed with instant notification approval are addressed in sections 5.2.2 and 5.2.4. In addition, for such transactions, the cancellation/refund flows initiated using long and short QR codes on the POS are included in sections 5.2.5 and 5.2.6, respectively.

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

The flow given in Figure 7 describes the situation where the Card Issuing Institution prefers verification by entering the card PIN on the POS or prefers the transaction to be sent to Authorization without using any verification method.

Figure 7: Payment Flow Starting by Reading the BKM LQF 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 the QR code containing the payment details in accordance with the BKM LQF 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, expiration date of the card selected by the cardholder, and the QR code content read from the POS terminal are transmitted by the MHSK to the KYS via the informIssuer service. These data are encrypted with the AES key between the MHSK and the KYS.

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

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

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

9. The terminal creates an authorization message with the incoming data and routes the transaction to the Merchant Card Acquirer 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 Merchant Card Acquirer Institution, based on the request from the terminal, 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 rejection information as a notification to the mobile application that initiated the QR code transaction via the KYS (see 5.2.7).

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

5.2.2 Payment Flow Starting by Generating the BKM Long QR Code Format from the POS and Performed with Customer Verification via Instant Notification Approval

The flow given in Figure 8 describes the situation where the Card Issuing Institution prefers to verify its customer via instant notification approval.

Figure 8: Payment Flow Starting by Reading the BKM LQF with a Third-Party Mobile Application and Performed with Customer Verification via Instant Notification Approval

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 LQF 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, expiration date of the card selected by the cardholder, and the QR code content read from the POS terminal are transmitted by the MHSK to the KYS via the informIssuer service. These data are encrypted with the AES key between the MHSK and the KYS.

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

7. The Card Issuing Institution verifies the transaction by sending an instant notification (push approval) to the mobile application belonging to the Card Issuing Institution installed on the cardholder's mobile phone, asking them to approve the transaction. The Card Issuing Institution decides on the authentication methods to be used when obtaining payment approval via instant notification. On the screen opened after the notification, the payment information is clearly displayed and the user is presented with an approve or decline option. The card issuer may present this approve or decline option without asking for the mobile application password or after asking for it. This verification method can be used for transactions to be performed via Physical POS and Virtual POS.

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

9. The KYS transmits the data received via startQRTransaction to the Merchant Acquirer. In the event that an error is received in the StartQRTransaction service or the card information cannot be transmitted to the Merchant Acquirer to initiate authorization, the Card Issuer notifies the MHSK via the service set out in clause 5.2.7.

10. The terminal creates an authorization message with the incoming data and routes the transaction to the Merchant Acquirer's system. The Merchant Acquirer, based on the request from the terminal, either processes the transaction itself depending on the card issuing institution or transmits it to the BKM Routing System.

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

12. In addition to providing the authorization response, the Card Issuer 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.7).

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

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

The flow given in Figure 9 describes the situation where the Card Issuer prefers verification by entering the card PIN into the POS or prefers the transaction to be sent to Authorization without using any verification method.

Figure 9: Payment Flow Starting by Reading BKM KKF with 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 the QR code containing the payment details in accordance with the BKM KKF structure.

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

4. The QR code read in the Mobile Application is read and its format is determined. If it is a short QR code, the flow below is followed.

5.

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 Merchant Acquirer via the getKKFInfo service.

5.3. After the transaction data returned as a result of the getKKFInfo service is displayed on the wallet screen by the MHKS 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 is 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 Issuer and routes it to the Card Issuer.

7. The Card Issuer 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 Merchant Acquirer.

9. The terminal creates an authorization message with the incoming data and routes the transaction to the Merchant Acquirer's system. If the Card Issuer 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 Merchant Acquirer, 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 Issuer.

11. In addition to providing the authorization response, the Card Issuer 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.7).

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

5.2.4 Payment Flow Starting by Generating BKM Short QR Code Format from POS and Performing Customer Verification with Instant Notification Approval

The flow given in Figure 10 describes the situation where the Card Issuer prefers to verify its customer with instant notification approval.

Figure 10: Payment Flow with Instant Notification Approval Starting by Reading BKM KKF with 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 the QR code containing the payment details in accordance with the BKM KKF structure.

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

4. It is checked whether the QR code read in the Mobile Application is a short QR code. If it is a short QR code, the flow below is followed.

5.

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 Merchant Acquirer via the getKKFInfo service.

5.3. After the transaction data returned as a result of the getKKFInfo service is displayed on the wallet screen by the MHKS 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 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 Issuer and routes it to the Card Issuer.

7. The Card Issuer verifies the transaction by sending an instant notification (push approval) to the mobile application belonging to the Card Issuer installed on the cardholder's mobile phone and asking them to approve the transaction. The Card Issuer decides on the authentication methods to be used when obtaining payment approval via instant notification. On the screen opened after the notification, the payment information is clearly displayed and the user is presented with an approve or decline option. The card issuer may present this approve or decline option after requesting the mobile application password or without requesting the mobile application password at all.

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

9. It transmits the data received via KYS startQRTransaction to the Card Acceptor institution. In the event that an error is received in the StartQRTransaction service or the card information cannot be transmitted to the Card Acceptor Institution to initiate authorization, the Card Issuer informs the MHSK via the service in article 5.2.7.

10. The Terminal creates an authorization message with the incoming data and routes the transaction to the Card Acceptor Institution's system.

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

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

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

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

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

The flow in Figure 11 describes the cancellation/refund flow initiated by reading the BKM long QR code generated at the POS with a third-party mobile application.

Figure 11: Cancellation/Refund Flow Initiated by Reading BKM UKF with a Third-Party Mobile Application

1. At 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's system.

2. The Terminal generates the cancellation / refund QR code in accordance with the BKM UKF 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 at 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 to KYS by MHSK via the informIssuer service. This data is encrypted with the AES key between MHSK and KYS.

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

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

8. 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 Card Acceptor Institution's system. If the Card Issuer 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 Acceptor Institution, based on the request from the terminal, either processes the transaction itself depending on who the card issuer institution is or transmits it to the BKM Routing System.

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

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

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

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

The flow in Figure 12 describes the cancellation/refund flow initiated by reading the BKM short QR code generated at the POS with a third-party mobile application.

Figure 12: Cancellation/Refund Flow Initiated by Reading BKM KKF with a Third-Party Mobile Application

1. At 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's system.

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 their mobile application.

4. The QR code format read with the Mobile Application is determined. If it is a short QR code, the following flow is continued.

5.

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

5.2. KYS requests detailed information about the QR code from the Card Acceptor institution 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 in the original transaction and other QR code data are transmitted to KYS by MHSK using the informIssuerKKF service. This data is encrypted with the AES key between MHSK and KYS.

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

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

8. 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 Card Acceptor Institution's system. If the Card Issuer 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 Acceptor Institution, based on the request from the terminal, either processes the transaction itself depending on who the card issuer institution is or transmits it to the BKM Routing System.

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

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

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

5.2.7 Notification of Authorization Result to the Mobile Application

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

Figure 13: Notification of the Authorization Result

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

2. KYS transmits the transaction result to MHSK with informTxnResult.

3. The mobile application presents the transaction result data received from 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 .

Figure 14: 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 specified by the “01” field code under the root and the object specified by the “01” field code under a data template with field code “62” indicate different data from each other.

• Length: A two-digit number with a value between “01” and “99” that specifies the length of the data value of the object in characters.

• 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 values of the objects within the QR code support 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:

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

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

[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.

• 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 the usage model and, in this direction, 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 TR QR Code usage models presented by the merchant to be used for card payments are given.

6.1.1 BKM UKF Structure Presented by the Merchant

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

Table 1: BKM UKF Data Organization Presented 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 for static and dynamic QR code distinction. 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.
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	082001234567890123456789	Summary Security (Hash) Value The Summary Security value is designed so that when the Merchant is onboarded to the system, it can be checked whether the QR code was actually generated by this system. The Merchant 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 ordering for filling the field. It is sufficient to indicate supported schemes with the scheme code and unsupported ones with the value “0”. In the Issuer'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	13160123 45678901 2345 Or 00001234 567891	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.
Business Account Information	32						Used for mobile payments.
Business Code	49		N	10	Z	49100023 415672	It is the unique reference number of the business in the Business 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:	It is the location information that can be used for QR code payment transactions 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

						50163993 94233285 1791	and no separator such as '.', ',', etc. is used in it. The number of 'e' and 'b' digits is 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		ÖAN	Variable up to 99	Z	5191	It is the QR code identity template generated by the QR code generator. The ID and length information for this field is 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 version number 'S.s', the data value is created as 'Ss' without using a punctuation mark.
		02-QR Code Generator 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 generator 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.
		03-QR Code Reference Number	ÖAN	Variable up to 12	Z	03082345 1017	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 business application or the QR code generator and is used in processes such as end-to-end verification, transaction recording, or receipt generation. It can be specified by the business 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	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': Business application '05': Web '06': Payment service provider's business application
05- Terminal Device Serial Number	ÖAN	Variable up to 23	İ	05231234 56789012 34567890 ABC	The distinguishing value of 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ıs 2020 at 14.01:59: 06122005 29140159	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
07-Last Validity Time	N	12	K	For 29 Mayıs 2020 at 15.01:59: 07122005 29150159	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 Optional for static QR codes, mandatory for dynamic QR codes.
Merchant Category Code	52	N	04	Z	52041234	It is the ISO 18245:2003 compliant Merchant Category Code (MCC) of the transaction. Examples of these 4-digit codes include “5661” (shoe seller) or “5499” (supermarkets). If this field is not used, the value “0000” must be written.
Currency	53	N	03	Z	5303949	It is the ISO 4217 compliant currency code of the transaction: TRY: “949”, USD: “840”, EUR: “978”, etc.
Amount	54	N	12	K	54120000 00000123	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. 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 a 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 a tip or other amount.
Tip or Other Amount Value (Fixed)	56		N	12	K		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. 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. 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 merchant as specified in ISO 3166-1 alpha 2. For Turkey, “TR”.
Merchant Name	59		Variable up to ÖAN 25	Z	5906ABC DEF		Business name.
Business City	60		Variable up to ÖAN 15	Z	6008ISTA NBUL		City name of the business.
Postal Code	61		Variable up to ÖAN 10	İ	61053474 6		Business postal code
Additional Data Fields Template	62		K	Variable up to 99	İ	6250	Contains additional data required by the business for card payments. Since the total length of the field belonging to the template can be 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			Variable up to ÖAN 25	İ	0111TLK0 1230405		Contains the invoice number.
02 - Customer's Phone Number			Variable up to ÖAN 15	İ	02129021 23507900		Customer's mobile phone number.

		03 - Store Label	ÖAN	Variable up to 25	İ	0306AVM STR	A label information that can be used to distinguish a particular store from others.
		04 - Customer Loyalty Number	ÖAN	Variable up to 25	İ	04102315 634123	Customer's loyalty card number.
		06 - Customer Number	ÖAN	Variable up to 25	İ	06100518 894111	Label 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	ISO 639-1 compliant two-character language code. "TR": Turkish "EN": English This is the code of the (usually local) language used to resolve the merchant's name and city information encoded in the "01" and "02" coded subfields of this template. It is a mandatory field when the template is used.
		01-Merchant Name in Alternative Language	K	Variable up to 50	Z	0108AĞA ÇA.Ş.	The merchant's name 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.
		03-99 Fields reserved by EMVCo	K	Variable up to 99	-		Reserved for future use by EMVCo.
EMVCo. Reserved fields	65-79		K	Variable up to 99	İ		Reserved for future use by EMVCo.
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	6304C2B 6	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 within the QR code, including IDs, lengths, and values, are included in the calculation in the same order. The ID and length information of the CRC value are included, the CRC value itself is not included, and the calculated value is written.

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

00020101021126680010TR.COM.BKM060110820012345678901234567890910TDVMAUJ0001001N110203491 000234156725195000210020400010312180904121314040202052312345678901234567890ABC06122005291 40159071220052915015952041234530394954120000000001235802TR5906ABCDEF6008ISTANBUL6304C2B6

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

Figure 15: Example BKM Long QR Code Image

6.1.2 Summary Security (Hash) Value

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

The recommended method is as follows:

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

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

3. The Card Accepting Institution system, before starting the online authorization transaction, checks the workplace and terminal that generated the QR code by using the summary security (hash) value in the QR code sent by the terminal. If it is faulty, 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 workplace.

Table 2: BKM Short QR Code Data Organization

Field Name	Presence Status	Data Type	Length	Sample 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"	123456789012	Unique transaction reference number on a Card Accepting Institution basis, generated in a non-sequential manner.
Summary Security (Hash) Value	Z	K	"32"	01234567890123456789012345678912	Field to be determined specific to the Card Accepting Institution. The Card Accepting Institution can use this field to check that the QR code data is the QR code it generated.
CRC	Z	ÖAN	"04"	6304	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, including ID, length and values, are included in the same order for calculation. The ID and length information of the CRC value are 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 can be as follows:

9908001234567890120123456789012345678901234567891280BE

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

Figure 16: Sample BKM Short QR Code Image

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

6.1.4 ATM TR QR Code Structure

Table 3 shows the ATM TR QR Code data organization.

Table 3: ATM TR 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 TR QR Code Format.
QR Code Producer Code	Z	N	"04"	0800	The code required to generate a TR QR Code
ATM Data	Z	ÖAN	Variable up to 214		The Card Accepting Institution creates it according to its own standards.

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

Figure 17: Example ATM TR 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, Issue: 31220

• QR Code Routing System Reference Document