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

September 2025
Version 1.3

CENTRAL BANK OF THE REPUBLIC OF TÜRKİYE

Date of Change	Description of Change	Version
December 2020	First Version	1.0
March 2022	New flows required for performing transactions with QR code in case the card issuing and mobile application service providing institutions are different 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
September 2025	Cross-Border TR QR Code Payment Flows were defined. Textual updates were made.	1.3

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
Cash Register
ATM
QR codes generated for card payments in mobile applications of payment service providers
Static QR codes
Dynamic 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,

BKM: Interbank Card Center Joint Stock Company,

BKM SQF: The Short QR Code Format created for card payments according to this Guide,

BKM LQF: The EMVCo compatible Long QR Code Format created for card payments according to 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,

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

EFTPOS: PCI1 compliant single POS terminal,

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

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,

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

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,

Cash Register: A payment recording device integrated with or connected to a POS application,

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

Cross-Border Mobile Application: The mobile application of the institution resident abroad used to perform cross-border TR QR code payments,

Static QR code: The QR code with fixed content that can be used in more than one payment transaction,

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 that can be used in payments within the scope of the Law,

VPOS (Virtual POS): The online card acceptance tool that performs card payment transactions over the internet,

Wallet ID (Wallet Program Data): The identifier components to be assigned by BKM specific to the mobile application through which the TR QR code payment is initiated,

Regulation: The Regulation on the Generation and Use of TR QR Code in Payment Services published in the Official Gazette dated 21 August 2020 and numbered 31220,

refer to.

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

4 General Principles

1. Within the scope of the Regulation, all payment services to be performed using QR codes for card payments shall be carried out with QR codes created in accordance with the rules set out in this Guide. All types 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 KYS) 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 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 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 fulfill all other obligations arising from the Law and other relevant legislation and not otherwise specified in this Guide. This situation covers all regulations to which payment service providers are subject, especially their obligations within the framework of the regulations of the Financial Crimes Investigation Board of the Ministry of Treasury and Finance.

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.

7. Within the scope of Article 10 of the Regulation, for QR code payment transactions where one of the parties to the transaction is resident abroad and the infrastructure of the institution resident abroad is used for the payment transaction, the use of TR QR Code is not mandatory, but if it is desired to use the card payment TR QR Code, the flows set out in this document must be used.

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 Issuing Institution of 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 presented by the merchant.

Figure 1: Payment Flow Starting by Reading BKM UKF with the Mobile Application of the 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, expiry date of the card selected by the cardholder, the customer verification method (CVM type), electronic commerce indicator (ECI value), and the QR code value read from the POS terminal are transmitted by the Issuing Institution to the KYS. These data are encrypted with the AES key between the Issuing Institution and the KYS.

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

7. The terminal creates an authorization message with the incoming data and routes the transaction to the Acquiring Institution's system. If the 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.

8. The Acquiring 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 Issuing Institution.

10. In addition to providing the authorization response, the 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 the BKM Short QR Code Format from POS

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

Figure 2: Payment Flow Starting by Reading BKM KKF with the Mobile Application of the 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 Issuing Institution's system.

5. The Card Issuing Institution transmits the KKF 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 related to the transaction concerning the KKF QR code to the KYS.

8. The KYS routes the QR code information coming 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, its 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 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 in the incoming card and QR code value to the Card Accepting Institution by encrypting it 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's system. If the Card Issuing Institution 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 Accepting Institution routes the transaction to the BKM Switching System.

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

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

16. The transaction is completed at the terminal in accordance with the authorization response coming through BKM.

5.1.3 Cancellation / Refund Flow Starting by Generating BKM Long QR Code Format from POS

Figure 3 shows the card cancellation / refund workflow regarding the use of BKM UKF offered by the merchant.

Figure 3: Cancellation / Refund Flow Starting by Reading BKM UKF 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 slip. The sales transaction is queried in the Card Accepting 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 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 belonging to the sales transaction in the transaction data obtained from the QR code are displayed in the application. The cardholder approves 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's system.

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

6. The KYS routes the incoming information and the data in 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 Switching System.

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

5.1.4 Cancellation / Refund Flow Starting by Generating BKM Short QR Code Format from POS

Figure 4 shows the card cancellation / refund workflow regarding the use of BKM KKF offered by the merchant.

Figure 4: Cancellation / Refund Flow Starting by Reading BKM KKF with the Card Issuing Institution'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 has read to the Card Issuing Institution's 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 related to the transaction concerning the KKF QR code to the KYS.

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

9. The transaction amount and merchant name belonging to the sales transaction in the transaction data obtained from the QR code are displayed in the application. The cardholder approves 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 together with the QR code value read from the terminal.

11. The KYS routes the incoming information and the data in 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 Switching 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: Cash Withdrawal Transaction Flow with ATM TR QR Code

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

4. The Card Issuing Institution transmits the card selected by the cardholder, its 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 Issuing Institution and the KYS.

5. The KYS routes the data in the incoming card and QR code value to the acquiring Card Accepting Institution by encrypting it under the AES key belonging to the Card Accepting Institution.

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

7. The terminal sends the commission inquiry message to the Card Acceptor Institution's system.

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

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

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

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

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

13. The Card Issuer Institution sends 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 via BKM, the terminal produces 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 with ATM TR QR Code.

Figure 6: ATM TR QR Code Cash Deposit Transaction Flow

1. The cardholder selects Card/Account via the 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 Institution's system.

4. The Card Issuer Institution 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 Institution and the KYS.

5. KYS encrypts the data within the incoming card and QR code value under the AES key of the Card Accepting Institution 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 cash deposit unit 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 Accepting Institution system.

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

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

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

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

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

14. The Card Issuing Institution 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 scanning the QR code generated from POS with a third-party mobile application, the TR QR Code payment flow varies according to the customer authentication method to be used by the Card Issuing Institution. While the decision on the customer authentication method is made by the relevant Card Issuing Institutions within the framework of the regulations they are subject to, the flows in cases where customer authentication is not preferred or where authentication of the customer using a PIN is preferred are addressed in sections 5.2.1 and 5.2.3; and the flows in cases where customer authentication via instant notification approval is preferred are addressed in sections 5.2.2 and 5.2.4. In addition, cancellation/refund flows initiated at POS using long and short QR codes for such transactions are also included in sections 5.2.5 and 5.2.6, respectively.

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

The flow presented in Figure 7 describes the situation where the Card Issuing Institution prefers authentication to be performed by entering the card PIN at the POS or prefers the transaction to be transmitted to Authorization without using any authentication method.

Figure 7: Payment Flow Starting with Scanning of 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 and expiration date of the card selected by the cardholder, along with 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 uses the incoming data to call the startQRTransaction service 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 system of the Card Accepting Institution. If the Card Issuing Institution has requested the customer authentication method (CVM) type as PIN, 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 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. In accordance with the authorization response received from BKM, the terminal completes the transaction.

5.2.2 Payment Flow Starting with Generation of BKM Long QR Code Format from POS and Performing Customer Authentication with Instant Notification Approval

The flow presented in Figure 8 describes the situation where the Card Issuing Institution prefers to authenticate its customer with instant notification approval.

Figure 8: Payment Flow Starting with Scanning of BKM LQCF with a Third-Party Mobile Application and Performing Customer Authentication with Instant Notification Approval

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.

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

7. The Card Issuing Institution validates the transaction by requesting the cardholder to approve the transaction by sending an instant notification (push approval) to the Card Issuing Institution's mobile application installed on the cardholder's mobile phone.

The Card Issuing Institution decides on the identity verification methods to be used when obtaining payment approval via instant notification. In 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 made 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 Card Acquirer. In case an error is received in the startQRTransaction service or the card information cannot be transmitted to the Card Acquirer to initiate authorization, the Card Issuer informs the MHSK using the service specified in article 5.2.7.

10. The terminal creates an authorization message with the incoming data and routes the transaction to the Card Acquirer's system.

Based on the request from the terminal, the Card Acquirer either processes the transaction itself depending on the Card Issuer 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 approve 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 from the BKM.

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

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

Figure 9: Payment Flow Starting with Scanning of the BKM KKF by 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 KKF 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 following flow continues.

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

5.2. The KYS requests detailed information regarding the QR code from the Card Acquirer via the getKKFInfo service.

5.3. After the transaction data returned as a result of the getKKFInfo service are displayed on the wallet screen by the MHKS and approval is obtained, the number of the card selected by the cardholder, the expiry date, and the QR code value read from the POS terminal are transmitted to the KYS by the MHSK using the informIssuerKKF service. These data are 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 them to the Card Issuer.

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

8. The data received via startQRTransaction from the KYS are transmitted to the Card Acquirer.

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 forwards 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 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 from BKM.

5.2.4 Payment Flow Starting with Generation of BKM Short QR Code Format from POS and Customer Verification with Instant Notification Approval

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

Figure 10: Payment Flow Starting with Scanning of BKM SQRF with a Third-Party Mobile Application and Instant Notification Approval

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 SQRF structure.

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

4. In the Mobile Application, it is checked whether the scanned QR code is a short QR code. If it is a short QR code, the following flow continues.

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

5.2. KYS requests detailed information regarding 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 are displayed on the wallet screen by MHKS and approval is obtained, the number of the card selected by the cardholder, the expiration date, and the QR code value read from the POS terminal are transmitted to KYS by MHSK using the informIssuerKKF service. These data are 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 Institution and routes it to the Card Issuer Institution.

7. The Card Issuer Institution validates the transaction by sending an instant notification (push approval) to the Card Issuer Institution's mobile application installed on the cardholder's mobile phone, requesting them to approve the transaction. The Card Issuer Institution decides on the identity verification methods to be used when obtaining payment approval via instant notification. The payment information is clearly displayed on the screen that opens after the notification, and the user is offered the option to approve or reject. The card issuer institution may offer this approval or rejection option after requesting the mobile application password or without requesting the mobile application password at all.

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

9. KYS transmits the data received via startQRTransaction to the Card Acceptor Institution. In case 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 Institution informs MHSK using the service specified in section 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 forwards it to the BKM Routing System.

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

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

5.2.5 Cancellation / Refund Flow Starting with Generation of BKM Long QR Code Format from POS

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

Figure 11: Cancellation/Refund Flow Starting with Scanning of BKM LQRF with a Third-Party Mobile Application

1. On 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 Institution system.

2. The Terminal generates the cancellation / refund QR code in accordance with the BKM LQRF structure. The QR code reference code (QR code id) fields of the cancellation / refund transaction must be the same as those of the original sales transaction.

3. The cardholder scans 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 from the original transaction and the QR code value read from the POS terminal are transmitted to KYS by MHSK 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 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 uses the incoming data to call the startQRTransaction service 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 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 Acceptor Institution, based on the request from the Terminal, either processes the transaction itself depending on who the Card Issuer Institution is, or forwards it to the BKM Routing System.

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

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 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 Starting with the Generation of the BKM Short QR Code Format from the POS

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

Figure 12: Cancellation/Refund Flow Starting with the Scanning of the BKM Short QR Code Format by a Third-Party 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 Accepting Institution's system.

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

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

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

5.2. KYS requests detailed information regarding the QR code from the Card Accepting 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 and other QR code data from the original transaction 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 forwards it to the Card Issuer.

7. The Card Issuer adds values such as eci and cvm to the incoming data and calls the KYS startQRTransaction service.

8. The data received via startQRTransaction at KYS is transmitted 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 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. 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 the identity of the Card Issuer.

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

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

5.2.7 Notification of the Authorization Result to the Mobile Application

The authorization result is transferred from the card issuer to MHSK via KYS, and MHSK transmits the incoming response to the mobile application, allowing the mobile application to display the authorization result to the user.

Figure 13: Notification of the Authorization Result

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

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

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

5.3 Reading the TR QR Code Generated from the POS with a Cross-Border Mobile Application

For transactions to be carried out by reading TR QR Codes displayed at domestic POS terminals with the mobile applications of payment service providers established abroad, a separate Wallet ID will be assigned by BKM specific to the foreign mobile application.

All transactions will be carried out only using these Wallet IDs assigned by BKM, and all related transactions will be transmitted to the KYS with this ID. Payment service providers are responsible for ensuring that such transactions they intermediate are carried out using the correct Wallet ID.

5.3.1 Reading the TR QR Code Generated from the POS with a Cross-Border Mobile Application and Direct Transmission to the Domestic Contracted Payment Service Provider (Card Issuer)

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

The flow given in Figure 14 describes the flow of reading the BKM long QR code format generated from the POS with a Cross-Border Mobile Application and its direct transmission to the Domestic Contracted Payment Service Provider (Card Issuer).

Figure 14: Reading the BKM UKF with a Cross-Border Mobile Application and Direct Transmission to the Domestic Contracted Payment Service Provider

1. The transaction amount is entered at the terminal and a request to generate a TR QR Code is made from the Merchant Acquirer.

2. The terminal generates a TR QR Code in accordance with the BKM UKF structure and displays it on the screen.

3. The displayed TR QR Code is read with the Cross-Border Mobile Application.

4. The read QR code data is transmitted to the Cross-Border Institution. The transaction amount and merchant name in the transaction data obtained from the TR QR Code are displayed in the application.

5. The read TR QR Code data and the payment request are routed to the Card Issuer.

6. The Card Issuer transmits the card number, expiration date, customer verification method (CVM type), electronic commerce indicator (ECI value), and the TR QR Code value read from the POS terminal to the KYS. This data is encrypted with the AES key between the Card Issuer and the KYS.

7. The KYS encrypts the card information (Card no, expiry date) and transaction data under the AES key belonging to the Merchant Acquirer and routes it to the Merchant Acquirer.

8. The terminal creates an authorization message with the incoming data and routes the transaction to the Merchant Acquirer's system.

9. The authorization request is routed by the Merchant Acquirer to the BKM Routing System.

10. The BKM Routing System transmits the incoming authorization request to the Card Issuer.

11. The transaction result is notified to the terminal by the Merchant Acquirer. Simultaneously, the transaction result is transmitted to the Cross-Border Institution by the Card Issuer.

12. The terminal generates the slip according to the transaction result. At the same time, the transaction result is transmitted to the Cross-Border Mobile Application and the display of the transaction result is provided through the application.

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

The flow given in Figure 15 describes the situation of reading the BKM short QR code format generated from the POS with a Cross-Border Mobile Application and its direct transmission to the Domestic Contracted Payment Service Provider (Card Issuer).

Figure 15: Reading the BKM KKF with a Cross-Border Mobile Application and Direct Transmission to the Domestic Contracted Payment Service Provider (Card Issuer)

1. The transaction amount is entered at the terminal and a request to generate a TR QR Code is made from the Merchant Acquirer.

2. The terminal generates a TR QR Code in accordance with the BKM KKF structure and displays it on the screen.

3. The displayed short QR code is read with the Cross-Border Mobile Application.

4. The generated TR QR Code is read via the Cross-Border Mobile Application and transmitted to the Cross-Border Institution.

5. In order to obtain detailed information regarding the read short QR code, the short QR code data is transmitted to the Card Issuer.

6. The Card Issuer calls the KYS GetKkfInfo service to obtain the details of the short QR code.

7. The KYS transmits the information to the Merchant Acquirer that generated the QR code via the GetkkfInfo service in order to obtain the detailed information regarding the short QR code.

8. The mobile application, to which the details of the short QR code have reached, presents the transaction information for customer approval and transmits it to the Cross-Border Institution Host.

9. The transaction information is transmitted to the Card Issuer for the payment to be made.

10. The Card Issuing Institution transmits the transaction to the KYS together with the Card no, expiry date and other data. The card number, expiry date, the customer verification method (CVM type), the electronic commerce indicator (ECI value) and the TR 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.

11. The KYS encrypts the card information (Card no, expiry date) and transaction data under the AES key belonging to the Card Accepting Institution and routes them to the Card Accepting Institution.

12. The terminal creates an authorization message with the incoming data and routes it to the system of the Card Accepting Institution.

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

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

15. The transaction result is notified to the terminal by the Card Accepting Institution. Simultaneously, the transaction result is transmitted by the Card Issuing Institution to the Cross-Border Institution.

16. The terminal produces the slip according to the transaction result. Simultaneously, the transaction result is transmitted to the Cross-Border Mobile Application and the transaction result is displayed via the application.

5.3.1.3 Cancellation / Refund Flow Starting by Generating the BKM Long QR Code Format from the POS

The flow given in Figure 16 describes the flow of having the BKM long QR code cancellation/refund format generated from the POS read with the Cross-Border Mobile Application and transmitted directly to the Domestic Contracted Payment Service Provider (Card Issuing Institution).

Figure 16: Reading the BKM LQF with the Cross-Border Mobile Application for the Cancellation/Refund Transaction and Transmitting It Directly to the Domestic Contracted Payment Service Provider (Card Issuing Institution)

1. On the terminal, the cancellation / refund transaction is initiated by methods such as entering the reference number on the card transaction slip. The terminal generates the cancellation / refund QR code in accordance with the BKM Long QR Code structure. The QR code reference code (QR code id) fields of the sale transaction and the cancellation / refund transaction must be the same.

2. The QR code generated for the cancellation/refund transaction is displayed on the terminal.

3. The displayed cancellation/refund QR code is read via the Cross-Border Mobile Application.

4. The TR QR Code data read via the Cross-Border Mobile Application is transmitted to the Cross-Border Institution host system.

5. The read TR QR Code data and the payment request are transmitted to the Domestic Contracted Payment Service Provider (Card Issuing Institution).

6. The Domestic Contracted Payment Service Provider (Card Issuing Institution) transmits the cancellation/refund request to the KYS together with the TR QR Code data and other transaction data.

7. The KYS transmits the cancellation/refund request to the Card Accepting Institution system together with the TR QR Code data and other transaction information.

8. The authorization request for the cancellation/refund transaction is notified to the terminal.

9. The authorization request is transmitted to the BKM Routing System via the Card Accepting Institution.

10. The BKM Routing System transmits the incoming authorization request to the Card Issuing Institution.

11. The transaction result is transmitted to the terminal by the Card Accepting Institution. Simultaneously, the transaction result is transmitted by the Card Issuing Institution to the Cross-Border Institution.

12. The payment information reaches the terminal and slip production is carried out. At the same time, it notifies the Cross-Border Mobile Application and provides the display of the transaction result.

5.3.1.4 Cancellation / Refund Flow Starting by Generating the BKM Short QR Code Format from the POS

The flow given in Figure 17 describes the flow of having the BKM short QR code cancellation/refund format generated from the POS read with the Cross-Border Mobile Application and transmitted directly to the Domestic Contracted Payment Service Provider (Card Issuing Institution).

Figure 17: Reading the BKM SQF with the Cross-Border Mobile Application for the Cancellation/Refund Transaction and Transmitting It Directly to the Domestic Contracted Payment Service Provider (Card Issuing Institution)

1. On the terminal, the cancellation / refund transaction is initiated by methods such as entering the reference number on the card transaction slip. 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 sale transaction and the cancellation / refund transaction must be the same.

2. The short QR code generated for the cancellation/refund transaction is displayed on the terminal.

3. The displayed short QR code is read via the Cross-Border Mobile Application.

4. The TR QR Code data read via the Cross-Border Mobile Application is transmitted to the Cross-Border Institution host system.

5. In order to obtain detailed information regarding the read short QR code, the short QR code data is transmitted to the Card Issuing Institution.

6. The Card Issuing Institution calls the KYS with the GetKkfInfo service in order to obtain the details regarding the short QR code.

7. KYS, to be able to obtain detailed information about the short QR code, transmits the information to the Card Acquiring Institution that generated the QR code via the GetkkfInfo service.

8. The mobile application to which the details of the short QR code have arrived presents the transaction information for customer approval and simultaneously transmits the data to the Cross-Border Institution Host system.

9. The transaction information is transmitted to the Card Issuing Institution for the payment to be made.

10. The Card Issuing Institution transmits the cancellation/refund request to the KYS together with the transaction, the TR QR code data and other data.

11. KYS transmits the transaction to the Card Acquiring Institution system together with the cancellation/refund request, the TR QR code data and other data.

12. The Card Acquiring Institution transmits the authorization request for the cancellation/refund transaction to the terminal and generates the authorization message specific to the transaction.

13. The authorization request is transmitted to the BKM Routing System via the Card Acquiring Institution.

14. The BKM Routing System transmits the incoming authorization request to the Card Issuing Institution.

15. The transaction result is transmitted to the terminal by the Card Acquiring Institution. Simultaneously, the transaction result is notified to the Cross-Border Institution by the Card Issuing Institution.

16. The payment information reaches the terminal and the slip is generated. At the same time, it is notified to the Cross-Border Mobile Application and the transaction result is displayed.

5.3.2 Scanning of the QR Code Generated from POS with the Cross-Border Mobile Application and Its Transmission via KYS to the Domestic Contracted Payment Service Provider (Card Issuing Institution)

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

The flow presented in Figure 18 describes the case of scanning the BKM LQCF generated from POS with the Cross-Border Mobile Application and transmitting it via KYS to the Domestic Contracted Payment Service Provider (Card Issuing Institution).

Figure 18: Scanning of the BKM LQCF with the Cross-Border Mobile Application and Its Transmission via KYS to the Domestic Contracted Payment Service Provider (Card Issuing Institution)

1. The amount is entered at the terminal and a request is made to the Card Acquiring Institution to generate a QR code. The QR code generated in accordance with the BKM LQCF structure is displayed on the screen.

2. The displayed QR code is read by the Cross-Border Mobile Application.

3. The read QR code data is transmitted to the Cross-Border Institution Host.

4. In order to obtain and parse the details of the read QR code data, the data is transmitted to the KYS via BKM Gateway.

5. The mobile application to which the details of the QR code have arrived presents the transaction information for customer approval and transmits this information to the Cross-Border Institution Host.

6. The Cross-Border Institution transmits the transaction details relating to the payment order to the KYS via BKM Gateway.

7. The KYS transmits the TR QR code data and transaction details to the Card Issuing Institution.

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

9. KYS encrypts the card number, expiry date and transaction data under the AES key belonging to the Card Acquiring Institution and routes them to the Card Acquiring Institution.

10. The authorization request is notified to the terminal.

11. The authorization request is routed to the BKM Routing System via the Card Acquiring Institution.

12. The BKM Routing System transmits the incoming authorization request to the Card Issuing Institution.

13. The transaction result is notified to the terminal by the Card Acquiring Institution. The transaction result is simultaneously transmitted to the Cross-Border Institution by the Card Issuing Institution.

14. The payment information reaches the terminal, a slip is generated and the transaction is completed. At the same time, it is notified to the Cross-Border Mobile Application and the transaction result is displayed on the application.

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

The flow presented in Figure 19 describes the case of scanning the BKM short QR code format generated from POS with the Cross-Border Mobile Application and transmitting it via KYS to the Domestic Contracted Payment Service Provider (Card Issuing Institution).

Figure 19: Scanning of the BKM SQCF with the Cross-Border Mobile Application and Its Transmission via KYS to the Domestic Contracted Payment Service Provider (Card Issuing Institution)

1. The transaction amount is entered at the terminal and a QR code is requested. The generated short QR code is displayed on the terminal screen.

2. The displayed QR code is read by the Cross-Border Mobile Application.

3. The QR code data read via the Cross-Border Mobile Application is transmitted to the Cross-Border Institution Host.

4. In order to obtain the details of the read QR code data, the data is transmitted to the KYS via BKM Gateway.

5. KYS requests the detailed information regarding the QR code it generated from the Card Acquiring Institution via the Getkkfinfo service.

6. The mobile application to which the details of the TR QR code have arrived presents the transaction information for customer approval and transmits this information to the Cross-Border Institution Host.

7. The Cross-Border Institution transmits the transaction details relating to the payment order to the KYS via BKM Gateway.

8. The KYS transmits the TR QR code data and transaction details to the Card Issuing Institution.

9. The Card Issuing Institution transmits the card data, expiry date, TR QR code data and the StartQrTransaction request to the KYS.

10. KYS transmits the incoming StartQrTransaction request to the Card Acquiring Institution.

11. The authorization request is transmitted to the terminal.

12. The authorization request is transmitted to the BKM Routing System via the Card Acquiring Institution.

13. The BKM Routing System transmits the incoming authorization request to the Card Issuing Institution.

14. The transaction result is notified to the terminal by the Card Acquiring Institution. The transaction result is simultaneously notified to the Cross-Border Institution by the Card Issuing Institution.

15. The payment information reaches the terminal, a slip is generated and the transaction is completed. At the same time, the transaction result is notified to the Cross-Border Mobile Application and the display of the transaction result is provided.

5.3.4.3 Cancellation / Refund Flow Starting with Generation of the BKM Long QR Code Format from POS

The flow described in Figure 20 illustrates the scanning of the BKM long QR code cancellation/refund format generated from the POS with the Cross-Border Mobile Application and its transmission to the Domestic Contracted Payment Service Provider (Card Issuing Institution) via KYS.

Figure 20: Scanning of the BKM LQF with the Cross-Border Mobile Application and Transmission to the Domestic Contracted Payment Service Provider (Card Issuing Institution) via KYS for the Cancellation/Refund Transaction

1. At the terminal; the cancellation / refund transaction is initiated by methods such as entering the reference number on the card transaction slip. The terminal generates the cancellation / refund QR code in accordance with the BKM Long QR Code structure. The QR code reference code (QR code id) fields of the cancellation / refund transaction must be the same as those of the sales transaction.

2. The displayed QR code is read by the Cross-Border Mobile Application.

3. The QR code data read via the Cross-Border Mobile Application is transmitted to the Cross-Border Institution Host.

4. In order to obtain and parse the details of the read QR code data, it is transmitted to KYS via BKM Gateway.

5. The mobile application that received the details of the QR code presents the cancellation/refund transaction information for customer approval and transmits this information to the Cross-Border Institution Host.

6. The Cross-Border Institution transmits the transaction details to KYS via BKM Gateway for the transmission of the cancellation/refund transaction.

7. KYS transmits the TR QR code data and transaction details to the Card Issuing Institution.

8. The Card Issuing Institution transmits the StartQrTransaction request for the cancellation/refund transaction with the TR QR code data to KYS.

9. KYS transmits the incoming StartQrTransaction request to the Card Accepting Institution.

10. The authorization request for the cancellation/refund transaction is notified to the terminal.

11. The Cancellation/Refund Authorization request is transmitted to the BKM Routing System via the Card Accepting Institution.

12. The BKM Routing System transmits the incoming authorization request to the Card Issuing Institution.

13. The transaction result is notified to the terminal by the Card Accepting Institution. Simultaneously, the transaction result is notified to the Cross-Border Institution by the Card Issuing Institution.

14. The payment information reaches the terminal and the slip is generated. At the same time, the transaction result is notified to the Cross-Border Mobile Application and is displayed via the application.

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

The flow described in Figure 21 illustrates the scanning of the BKM short QR code cancellation/refund format generated from the POS with the Cross-Border Mobile Application and its transmission to the Domestic Contracted Payment Service Provider (Card Issuing Institution) via KYS.

Figure 21: Scanning of the BKM SQF with the Cross-Border Mobile Application and Transmission to the Domestic Contracted Payment Service Provider (Card Issuing Institution) via KYS for the Cancellation/Refund Transaction

1. At the terminal; the cancellation / refund transaction is initiated by methods such as entering the reference number on the card transaction slip. 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 cancellation / refund transaction must be the same as those of the sales transaction.

2. The displayed QR code is read with the Cross-Border Mobile Application.

3. The QR code data read via the Cross-Border Mobile Application is transmitted to the Cross-Border Institution Host.

4. In order to obtain details of the read QR code data, the data is transmitted to KYS via the BKM Gateway.

5. KYS requests detailed information regarding the TR QR Code it generated from the Card Accepting Institution via the Getkkfinfo service.

6. The mobile application, to which the details of the TR QR Code have reached, presents the transaction information to the customer's approval and this information is transmitted to the Cross-Border Institution Host.

7. The Cross-Border Institution transmits the transaction details regarding the cancellation/refund order to KYS via the BKM Gateway.

8. KYS transmits the TR QR Code data and transaction details to the Card Issuing Institution.

9. The Card Issuing Institution transmits the StartQrTransaction request with the cancellation/refund request and QR code data to KYS.

10. KYS transmits the incoming StartQrTransaction request to the Card Accepting Institution.

11. The authorization request for the cancellation/refund transaction is notified to the terminal.

12. The authorization request for the cancellation/refund transaction is routed to the BKM Routing System via the Card Accepting Institution.

13. The BKM Routing System transmits the incoming authorization request to the Card Issuing Institution.

14. The transaction result is notified to the terminal by the Card Accepting Institution. The transaction result is simultaneously notified to the Cross-Border Institution by the Card Issuing Institution.

15. The payment information reaches the terminal and slip generation is performed. At the same time, it is notified to the Cross-Border Mobile Application and the transaction result is displayed.

5.3.3 Connection of Card Schemes to KYS

5.3.3.1 Payment Flow Initiated by Generating BKM Long QR Code Format from POS

The flow given in Figure 22 describes the situation where the BKM long QR code format generated from the POS is read with the Cross-Border Mobile Application and transmitted directly to the Card Scheme.

Figure 22: Reading of BKM UKF with Cross-Border Mobile Application and Direct Transmission to Card Scheme

1. The transaction amount is entered at the terminal and a QR code request is made from the Card Accepting Institution.

2. The generated QR code is displayed on the terminal screen.

3. The displayed QR code is read with the Cross-Border Mobile Application.

4. The QR code data read via the Cross-Border Mobile Application is transmitted to the Cross-Border Institution host.

5. The read QR code data is transmitted to the Card Scheme for parsing.

6. The Card Scheme transmits the QR code data to KYS for parsing the QR code and sharing transaction details. KYS provides the necessary data and transmits the response message.

7. The mobile application, to which the details of the TR QR Code have reached, presents the transaction information to the customer's approval and transmits this information to the Cross-Border Institution Host.

8. The card information selected by the customer and the payment request are transmitted to the Card Scheme.

9. The Card Scheme transmits the selected card data, expiry date and other data to KYS via the StartQrTransaction service.

10. KYS transmits the shared card data, expiry date and other data to the Card Accepting Institution.

11. The authorization request is notified to the terminal.

12. The authorization request is routed to the BKM Routing System via the Card Accepting Institution.

13. The BKM Routing System transmits the incoming authorization request to the Card Scheme system.

14. The card scheme transmits the cancellation/refund transaction result to the Cross-Border Institution.

15. The transaction result is notified to the terminal by the Card Accepting Institution. The transaction result is simultaneously transmitted to the Cross-Border Mobile Application by the Card Issuing Institution.

16. The payment information reaches the terminal and slip generation is performed. At the same time, the Cross-Border Institution provides the display of the transaction result to its customer via the Mobile Application.

5.3.3.2 Payment Flow Initiated by Generating BKM Short QR Code Format from POS

The flow given in Figure 23 describes the situation where the BKM short QR code format generated from the POS is read with the Cross-Border Mobile Application and transmitted directly to the Card Scheme.

Figure 23: Reading of BKM KKF with Cross-Border Mobile Application and Direct Transmission to Card Scheme

1. The transaction amount is entered at the terminal and a QR code generation request is made from the Card Accepting Institution.

2. The generated short QR code is displayed on the terminal screen.

3. The displayed short QR code is read by the Cross-Border Mobile Application.

4. The QR code data read via the Cross-Border Mobile Application is transmitted to the Cross-Border Institution host.

5. The read QR code data is transmitted to the Card Scheme in order to obtain details.

6. The Card Scheme transmits the short QR code data to KYS for sharing the details of the short QR code.

7. In order to obtain the details of the Short QR Code, KYS transmits the TR QR Code data to the Card Accepting Institution and receives the transaction details.

8. The mobile application to which the details of the short QR code reach presents the transaction information for customer approval, and this information is transmitted to the Cross-Border Institution Host.

9. The card information selected by the customer and the payment request are transmitted to the Card Scheme.

10. The Card Scheme transmits the selected card data, expiry date and other data to the KYS via the StartQrTransaction service.

11. The KYS transmits the shared card data, expiry date and other data to the Card Acceptor Institution.

12. The authorization request is notified to the terminal.

13. The authorization request is transmitted to the BKM Routing System via the Card Acceptor Institution.

14. The BKM Routing System transmits the incoming authorization request to the Card Scheme system.

15. The Card Scheme transmits the transaction result to the Cardholder's Cross-Border Institution.

16. The transaction result is notified to the terminal by the Card Acceptor Institution. The transaction result is simultaneously notified to the Cross-Border Mobile Application.

17. The payment information reaches the terminal and slip generation is performed. At the same time, it enables the display of the transaction result to its customer via the Cross-Border Mobile Application.

5.3.3.3 Cancellation / Refund Flow Starting by Generating BKM Long QR Code Format from POS

The flow given in Figure 24 describes the flow of reading the BKM long QR code cancellation/refund format generated from the POS with the Cross-Border Mobile Application and transmitting it directly to the Card Scheme.

Figure 24: Reading the BKM UKF with the Cross-Border Mobile Application for Cancellation/Refund Transaction and Transmitting it Directly to the Card Scheme

1. At the terminal, the cancellation / refund transaction is initiated by methods such as entering the reference number on the card transaction slip. The terminal generates the cancellation / refund QR code in accordance with the BKM Long QR Code structure. The QR code reference code (QR code id) fields of the sale transaction and the cancellation / refund transaction must be the same.

2. The TR QR code generated for the cancellation/refund transaction is displayed on the terminal screen.

3. The displayed cancellation/refund TR QR code is read by the Cross-Border Institution Mobile application.

4. The QR code data read via the Cross-Border Mobile Application is transmitted to the Cross-Border Institution host.

5. The read TR QR Code data is transmitted to the Card Scheme for parsing into data objects.

6. The Card Scheme transmits the QR code data to the KYS for parsing the QR code into data objects and sharing the transaction details, and the KYS transmits the details of the data objects in the response message.

7. The mobile application to which the details of the QR code reach presents the information of the cancellation/refund transaction for customer approval and transmits this information to the Cross-Border Institution Host.

8. The generated cancellation/refund request, TR QR Code data and other data are transmitted to the Card Scheme.

9. The Card Scheme transmits the cancellation/refund request along with the TR QR Code data and other data to the KYS via the StartQrTransaction service.

10. The KYS transmits the cancellation/refund request, TR QR Code data and other data to the Card Acceptor Institution.

11. The authorization request for the cancellation/refund transaction is notified to the terminal.

12. The authorization request for the cancellation/refund transaction is transmitted to the BKM Routing System via the Card Acceptor Institution.

13. The BKM Routing System transmits the incoming authorization request to the Card Scheme system.

14. The Card Scheme transmits the cancellation/refund transaction result to the Cross-Border Institution.

15. The transaction result is notified to the terminal by the Card Acceptor Institution. The transaction result is simultaneously transmitted to the Cross-Border Mobile Application by the Card Issuer Institution.

16. The payment information reaches the terminal and slip generation is performed. At the same time, the transaction result is notified to the Cross-Border Mobile Application and displayed via the application.

5.3.3.4 Cancellation / Refund Flow Starting by Generating BKM Short QR Code Format from POS

The flow given in Figure 25 describes the flow of reading the BKM short QR code cancellation/refund format generated from the POS with the Cross-Border Mobile Application and transmitting it directly to the Card Scheme.

Figure 25: Reading the KKF with the Cross-Border Mobile Application for Cancellation/Refund Transaction and Transmitting it Directly to the Card Scheme

1. At the terminal, the cancellation / refund transaction is initiated by methods such as entering the reference number on the card transaction slip. 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 sale transaction and the cancellation / refund transaction must be the same.

2. The short QR code generated for the cancellation/refund transaction is displayed on the terminal.

3. The displayed short QR code is read by the Cross-Border Mobile Application.

4. The QR code data read via the Cross-Border Mobile Application is transmitted to the Cross-Border Institution host.

5. The read QR code data is transmitted to the Card Scheme to obtain its details.

6. The Card Scheme transmits the short QR code data to the KYS for sharing the details of the short QR code.

7. The KYS transmits the TR QR Code data to the Card Acceptor Institution to obtain the details of the Short QR Code and receives the transaction details.

8. The mobile application to which the details of the short QR code reach presents the cancellation/refund transaction information for customer approval and it is transmitted to the Cross-Border Institution Host.

9. The cancellation/refund request, TR QR Code data and other data are transmitted to the Card Scheme.

10. The Card Scheme transmits the cancellation/refund request, TR QR Code data and other data to the KYS via the StartQrTransaction service.

11. The KYS system transmits the cancellation/refund request, TR QR Code data and other data to the Card Acceptor Institution.

12. The authorization request for the cancellation/refund transaction is notified to the terminal.

13. The authorization request for the cancellation/refund transaction is transmitted to the BKM Routing System via the Card Acceptor Institution.

14. The BKM Routing System transmits the incoming authorization request to the Card Scheme system.

15. The Card Scheme transmits the transaction result to the Cardholder's Cross-Border Institution.

16. The transaction result is notified to the terminal by the Card Acceptor Institution. The transaction result is simultaneously transmitted to the Cross-Border Mobile Application by the Card Issuer Institution.

17. The payment information reaches the terminal and slip generation is performed. At the same time, the transaction result is notified to the Cross-Border Mobile Application and displayed via the application.

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, 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 26) 4 .

Figure 26: 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

[3] An object that is not 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.

value at the root level or within the data template in which it is 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 of 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 as “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 data by first reading this object in the QR code.

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

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 provided by the merchant in EMV format
QR Code Type	01		N	02	Z	010211	Used to distinguish static and dynamic QR codes. Data value: “11”: Static QR code where the same QR code is used for multiple transactions.

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


Merchant Account Information	26		ÖAN variable up to 99	Z	2668	ID and length information for this field
		00- Universal 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 so that when the Card Acceptor Organization is taken into the system, it can be checked whether the QR code was actually generated by this system. The Card Acceptor Organization 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 Organization'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 by BKM.
Merchant Account
Information
28 Reserved for future use by BKM.
Merchant Account
Information
29 Reserved for future use by 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
Workplace's Workplace Registration in the System unique reference number.
Values shorter than 10 digits on the left side with the '0' character will be completed.
Location 50 N 16-34 range variable
I Latitude
39.93942
3 and longitude
32.85179
1 for location value:
5016399
3942332
851791
For payment transaction with QR code that can be used and according to Decimal Degrees (DD) format created location information.
The location value consists of two parts of equal length, the first being latitude and the second being longitude.
Latitude: EE.eeeeee and Longitude:
BB.bbbbbb for 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 depending on the precision degree to be used, it can be at least 6 and at most 15. QR Code Identity Information Template 51 ÖAN up to 99 variable Z 5191 QR code identity template generated by the QR code generator. The ID and length information belonging to this field is calculated together with the sum of the subfields and written. 00-Version Number N 02 Z In this guide (version 1.0) for data organiza tion :
for:
000210
TR QR Code compliance version number. For version number "S.s", the data value is created as "Ss" without using a punctuation mark.
02-
QR Code
N 04 Z 0204000
1
The code required to generate a TR QR Code.

Producer Code					Payment Service Providers and payment system operators deemed appropriate by the CBRT will be able to obtain a QR code producer code by applying to BKM for registration in order to generate 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 12	Z	0308234 51017	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	The type of device on which the QR Code is generated. Defined values: "01": Static QR code "02": POS/mPOS/ÖKC/Kiosk etc. payment acceptance software and hardware "03": ATM "04": Merchant application "05": Web "06": Payment service provider's merchant application
05- Terminal Device Serial Number	Variable up to 23	İ	0523123 4567890 1234567 890ABC	The distinguishing value belonging to the QR code generating device or terminal (for example, the terminal number and/or the serial number of the terminal).
06- Creation Time	N	12	Z	29 May 2020 at	It is the time information when the QR Code was generated. YYAAGGSSDDss YY: Year, AA: Month, GG: Day,

						For 14.01:59: 0612200 5291401 59	SS: Hour (24 hours), DD: minute, ss: Second
		07- Expiration Time	N	12	K	For 29 May 2020 at 15.01:59: 0712200 5291501 59	It is the last time information when the QR Code is valid. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24 hours), DD: minute, ss: Second. It is optional for static QR codes and mandatory for dynamic QR codes.
Merchant Category Code	52		N	04	Z	5204123 4	It is the Merchant Category Code (MCC) of the transaction, compliant with ISO 18245:2003. 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 currency code of the transaction, compliant 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 specifies 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 requests 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		It specifies the fixed tip or other amount. If the value of the field with code “55” is “02”, this field must be filled. The last two digits indicate the decimal part (kuruş, cent, etc.). 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 of 3.25%, 00325	It specifies the percentage tip or other amount. If the value of the field with code “55” is “03”, this field must be filled. The last two digits give the decimal part. The percentage value given in this field of the amount specified in the field with code “54” constitutes the other amount. 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 Turkey, “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	It contains additional data required 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		Variable up to ÖAN 15	İ	0212902 1235079 00	Customer's mobile phone number.
03 - Store Label		Variable up to ÖAN 25	İ	0306AV MSTR	A label information that can be used to distinguish a particular store from others.

		04 - Customer Loyalty Number	ÖAN	Variable up to 25	İ	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 It is the code of the (usually local) language used to resolve the name of the merchant and the city information where it is located, encoded in the "01" and "02" coded subfields of this template. It is a mandatory field in case 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.
		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	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 ID, length 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 is not included, and 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 27.

Figure 27: Example BKM Long QR Code Image

6.1.2 Hash Value

The hash value within the QR code is used by the Merchant Acquirer to verify that the QR code is one it generated before routing the authorization transaction to the BKM Routing System.

The recommended method is as follows:

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

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

3. Before initiating the online authorization transaction, the Merchant Acquirer system checks the merchant and terminal that generated the QR code using the hash value in the QR code sent by the terminal. If it is incorrect, the transaction is terminated. If the 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	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 Producer 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 per Card Acceptor Organization, 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 Organization. The Card Acceptor Organization can use this field to verify that the QR code data is the 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, including ID, length 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 is not included, the calculated value is written.

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

9908001234567890120123456789012345678901234567891280BE

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

Figure 28: Example 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 merchant and the merchant's 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	Example 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 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 Acceptor Organization according to its own standards.

When an example plain text value in the ATM TR QR Code structure is "98080012345678901201234567890123456789", the QR code image generated from this plain text value is shown in Figure 29.

Figure 29: 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

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

1 Introduction

2 Purpose, Scope and Basis

3 Definitions and Abbreviations

4 General Principles

5 QR Code Usage Models for Card Payments

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

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

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

5.1.3 Cancellation / Refund Flow Starting by Generating BKM Long QR Code Format from POS

5.1.4 Cancellation / Refund Flow Starting by Generating BKM Short QR Code Format from POS

5.1.5 ATM TR QR Code Cash Withdrawal Transaction Flow

5.1.6 ATM TR QR Code Cash Deposit Transaction Flow

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 BKM Long QR Code Format from POS

5.2.2 Payment Flow Starting with Generation of BKM Long QR Code Format from POS and Performing Customer Authentication with Instant Notification Approval

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

5.2.4 Payment Flow Starting with Generation of BKM Short QR Code Format from POS and Customer Verification with Instant Notification Approval

5.2.5 Cancellation / Refund Flow Starting with Generation of BKM Long QR Code Format from POS

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

5.2.7 Notification of the Authorization Result to the Mobile Application

5.3 Reading the TR QR Code Generated from the POS with a Cross-Border Mobile Application

5.3.1 Reading the TR QR Code Generated from the POS with a Cross-Border Mobile Application and Direct Transmission to the Domestic Contracted Payment Service Provider (Card Issuer)

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

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

5.3.1.3 Cancellation / Refund Flow Starting by Generating the BKM Long QR Code Format from the POS

5.3.1.4 Cancellation / Refund Flow Starting by Generating the BKM Short QR Code Format from the POS

5.3.2 Scanning of the QR Code Generated from POS with the Cross-Border Mobile Application and Its Transmission via KYS to the Domestic Contracted Payment Service Provider (Card Issuing Institution)

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

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

5.3.4.3 Cancellation / Refund Flow Starting with Generation of the BKM Long QR Code Format from POS

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

5.3.3 Connection of Card Schemes to KYS

5.3.3.1 Payment Flow Initiated by Generating BKM Long QR Code Format from POS

5.3.3.2 Payment Flow Initiated by Generating BKM Short QR Code Format from POS

5.3.3.3 Cancellation / Refund Flow Starting by Generating BKM Long QR Code Format from POS

5.3.3.4 Cancellation / Refund Flow Starting by Generating BKM Short QR Code Format from POS

6 QR Code Specifications for BKM Card Payments

6.1 QR Code Data Organization and Naming Rules

6.1.1 BKM UKF Structure Provided by the Merchant

6.1.2 Hash Value

6.1.3 BKM Short QR Code Structure

6.1.4 ATM TR QR Code Structure

7 References

Lineage: No known changes

Similar documents from other regulators