Rule · CBRT · 31 Dec 2020
Payment service providers offering QR code card payments, QR code generators, and all parties to TR QR Code transactions must follow this Guide's specifications for EFTPOS, Shared EFTPOS, POS, ATM, static QR codes, virtual POS and provider mobile-application QR codes; generators are responsible for complete, accurate data. PIN entry is permitted only from PCI-compliant EFTPOS, ÖKC, ATM or PCI SPOC approved terminals, and is prohibited with static QR codes or non-PCI SPOC compliant mobile dynamic QR codes.
CENTRAL BANK OF THE REPUBLIC OF TÜRKİYE
BKM (Card Payments)
TR QR Code Technical Principles and
Rules Guide
December 2020
Version 1.0
Confidential
| Change Date | Change Description | Version |
|---|---|---|
| December 2020 | First Version | 1.0 |
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).
The purpose of this Guide is to define the specifications for the arrangement of the QR code structure to be used in card payments in compliance with the Regulation and the Technical Document. Transactions where payment is made via QR code through a debit card, credit card, or a prepaid card within the scope of the Law No. 6493 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions (Law) are considered card payments in terms of this Guide.
The flows described in this Guide shall be valid for the following terminal and QR code types.
EFTPOS
Shared EFTPOS
POS
ATM
QR codes generated for card payments in mobile applications of payment service providers
Static QR codes
Virtual POS
This document has been prepared based on the first paragraph of Article 6 of the Regulation.
In this Guide;
Recipient: The real or legal person to whom the funds subject to the payment transaction are intended to reach,
BKM SQF: The Short QR Code Format created for card payments in accordance with this Guide,
BKM LQF: The EMVCo-compliant Long QR Code Format created for card payments in accordance with this Guide,
BKM Switching System (Switch): The switching system that mediates the routing of clearing-eligible transactions executed through ATM and POS terminals to the relevant Card Issuing Institution for authorization purposes, ensures the transmission of the Card Issuing Institution's positive-negative response to the Card Accepting Institution, and is operated by BKM,
EFTPOS: PCI1 compliant single POS terminal,
EMVCo2: The union consisting of American Express, Discover, JCB, Mastercard, UnionPay and Visa,
Sender: The real or legal person who gives a payment order from their own payment account or without having a payment account,
[1] These are data security standards accepted at the international level in the card payments industry.
[2] EMV® QR Code Specification for Payment Systems Merchant-Presented Mode, Version 1.0, July 2017
Law: The Law No. 6493 dated 20/6/2013 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions,
QR Code Routing System (QRS): The infrastructure that enables the transfer of QR codes and the information contained therein between payment service providers and is established and operated by BKM in accordance with the Regulation,
Card Issuing Institution: Institutions that establish a debit card or credit card system and are authorized to issue cards according to this system, as well as institutions authorized to issue cards that qualify as 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 qualify as 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,
Shared EFTPOS: PCI compliant shared POS terminal,
Payment service: The services specified in Article 12 of the Law,
Payment service provider: The institutions specified in Article 13 of the Law,
Payment transaction: The activity of depositing, transferring or withdrawing funds carried out upon the instruction of the sender or recipient,
POS: The payment recording device integrated with or connected to a POS application,
Guide: The BKM (Card Payments) TR QR Code Technical Principles and Rules Guide,
TCMB: Türkiye Cumhuriyet Merkez Bankası Anonim Şirketi,
TR QR Code: The QR code created in accordance with the procedures and principles set out in the TR QR Code Principles and Rules document and which can be used in payments within the scope of the Law,
refers to.
1. Within the scope of the Regulation, all payment services to be carried out using QR codes for card payments are performed with QR codes created in accordance with the rules set out in this Guide. All kinds of TR QR Code transactions to be carried out with card payments (not subject to clearing, subject to clearing, and using or not using QRS) shall use the specifications in this Guide.
2. Payment service providers who wish to offer their users the opportunity to pay 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 whom they provide services for card payments.
4. When a QR code generator creates any QR code for card payments or adds any other data to an already created QR code, it is responsible for ensuring that all data contained therein is complete and accurate and that the QR codes fully comply with the requirements in the QR code formats in this Guide.
5. In payments to be made using QR codes for card payments, all parties, especially payment service providers, continue to be obliged to fulfill all other obligations arising from the Law and other relevant legislation and not otherwise specified in this Guide.
6. In QR code transactions, PIN entry can only be made from the following types of PCI-compliant terminals.
EFTPOS
ÖKC
ATM
PCI SPOC approved terminals
In transactions made with static QR codes or dynamic QR codes generated on mobile devices that are not PCI SPOC compliant, PIN entry cannot be made.
In card payment transactions, the workflows in cases where the KYS is used are shared below.
Figure 1 shows the card payment workflow regarding the use of BKM UKF presented by the merchant.
Figure 1: Payment Flow Starting by Generating BKM UKF from POS
Flow steps where 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, expiration 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 to the KYS by the Issuer. These data are encrypted with the AES key between the Issuer and the KYS.
6. The KYS encrypts the incoming card information and the data within the QR code value under the AES key belonging to the Acquirer and routes it to the Acquirer.
7. The terminal creates an authorization message with the incoming data and routes the transaction to the Acquirer's system. If the 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.
8. The Acquirer, upon the request from the terminal, transmits the transaction to the BKM Switching System.
9. The BKM Switching System routes the transaction to the Issuer.
10. The Issuer, in addition to providing an authorization response, also transmits the approval or rejection information as a notification to the mobile application that initiated the QR code transaction.
11. The terminal completes the transaction in accordance with the authorization response received via BKM.
Figure 2 shows the card payment workflow regarding the use of BKM KKF presented by the merchant.
Figure 2: Payment Flow Starting by Generating BKM KKF from POS
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 the mobile application.
4. The short QR code value read by the mobile application is transmitted to the Card Issuer's system.
5. The Card Issuer transmits the KKF value to the KYS.
6. The KYS routes the incoming QR code content to the Card Acquirer.
7. The Card Acquirer returns the data related to the transaction for the KKF QR code to the KYS.
8. The KYS routes the QR code information received from the Card Acquirer to the Card Issuer.
9. The Card Issuer displays the transaction information in its mobile application. The cardholder selects the card to be used for the transaction.
10. The card selected by the cardholder, the expiry date, the customer verification method (CVM type), the Electronic Commerce Indicator (ECI), and the QR code value read from the terminal are transmitted by the Card Issuing Institution to the KYS. These data are encrypted with the AES key between the Card Issuing Institution and the KYS.
11. The KYS forwards the incoming data within the card and QR code value to the Card Accepting Institution, encrypting them under the AES key belonging to the Card Accepting Institution.
12. The terminal creates an authorization message with the incoming data and forwards it to the Card Accepting Institution 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 forwards the transaction to the BKM Routing System.
14. The BKM Routing System forwards the transaction to the Card Issuing Institution.
15. The Card Issuing Institution transmits the approval or decline information as a notification to the mobile application that initiated the QR code transaction.
16. The transaction is completed at the terminal in accordance with the authorization response received from BKM.
Figure 3 shows the card-based cancellation / refund workflow regarding the use of BKM UKF offered by the merchant.
Figure 3: Cancellation / Refund Flow Starting with Generation of BKM UKF from POS
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 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 of the sales transaction within the transaction data obtained from the QR code are displayed in the application. The cardholder approves the cancellation / refund transaction. (There is no need for the cardholder to select the card used for the transaction from the mobile application.)
4. The mobile application transmits the cardholder's cancellation / refund request to the Card Issuing Institution system.
5. The cardholder's cancellation / refund request is transmitted by the Card Issuing Institution to the KYS together with the QR code value read from the terminal.
6. The KYS forwards the incoming information and the data within the QR code value to the Card Accepting Institution.
7. The Card Accepting Institution generates a cancellation/refund message and forwards the transaction to the BKM Routing System.
8. The BKM Routing System forwards the transaction to the Card Issuing Institution.
Figure 4 shows the card-based cancellation / refund workflow regarding the use of BKM KKF offered by the merchant.
Figure 4: Cancellation / Refund Flow Starting with Generation of BKM KKF from POS
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 system.
2. The terminal generates the cancellation / refund QR code in accordance with the BKM Short QR Code structure. The QR code reference code (QR code id) fields of the sales transaction and the cancellation / refund transaction must be the same.
3. The cardholder reads - the QR code generated at the terminal via the mobile application.
4. The mobile application transmits the short QR code value it read to the Card Issuing Institution system.
5. The Card Issuing Institution transmits the short QR code value to the KYS.
6. The KYS forwards the incoming QR code to the Card Accepting Institution.
7. The Card Accepting Institution returns the information regarding the transaction for the KKF QR code to the KYS.
8. The KYS forwards the QR code information received from the Card Accepting Institution to the Card Issuing Institution.
9. The transaction amount and merchant name of the sales transaction within the transaction data obtained from the QR code are displayed in the application. The cardholder approves the cancellation / refund transaction. (There is no need for the cardholder 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 forwards the incoming information and the data within the QR code value to the Card Accepting Institution.
12. The Card Accepting Institution generates a standard cancellation/refund message and forwards the transaction to the BKM Routing System.
Figure 5 shows the general workflow regarding ATM QR code usage.
Figure 2: ATM QR Code Transaction Flow
1. The cardholder reads the QR code at the ATM via the mobile application. Selects the card and amount.
2. The terminal continues to wait in the main screen (IDLE) state.
3. The ATM QR code value read by the mobile application is transmitted to the Card Issuing Institution system.
4. The Card Issuing 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 Issuing Institution and the KYS.
5. The KYS forwards the incoming data within the card and QR code value to the generating Card Accepting Institution, encrypting them under the AES key belonging to the Card Accepting Institution.
6. The Card Accepting Institution checks the location information of the cardholder and the ATM.
7. The terminal transmits the commission inquiry message to the Card Accepting Institution system.
8. The Card Accepting Institution transmits the commission inquiry message to the BKM Routing System.
9. The BKM Routing System transmits the commission inquiry message to the Card Issuing Institution. Transmits the response returned from the Card Issuing Institution to the Card Accepting Institution.
10. Commission information is displayed on the terminal. The cardholder confirms 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 transmits the approval or decline 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 generates the card transaction receipt and the transaction ends.
The data within a QR code are organized in a tree structure as objects, and this structure is divided into two main classes: simple data objects and data template objects, located under the root3 part of this structure. While simple data objects can store a single piece of information such as date, amount, or reference number, data template objects can contain one or more simple data objects and other data template objects (Figure)4.
Figure 6: Figure: QR Code Data Structure Organization
Each object within a QR code has a data structure consisting of three parts:
[3] An object that is not located under any data template.
[4] The relevant information has been taken from the "TR QR Code Principles and Rules" document, which is an annex to the Regulation.
code "62" refer to different data.
Length: A two-digit number indicating the length in characters of the data value belonging to the object, having a value between "01" and "99".
Data value: The value of the data with a length of at least one character and at most 99 characters.
Example:
An object with field code "02", length "08", and data value "20200530" is represented as "020820200530".
The data values of the objects contained within a QR code support the following data types:
Character String (K): A data type containing characters created in accordance with the UTF-8 5 character encoding.
Special Alphanumeric (ÖAN): A data type containing digits between '0'-'9', letters of the alphabet, and punctuation marks. A subset of the Character String data type.
Numeric (N): A data type containing digits between '0'-'9'. A subset of the Special Alphanumeric data type.
For the presence status of objects within the QR code data organization, the notation specified below is used:
Mandatory (Z): The relevant data object must always be present in the QR code.
Optional (İ): The presence of the relevant data object in the QR code is optional.
Conditional (K): The presence of the relevant data object in the QR code depends on certain conditions. For example, if only one of two data objects is required to be present in the QR code, the presence status of these objects is specified as conditional. The necessary condition information is included in the descriptions of the relevant objects.
The QR Code Format Indicator, which is the first data object of the QR code, specifies the type of the QR code in accordance with 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 are provided for the BKM UKF, summary security (hash) value, BKM Short QR Code, and ATM QR Code usage models offered by the merchant for card payments.
[5] UTF-8 (8-bit Unicode Transformation Format) is the name of the general standard that provides the representation of all universally available characters using a variable number of bytes from 1 to 4.
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 Offered 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 offered by the merchant in EMV format | |
| QR Code Type | 01 | N | 02 | Z | 010211 | Used for Static and Dynamic QR Code distinction. Data value: “11”: Static QR Code where the same QR code is used for multiple transactions. “12”: Dynamic QR Code where a different QR code is used for each transaction. | |
| Merchant Account Information | 26 | ÖAN | Variable up to 99 | Z | 2668 | ID and length information belonging to this field | |
| 00- Globally Unique Identifier | ÖAN | 10 | Z | 0010TR.COM.BKM | Reverse domain name of BKM | ||
| 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 | 08200123 45678901 23456789 | Summary Security (Hash) Value The Summary Security value is designed so that when the Card Acceptor Institution is onboarded to the system, it can be checked whether the QR code was actually generated by this system. The Card Acceptor Institution may fill this field with a value of its own determined length when generating the QR code, or may assign random values. | ||
| 09 - Schemes | ÖAN | Variable up to 10 | Z | 0910TDV MAUJ000 | Supported schemes (Troy, Discover, Amex, Visa, Mastercard, Unionpay, JCB) (There is no specific ordering for filling the field. For supported |
| schemes, it is sufficient to indicate with the scheme code, and for unsupported ones with the value “0”. In the Card Issuer Institution's mobile application, cards belonging to the schemes indicated as supported in the QR code must be listed.) | ||||||
|---|---|---|---|---|---|---|
| 10 - Brand ÖAN | 01 | Z | 1001N | Brand POS indicator (B/M/W/A/None) A:Axess B:Bonus F:ParaPuan M:Maximum P:Paraf W:World Z:Bankkart Combo N:No Brand Support | ||
| 11 – Number of installments | N | 02 | İ | 110203 | Number of installments | |
| 13- RRN | N | 16 | K | 13160123 45678901 2345 Or 00001234 567891 | Used in refund transactions, the RRN value of the sale transaction. Values shorter than 16 digits will be completed with the '0' character on the left side. Example 0000123456789123 | |
| Merchant Account Information | 27 | Reserved for future use for BKM. | ||||
| Merchant Account Information | 28 | Reserved for future use for BKM. | ||||
| Merchant Account Information | 29 | Reserved for future use for BKM. | ||||
| Merchant Account Information | 30-31 | Used for FAST. | ||||
| Merchant Account Information | 32 | Used for mobile payments. | ||||
| Merchant Code 49 | N | 10 | Z | 49100023 415672 | It is the unique reference number of the merchant in the Merchant Registry System. Values shorter than 10 digits will be completed with the '0' character on the left side. |
| Location | 50 | N | Variable between 16-34 | İ | For latitude 39.939423 and longitude 32.851791, the location value: 50163993 94233285 1791 | It is the location information that can be used for QR code payment transactions and is created according to the Decimal Degrees (DD) format. The location value consists of two parts of equal length, the first being latitude and the second being longitude. For Latitude: EE.eeeeee and Longitude: BB.bbbbbb, the location value is specified as EEeeeeeeBBbbbbbb and no separator such as '.', ',', etc. is used in it. The number of 'e' and 'b' digits is equal and can be at least 6 and at most 15 depending on the degree of precision to be used. | |
|---|---|---|---|---|---|---|---|
| QR Code Identity Information Template | 51 | ÖAN | Variable up to 99 | Z | 5191 | It is the QR code identity template generated by the QR code generator. The ID and length information for this field are calculated and written together with the sum of the subfields. | |
| 00-Version Number | N | 02 | Z | For the data organization in this guide (version 1.0): 000210 | It is the TR QR code version number complied with. For version number “S.s”, the data value is formed as “Ss” without using a punctuation mark. | ||
| 02-QR Code Generator Code | N | 04 | Z | 02040001 | The code required to generate a TR QR code. Payment Service Providers and payment system operators deemed appropriate by the TCMB will be able to obtain a QR code generator code by applying to BKM for registration in order to generate 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 | ÖAN | Variable up to 12 | Z | 03082345 1017 | It is the unique reference number generated for the QR code. The transaction reference number within the QR code cannot be generated sequentially; it must be a random value. It is provided by the merchant application or the QR code generator and is used in processes such as end-to-end verification, transaction recording, or receipt generation. It may be specified by the merchant within the QR code or may be 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 was 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 | ÖAN | Variable up to 23 | İ | 05231234 56789012 34567890 ABC | The distinguishing value belonging to the device or terminal that generated the QR code (for example, the terminal number and/or the serial number of the terminal). | ||
| 06-Creation Time | N | 12 | Z | For 29 May 2020 at 14.01:59: 06122005 29140159 | It is the time information when the QR code was generated. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24-hour), DD: minute, ss: Second | ||
| 07-Expiration Time | N | 12 | K | For 29 May 2020 at 15.01:59: 07122005 29150159 | It is the last time information when the QR code is valid. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24-hour), DD: minute, ss: Second It is optional for static QR codes and mandatory for dynamic QR codes. | ||
| Merchant Category Code | 52 | N | 04 | Z | 52041234 | 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 ISO 4217-compliant currency code of the transaction: TRY: “949”, USD: “840”, EUR: “978”, etc. | |
| Amount | 54 | N | 12 | K | 54120000 00000123 | If the payment amount is requested to be entered into the application by the customer, this field is not included. Otherwise, this field is present. 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 | Variable up to 25 | Z | 5906ABCD EF | Workplace name. | |
| Workplace City | 60 | ÖAN | Variable up to 15 | Z | 6008ISTAN BUL | The city name of the workplace. | |
| Postal Code | 61 | ÖAN | Variable up to 10 | İ | 61053474 6 | Workplace postal code | |
| Additional Data Fields Template | 62 | K | variable up to 99 | İ | 6250 | Contains the additional data needed by the merchant for card payments. Since the total length of the field belonging to the template is at most 99 characters, |
| the subfields whose presence status is "optional" must be determined in a way that does not exceed this limit, and the QR code must be generated accordingly. | |||||||
|---|---|---|---|---|---|---|---|
| 01 - Invoice Number | ÖAN | variable up to 25 | İ | 0111TLK0 1230405 | Contains the invoice number. | ||
| 02 - Customer's Phone Number | ÖAN | variable up to 15 | İ | 02129021 23507900 | The customer's mobile phone number. | ||
| 03 - Store Label | ÖAN | variable up to 25 | İ | 0306AVM STR | A label information that can be used to distinguish a particular store from others. | ||
| 04 - Customer Loyalty Number | ÖAN | variable up to 25 | İ | 04102315 634123 | The customer's loyalty card number. | ||
| 06 - Customer Number | ÖAN | variable up to 25 | İ | 06100518 894111 | A label value used specifically for the customer. For example, it may be the customer's membership number for a membership. | ||
| 08- Payment purpose | ÖAN | 2 | İ | It will not be used for card payments. | |||
| 09 - Additional Consumer Data | ÖAN | variable up to 3 | İ | It will not be used for card payments. | |||
| Merchant Language Information Template | 64 | K | variable up to 99 | İ | 6430 | The merchant's information is specified in an alternative language. | |
| 00-Preferred Language | ÖAN | 02 | Z | 0002TR | Two-character language code compliant with ISO 639-1. "TR": Turkish "EN": English This is the code of the (usually local) language used to resolve the merchant's name and city information encoded in the "01" and "02" coded subfields of this template. It is a mandatory field if the template is used. | ||
| 01-Name of Workplace with Alternative Language | K | variable up to 50 | Z | 0108AĞAÇ A.Ş. | The name of the workplace coded with the language specified in the “00” field. | ||
| 02-City Name of Workplace with Alternative Language | K | variable up to 25 | İ | 0208İSTANBUL | The name of the city where the workplace is located, coded in the language specified in the “01” field. | ||
| 03-99 Fields reserved by EMVCo | K | variable up to 99 | - | Reserved by EMVCo for future use. | |||
| EMVCo. Reserved fields | 65-79 | K | variable up to 99 | İ | Reserved by EMVCo for future use. | ||
| Free Templates | 80-99 | N | variable up to 99 | İ | These are fields reserved for future use within the scope of TR QR Code. Application must be made to the TCMB for use. | ||
| CRC | 63 | ÖAN | 04 | Z | 6304C2B6 | It is the integrity check value calculated over the entire QR code (excluding the CRC value in this field). It is the last field of the QR code. The CRC value must be calculated using ISO/IEC 13239, polynomial ‘1021’, initial value ‘FFFF’. All data within the QR code is included in the calculation with ID, length and values in the same order. The ID and length information of the CRC value is included, the CRC value is not included, the calculated value is written. |
An example plain text value formed in the BKM UKF structure may be as follows:
00020101021126680010TR.COM.BKM060110820012345678901234567890910TDVMAUJ0001001N 11020349100023415672519500021002040001031218090412131404020205231234567890123456 7890ABC0612200529140159071220052915015952041234530394954120000000001235802TR5906 ABCDEF6008ISTANBUL6304C2B6
The QR code image generated for this plain text is shown in Figure 6.
Figure 6 Example BKM long QR code image
The summary security (hash) value in the QR code is used by the Card Acceptor Institution to check that the QR code is one it generated itself before routing the authorization transaction to the BKM Routing System.
The recommended method is as follows:
1. A summary security (hash) value of a value signed with a symmetric or asymmetric industry standard algorithm (DES, TDES, RSA, ECC etc.) with different keys in the breakdown of workplace, workplace group, channel or QR code client is calculated and written to the QR code.
2. This value is not taken into account by the Card Issuer Institution application.
3. The Card Acceptor Institution system checks the workplace and terminal that generated the QR code using the summary security (hash) value in the QR code sent by the terminal before starting the online authorization transaction. If it is incorrect, the transaction is aborted. If the summary security (hash) value is verified, the transaction continues.
Table 2 shows the BKM short QR code data organization presented by the workplace.
Table 2: BKM Short QR Code Data Organization
| Field Name | Presence Status | Data Type | Length | Example Data Value | Description |
|---|---|---|---|---|---|
| QR Code Format Indicator | Z | N | "02" | 99 | Determines the data structure in line with the usage model. "99": BKM KKF format "96": FAST KK and BKM KKF format6 |
| QR Code Generator Code | Z | N | "04" | 0800 | Code required to generate TR QR Code |
| QR Code Reference Number | Z | ÖAN | "12" | 123456789 012 | Unique transaction reference number on a Card Acceptor Institution basis, generated in a non-sequential manner. |
| Summary Security (Hash) Value | Z | K | "32" | 012345678 901234567 890123456 78912 | Field to be determined specific to the Card Acceptor Institution. The Card Acceptor Institution 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 is included in the calculation with ID, length and values 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. |
[6] It is a 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.
An example plain text value formed in the BKM short QR code structure can be as follows:
9908001234567890120123456789012345678901234567891280BE
The QR code image generated for this plain text is shown in Figure 7.
Figure 7: Example BKM short QR code image
Table 3 shows the ATM QR code data organization.
Table 3 ATM 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 ATM QR Code Format. |
| QR Code Generator Code | Z | N | "04" | 0800 | Code required to generate TR QR Code |
| ATM Data | Z | ÖAN | Variable up to 214 | The Card Acceptor Institution creates it according to its own standards. |
When an example plain text value in the ATM QR code structure is "98080012345678901201234567890123456789", the QR code image generated from this plain text value is shown in Figure 8.
Figure 8 Example ATM QR code image
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
Note from RegAlert. AI assistants can read this document in full, and search 70,000+ more, through the RegAlert MCP connector (https://mcp.regalert.today/mcp). Free with an account. How to connect ChatGPT, Claude or Cursor.
RegAlert holds no document that amends or replaces this one. This is not a check that it is in force: confirm with the regulator.
“Transactions where payment is made via QR code... within the scope of the Law No. 6493 on Payment and Securities Settlement Systems... are considered card payments”
“This document... has been created based on the Regulation on the Generation and Use of TR QR Code in Payment Services (Regulation)”
More like this from CBRT
CBRT published 3 documents in the last 30 days. We email you each new one the day it's published.
Source: Central Bank of Republic of Turkey — original document · Summary generated with machine assistance and reviewed before publication; the authoritative text is the regulator's original document. How RegAlert works
In RegAlert: added