Guidance · CBRT · 6 Jan 2021
Merchants and their payment service providers using the merchant-presented QR model must specify in the "operator code" subfield (code "01") of the mobile payments template (code "32") the mobile operators with which the provider has agreements; if the customer's operator is unsupported, the customer's application must error and not continue. After BKM's merchant registry system is established, that code must match the registered merchant code. The optional "Purpose of Payment" subfield (code "08") of template "62" may carry the service ID, and optional subfields must keep the template within its 99-character limit.
CENTRAL BANK OF THE REPUBLIC OF TURKEY
Mobile Payments
TR QR Code Technical Principles and
Rules Guide
December 2020
Version 1.0
Confidential
| Change Date | Change Description | Version |
|---|---|---|
| December 2020 | Initial Version | 1.0 |
The "Regulation on the Generation and Use of TR QR Code in Payment Services" (Regulation) and the "TR QR Code Principles and Rules" document annexed to this Regulation, prepared in order to ensure interoperability among the actors in the payments ecosystem by establishing common rules and a common language, to support innovative initiatives, and thus to contribute to the dissemination of QR code use in payment services, were published in the Official Gazette dated 21 August 2020 and numbered 31220 and entered into force.
With the TR QR Code, it is aimed to increase cashless payments in Turkey at all levels, to ensure QR code standardization for retail payments, and thus to support the goal of using less cash. With the common QR code rules, users of different payment service providers will be given the opportunity to make payments with QR codes, payments between different payment service providers will be facilitated, and businesses, including small-scale enterprises, will be encouraged to adopt QR codes as a payment method.
This document presents the technical principles and rules regarding the use of TR QR Code in payment services (mobile payment) specified in subparagraph (d) of the first paragraph of Article 12 of the Law on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions dated 20/6/2013 and numbered 6493 (Law).
In this document, which has been created in compliance with the Regulation and the TR QR Code Principles and Rules document annexed to the Regulation, sample mobile payment workflows are provided in accordance with the merchant-presented and consumer-presented QR code usage models, and the TR QR Code data organization for mobile payments is defined for both usage models.
Within the scope of the principles and rules contained in this document, the definitions in the TR QR Code Principles and Rules document have been used for the characteristics of QR code technology, the encoding of data objects, data types and formats, the QR code data organization according to the business model used, and the characteristics of data objects.
This document has been prepared based on the first paragraph of Article 6 of the Regulation.
Within the scope of this document;
Recipient: The real or legal person to whom the fund subject to the payment transaction is intended to reach,
Dynamic QR code: The QR code that is generated specifically for the payment transaction to be used and is single-use,
Electronic communications operator (ECO): The operator defined within the framework of the Electronic Communications Law dated 5/11/2008 and numbered 5809,
Sender: The real or legal person who issues a payment order from their own payment account or without having a payment account,
Mobile Operator: Electronic communications operator,
Merchant: The real or legal person who, as the recipient, accepts that a payment related to the price of a good or service be made using QR codes generated within the scope of the TR QR Code Principles and Rules, within the framework of the contract made with the payment service provider,
Merchant-presented QR code: The QR code model based on the principle that customers scan the QR code presented by the merchant through the application they use and initiate the payment transaction,
Law: The Law on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions dated 20/6/2013 and numbered 6493,
QR code: The two-dimensional code created to be used in payment transactions by scanning method; storing alphanumeric data, characters and symbols, consisting of three square pattern markers in the lower left corner, upper left corner and upper right corner according to the viewer, and having black and white modules in the form of square black-and-white dots or pixels,
QR code generator code: The code required to generate a TR QR Code,
QR Code Routing System (QRS): The infrastructure that enables the transfer of QR codes and the information contained therein between payment service providers,
User: Real or legal persons who make payments using QR codes,
Mobile payment: The payment service specified in subparagraph (d) of the first paragraph of Article 12 of the Law,
Customer: The person who is in the position of sender with respect to the realized transaction,
Consumer-presented QR code: The QR code model based on the principle that the merchant scans the QR code displayed by the customer who will make the payment through the QR code generation option in their application and initiates the payment transaction,
MSISDN: Mobile phone number (Mobile Station International Subscriber Directory Number1),
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,
Payment system: The structure that provides the infrastructure necessary for clearing and settlement operations to ensure the realization of fund transfers arising from transfer orders between three or more participants and has common rules,
Payment system operator: The legal person responsible for the daily operation of the payment system and holding the operating license required for system operation,
Static QR code: The QR code whose content is fixed and can be used in multiple payment transactions,
CBRT: Central Bank of the Republic of Turkey Joint Stock Company,
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] It is also used as Mobile Subscriber Integrated Services Digital Network.
In Article 12, paragraph one, subparagraph (d) of the Law, mobile payments defined as "a payment transaction where the approval for the execution of the payment transaction by the sender is given through an information or electronic communication device and the payment is made to an information or electronic communication operator acting solely as an intermediary between the payment service user and the provider of goods or services" may be carried out according to the QR code usage model presented by the merchant or presented by the customer. In this section, while example workflows for both models are presented, the following matters must be taken into consideration in relation to the subject:
1. In accordance with paragraph 4 of Article 5 of the Regulation on Payment Services and Electronic Money Issuance and Payment Institutions and Electronic Money Institutions, the services listed in Article 12, paragraph one, subparagraph (d) of the Law may be performed by the institution whose control is held by and which is represented by the information or electronic communication operator acting as an intermediary.
2. The workflows created are given as examples, and it is possible for the workflows to vary according to the business model and the regulations to which payment service providers and mobile operators are subject.
The QR code usage model presented by the merchant, which is based on the principle that the customer initiates the payment transaction by scanning the QR code generated at the merchant through the application, can also be used for mobile payments. Two example workflows relating to this model, for which different flows may be designed according to business models, are presented below.
The workflows are provided as examples to better understand payment transactions that can be carried out with the TR QR Code, and do not contain any limitation or direction regarding the business model or flow.
Example Workflow 1:
Figure 1 shows the workflows relating to the first example concerning the use of the QR code presented by the merchant, and in this business model, the merchant's payment service provider and the merchant do not have the customer's mobile operator and MSISDN information until the payment transaction is completed.
Figure 1: Example workflow 1 for mobile payment with the QR code model presented by the merchant
1. At the payment stage in the purchasing process, the payment page opens. The customer selects "mobile payment with QR code".
2. The merchant's payment service provider generates the QR code relating to the mobile payment and displays it on the payment page.
3. The customer scans the QR code through the application of the customer's payment service provider.
4. The customer checks the payment (product/service, amount, etc.) and seller (merchant) information and initiates the mobile payment transaction.
5. After the customer's payment service provider checks the information relating to the customer and the payment (balance check, mobile payment permissions, etc.), it sends a verification request or approval code to the customer via SMS through the customer's mobile operator.
6. The customer approves the payment through the various methods presented to them. For example:
6a. The customer approves the payment transaction by entering the approval code into the payment service provider's application.
or
6b. The customer approves the transaction by replying to the incoming SMS with expressions such as "APPROVE" or "YES".
7. The customer's payment service provider transmits the payment information to the customer's mobile operator.
8. The customer's mobile operator updates its records so as to reflect the payment on the customer's bill.
9. The customer's payment service provider informs the merchant's payment service provider and the customer, and the merchant's payment service provider informs the merchant, that the transaction has been completed.
In the flow designed above, the merchant's payment service provider specifies the mobile operators with which it has an agreement in the "operator code" subfield with code "01" of the mobile payments template with code "32" in the QR code. If the customer's mobile operator is not among these operators, the application used by the customer must give an error and must not continue the transaction.
In the "merchant number" subfield with code "02" of the mobile payments template with code "32" of the QR code, there is the "merchant number" information by which the merchant's payment service provider can uniquely identify the merchant in its own system. After the establishment of the merchant registry system to be created at BKM, the code to be specified in this field must be the same as the merchant code registered in the merchant registry system.
In addition, in the "Purpose of Payment" subfield with code "08" of the "Additional Data Fields Template" with code "62" of the QR code, it is possible to include the service information (service ID) relating to the purchased product.
The verification and approval mechanisms given in the flow are provided as examples, and these mechanisms may vary according to the business model and the regulations to which the customer's payment service provider and mobile operators are subject.
Example Workflow 2:
Figure 2 shows the workflows relating to the first example concerning the use of the QR code presented by the merchant, and in this business model, the merchant's payment service provider obtains the information relating to the customer and the payment from the customer's payment service provider via the QR Code Routing System (KYS), obtains the merchant's approval if needed, and thereafter transmits the request to the customer's payment service provider for the payment to be realized.
Figure 2: Example workflow 2 for mobile payment with the QR code model presented by the merchant
1. At the payment stage in the purchasing process, the payment page opens. The customer selects "mobile payment with QR code".
2. The merchant's payment service provider generates the QR code relating to the mobile payment and displays it on the payment page.
3. The customer scans the QR code through the application of the customer's payment service provider.
4. The customer checks the payment (product/service, amount) and seller (merchant) information and initiates the mobile payment transaction.
5. The customer's payment service provider transmits the information related to the payment in the QR code (QR code reference number, amount, product/service, etc.) and related to the customer (for example, the customer's MSISDN information) to the merchant's payment service provider (QR code generator) via the KYS.
6. The merchant's payment service provider optionally transmits the QR code information to the merchant and ensures verification of payment information, particularly the amount information (verifications such as discounted amount, discount, etc. offered by the customer's payment service provider).
7. The merchant's payment service provider transmits the information related to the mobile payment transaction to the customer's payment service provider.
8. The customer's payment service provider, after checking the information belonging to the customer and the payment (balance check, mobile payment permissions, etc.), sends a verification request or approval code to the customer via SMS through the customer's mobile operator.
9. The customer approves the payment through various methods presented to them. For example:
9a. The customer approves the payment transaction by entering the approval code into the payment service provider's application.
or
9b. The customer approves the transaction by replying to the incoming SMS with expressions such as "ONAY" or "EVET".
10. The customer's payment service provider transmits the approval result to the customer's mobile operator.
11. The customer's mobile operator updates its records to reflect the payment on the customer's bill.
12. The customer's payment service provider informs the merchant's payment service provider and the customer, and the merchant's payment service provider informs the merchant that the transaction has been completed.
In the flow constructed above, the merchant's payment service provider specifies the mobile operators with which it has agreements in the "operator code" subfield with code "01" of the mobile payments template with code "32" in the QR code. In the event that the customer's mobile operator is not among these operators, the application used by the customer must give an error and must not continue the transaction.
In the "merchant number" subfield with code "02" of the mobile payments template with code "32" of the QR code, the "merchant number" information that the merchant's payment service provider can uniquely identify the merchant in its own system is located. After the establishment of the merchant registry system to be created at BKM, the code to be specified in this field must be the same as the merchant code registered in the merchant registry system.
Additionally, in the "Purpose of Payment" subfield with code "08" of the "Additional Data Fields Template" with code "62" of the QR code, it is possible to include the service information (service ID) related to the purchased product.
The verification and approval mechanisms given in the flow are provided as examples, and these mechanisms may vary according to the business model and the regulations to which the customer's payment service provider and mobile operators are subject.
The QR code usage model presented by the customer, which is based on the principle that the customer who will make the payment shows the QR code created in the payment service provider's application and the payment transaction is initiated by scanning this QR code with the merchant's QR code reader, can also be used for mobile payments.
In Figure 3, the workflows related to the example regarding the use of the QR code presented by the customer are shown.
Figure 3: Example workflow of mobile payment with the QR code model presented by the customer
1. The customer creates the QR code for the mobile payment in the payment service provider's application.
2. The customer shows the QR code created in the first step on their mobile device at the payment stage of the purchasing process.
3. The merchant initiates the mobile payment transaction by scanning the QR code.
4. The merchant's payment service provider transmits the customer's mobile payment request, including payment information and information related to the merchant, to the customer's payment service provider.
5. The customer's payment service provider, after checking the information belonging to the customer and the payment (balance check, mobile payment permissions, etc.), sends a verification request or approval code to the customer via SMS through the customer's mobile operator.
6. The customer approves the payment through various methods presented to them. For example:
6a. The customer approves the payment transaction by entering the approval code on the merchant's payment page (or by telling the merchant).
or
6b. The customer approves the payment transaction by entering the approval code into their application.
7. The customer's payment service provider transmits the approval result to the customer's mobile operator.
8. The customer's mobile operator updates its records to reflect the payment on the customer's bill.
9. The customer's payment service provider informs the merchant's payment service provider and the customer, and the merchant's payment service provider informs the merchant that the transaction has been completed.
In the flow constructed above, the information related to the mobile operator to which the customer is a subscriber is specified in the "operator code" subfield with code "01" of the mobile payments template with code "32" in the QR code.
In the event that the customer's mobile operator is not a mobile operator supported by the merchant, the merchant application must give an error and must not continue the transaction.
Additionally, in the "MSISDN" field with code "02" of the mobile payments template with code "32" of the QR code, the customer's phone number and optionally in the fields numbered "01" and "03", the "account number" and "reference number" fields, respectively, which can uniquely identify the customer by the customer's payment service provider, are located. The reference number in question (or a part of it) can be displayed on the customer's screen together with the QR code, to be transmitted verbally by the customer, considering the situations where the QR code cannot be read by the merchant.
The verification and approval mechanisms given in the flow are provided as examples, and these mechanisms may vary according to the business model and the regulations to which the customer's payment service provider and mobile operators are subject.
The data within a QR code is organized in a tree structure as objects and under the root2 part of this structure, and is basically divided into two classes: simple data objects and data template objects. While simple data objects can store a single piece of information such as date, amount, reference number, data template objects can contain one or more simple data objects and other data template objects (Figure 4) 3 .
Figure 4: QR Code Data Structure Organization
Each object within the QR code has a data structure consisting of three parts:
Field code: Consists of two digits between “00” and “99” and specifies the identity of the object. Within a QR code, all field names have a unique value at the root level or within the data template in which they are located. For example, the object specified by the field code “01” under the root and the object specified by the field code “01” under a data template with field code “62” indicate different data from each other.
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 in the format “020820200530”.
The data value of the objects within the QR code supports the following data types:
[2] An object that is not under any data template.
[3] The relevant information is taken from the “TR QR Code Principles and Rules” document, which is an annex to the Regulation.
[4] UTF-8 (8-bit Unicode Transformation Format) is the name of the general standard that enables the representation of all universally available characters using a variable number of bytes from 1 to 4.
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.
In the QR code data organization, the following notation is used for the presence status of objects:
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 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 suitable for the 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 usage models presented by the merchant and presented by the customer to be used for mobile payments are given.
The data organization of the QR code presented by the merchant, for which example workflows are given in Section 4.1.1, has been created in accordance with the “Long QR Code Presented by the Merchant” data organization in the TR QR Code Principles and Rules document, and information regarding the data fields is shown in Table 1. The data template with field code “32”, which is specifically reserved for mobile payments in the table, contains the following subfields:
Operator Code: Indicates the mobile operators offering mobile payment facilities.
Merchant Number: The number that the merchant's payment service provider keeps in its own records and by which it can uniquely identify the merchant.
MSISDN: The phone number linked to the account for the merchant.
Summary security information (Hash): The summary security value calculated by the application that generates the QR code in order to verify the integrity of the payment information.
Table 1: QR Code Data Organization Presented by the Merchant for Mobile Payments
| Field Name | Field Code | Subfield code and Name | Data Type | Length | Presence Status | Sample Data | Description |
|---|---|---|---|---|---|---|---|
| QR Code Format Indicator | 00 | - | N | 02 | Z | 000201 | This is the value used for the QR code data organization presented by the merchant. The last two digits (data value) indicate the version number of the EMVCo standard with which the QR code data organization is compatible and have a fixed value of “01”. |
| QR Code Type | 01 | - | N | 02 | Z | For static QR code: 010211 For dynamic QR code: 010212 | Used to distinguish between Static and Dynamic QR Codes. Data value: “11”: Static QR Code where the same QR code is used for multiple transactions. “12”: Dynamic QR Code where a different QR code is used for each transaction. |
| Business Account Information | 02-46 | Business account information must be created under the "32" field code reserved for mobile payments | |||||
| 02-03 | Reserved for VISA. | These are fields reserved by EMVCo for EMV members. | |||||
| 04-05 | Reserved for Mastercard. | ||||||
| 06-08 | Reserved for EMVCo. | ||||||
| 09-10 | Reserved for Discover. | ||||||
| 11-12 | Reserved for Amex. | ||||||
| 13-14 | Reserved for JCB. | ||||||
| 15-16 | Reserved for UnionPay. | ||||||
| 17-25 | Reserved for EMVCo. | ||||||
| 26-27 | Used by BKM. | ||||||
| 28-29 | Reserved for BKM. | ||||||
| 30-31 | Used by FAST. | ||||||
| 32 | ÖA N | Variable up to 99 | Z | For Mobile Payments: 32uuVD | Used for mobile payments. VD: Data value of the relevant template. | ||
| uu: Total length in characters of the data value (VD) of the relevant template. | |||||||
| 00: Universal Unique Identifier | ÖAN | Variable up to 32 | İ | - | Will not be used for mobile payments. | ||
| 01: Operator Code | ÖAN | Variable up to 3 | Z | If the business accepts mobile payment through all three operators: 0103TCV | Used to specify the mobile operators that accept mobile payment for the business. One or more of the following characters (without repeating the same character) may be included in the field: "T": Türk Telekom "C": Turkcell "V": Vodafone Example: For Turkcell and Vodafone, "CV" or "VC" should be used, and for only Türk Telekom, "T" should be used. The order of the characters is not important. | ||
| 02: Business Number | ÖAN | Variable up to 30 | İ | For business code 25012: 020525012 | Unique number specific to the business held by the business's payment service provider. After the establishment of the business registry system to be created at BKM, the code to be specified in this field must be the same as the business code registered in the business registry system. | ||
| 03: MSISDN | N | Variable up to 15 | İ | 03105926100123 | Mobile Station International Subscriber Directory Number – Phone number linked to the account for the business | ||
| 20: Summary Security Value (Hash) | ÖAN | Variable up to 32 | İ | For the hash created with the QR code producer code, operator code and amount fields: 2032DD38000A97 AFAC7876FBB0537 3138525 | The summary security (hash) value calculated by the application that generates the QR code. The application used may use this field to verify the QR code. | ||
| 33-40 | Reserved for the CBRT | ||||||
| 41-46 | Reserved for other payment systems in Türkiye. Payment system operators who wish to use these field codes must apply to the CBRT. | ||||||
| Merchant Free Templates | 47-48 | ÖAN | Variable up to 99 | İ | 47uuVD 48uuVD | Merchants may use these fields freely as simple data and/or data templates in order to carry additional information related to the payment that is not defined in the other fields of the table (for example, product information, check, etc.) in the QR code. |
| Field Name | Field Code | Sub-field code and Name | Data Type | Length | Presence Status | Sample Data | Description |
|---|---|---|---|---|---|---|---|
| VD: The data value of the relevant template. uu: The total length in characters of the data value (VD) of the relevant template. | |||||||
| Merchant Code | 49 | N | 10 | İ | 4910000025012 | 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: 5016399394233 2851791 | 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 | 51uuVD | It is the QR code identity template generated by the QR code producer. The sub-fields belonging to the identity information are shown in Table 4. VD: The data value of the template. uu: The total length in characters of the data value (VD) of the template. | |
| 00: Version Number | N | 02 | Z | For the data organization in this document (version 1.0): 000210 | It is the TR QR code version number. For version number "S.s", the data value is created as "Ss" without using a punctuation mark. | ||
| 02: QR Code Producer Code | N | 04 | Z | For the payment service provider with code 0771: 02040771 | The code of the QR code producer. Payment Service Providers and payment system operators deemed appropriate by the CBRT will be able to obtain a QR code producer code by applying to BKM for registration in order to generate TR QR codes. Banks will use their EFT codes and do not need to register separately. Values shorter than 4 digits will be completed with the '0' character on the left side. |
| Field Name | Field Code | Sub-field code and Name | Data Type | Length | Presence Status | Sample Data | Description |
|---|---|---|---|---|---|---|---|
| 03: QR Code Reference Number | N | Variable up to 12 | K | For QR code reference number 23451017: 030823451017 | It is the unique reference number generated for the QR code. It is provided by the workplace application or 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 workplace 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 Web: 040205 | 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”: Workplace application “05”: Web “06”: Payment service provider's workplace application | ||
| 05: Terminal Device Serial Number | N | Variable up to 23 | İ | 05231234567890 1234567890ABC | The distinguishing value of the QR code generating device or terminal (for example, terminal number and/or terminal serial number). | ||
| 06: Creation Time | N | 12 | Z | For 02 October 2020 at 15.30:59: 0612201002153 059 | It is the time information when the QR code was generated. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24 hours), DD: minute, ss: Second | ||
| 07: Expiration Time | N | 12 | K | For 02 October 2020 at 16.30:59: 0712201002163 059 | It is the last time information that the QR code is valid. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24 hours), DD: minute, ss: Second Optional for static QR codes, mandatory for dynamic QR codes. | ||
| Workplace Category Code | 52 | N | 04 | Z | For markets: 52045499 | 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” (markets). If this field is not used, the value “0000” should be written. | |
| Currency | 53 | N | 03 | Z | For Turkish lira: 5303949 | It is the currency code of the transaction compliant with ISO 4217: |
| Field Name | Field Code | Subfield code and Name | Data Type | Length | Presence Status | Sample Data | Description |
|---|---|---|---|---|---|---|---|
| TRY: “949”, USD: “840”, EUR: “978”, etc. | |||||||
| Amount | 54 | N | 12 | İ | 75,5 TL for 5412000000007 550 | Indicates the amount of the payment transaction. The tip or other amount in the field with code "55" is not included. The last two digits indicate the decimal part (kuruş, etc.). To complete the amount to 12 digits, "0" is added to the left. If the amount value in this field is not available, the payment amount must be entered into the application by the customer. In addition, with an indicator in the relevant payment system template in the merchant account information, the entry of the payment by the customer into the application can be checked. | |
| Tip or Other Amount Indicator | 55 | N | 02 | İ | 550201 | It is the indicator for the use of tip or other amount: "01": The customer's application prompts the customer to enter the tip or other amount. "02": Indicates that the amount specified in the field with code "56" will be taken from the customer as a fixed other amount or other amount. "03": Indicates that a tip or other amount up to the percentage specified in the field with code "57" will be taken from the customer. | |
| Tip or Other Amount Value (Fixed) | 56 | N | 12 | K | 2,50 for 561200000000025 0 | Indicates the fixed tip or other amount. If the value of the field with code "55" is "02", this field must be filled. The last two digits indicate the decimal part (kuruş, cent, etc.). To complete the amount to 12 digits, "0" is added to the left. | |
| Tip or Other Amount Value (Percentage) | 57 | N | 05 | K | 570500325 for the value of 3.25% | Indicates the percentage tip or other amount. If the value of the field with code "55" is "03", this field must be filled. The last two digits give the decimal part. The percentage value given in this field of the amount specified in the field with code "54" constitutes the other amount. To complete the rate to five digits, "0" is added to the left. | |
| Country Code | 58 | ÖAN | 02 | Z | 5802TR | The 2-digit country code of the merchant as specified in ISO 3166-1 alpha 2. For Türkiye, "TR". |
Field Name
Field
Code
Sub-field code and Name
Data
Type
Length
Presence
Status
Sample Data Description
Merchant Name 59 ÖAN up to 25 variable Z 5909ABC STORE The account name of the merchant. During the transaction, it can be displayed on the screen of the customer's device. during the customer's device ekranında gösterilebilir.
Merchant City 60 ÖAN up to 15 variable Z 6008İSTANBUL The city name of the merchant.
Postal
Code 61 ÖAN up to 10 variable İ 610534100 The postal code of the merchant Additional Data Fields Template 62 K up to 99 variable İ 62uuVD Additional needed by the merchant contains the data.
VD: The template's data value. uu: The template's data value (VD) as characters total length5 .
01:
Invoice
Number up to ÖAN 25 variable İ 01085460980A
Invoice number.
In invoice payments, by the workplace within the QR code may be specified or to the consumer in the application he/she uses, the invoice a marker for entering the number may be.
02:
The customer's
Phone
Number up to ÖAN 15 variable İ
021290312507500
0
The customer's phone number.
By the workplace, within the QR code may be specified or to the consumer in the application he/she uses, the phone a marker for entering the number may be.
03:
Store
Label up to ÖAN 25 variable İ 0306AVMSTR
A label information that can be used to distinguish a specific store from the others.
By the workplace, within the QR code may be specified or to the consumer in the application he/she uses, the store a marker for entering the label may be. The consumer's application that reads the QR code may display this store information on the screen.
04:
The customer's
Loyalty
Number up to ÖAN 25 variable İ 04102315634123 The customer's loyalty card number.
By the workplace, within the QR code may be specified or to the consumer in the application he/she uses, the loyalty a marker for entering the number may be.
06:
Customer
Number
Up to ÖAN 25 variable İ 06100518894111
Used specifically for the customer and transmitted end-to-end label (subscriber number) value. For example, for a membership, the customer's member number may be.
By the workplace within the QR code can be specified or the customer's
[5] Due to the maximum total length of the field belonging to the template being 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.
| Field Name | Field Code | Subfield code and Name | Data Type | Length | Presence Status | Sample Data | Description |
|---|---|---|---|---|---|---|---|
| may be a sign for entering the tag number into the application it uses. | |||||||
| 08: Payment Purpose | ÖAN | up to 5 variable | İ | For service with code 1013: 08041013 | Code indicating the purpose of the payment transaction. Used for product/service code in mobile payment transaction. | ||
| 09: Additional Consumer Data | ÖAN | up to 3 variable | İ | 0901M | Contains indicators for additional data expected to be provided by the customer's mobile application in order for the payment transaction to be completed. This data is provided by the application without the need for customer approval. One or more of the following characters (without repeating the same character) may be present in the field: "A": Customer's address, "M": Customer's mobile phone number, "E": Customer's e-mail address. In case more than one character is used, each relevant data is required for the payment transaction to be initiated. | ||
| 10-49 | Reserved by EMVCo. | ||||||
| 51-99 | They are free fields specific to the payment system. | ||||||
| EMVCo Reserved Fields | 65-79 | K | up to 99 variable | İ | - | Reserved for future use by EMVCo. | |
| Free Templates | 80-99 | K | up to 99 variable | İ | - | They are fields reserved for future use within the scope of TR QR Code. Application must be made to TCMB for use. | |
| CRC | 63 | ÖAN | 04 | Z | 6304A47B | It is the integrity check value calculated over the entire QR code (excluding the CRC value in this field) (see: TR QR Code Principles and Rules). It is the last field of the QR code. |
Example:
00020101021232660103TCV020525012031059261001232032DD38000A97AFAC7876FBB05373138525491000000250125 01639939423328517915164000210020407710308234510170402050612201002153059071220100216305952045499530 394954120000000075505802TR5909ABC STORE6008İSTANBUL6105341006208080410136304A47B
The data organization of the QR code provided by the customer, for which example workflows are given in Section 4.1.2, has been created in accordance with the "QR Code Provided by the Customer" data organization contained in the TR QR Code Principles and Rules document, and information regarding the data fields is shown in Table 2. In the data template with field code "32" reserved specifically for mobile payments in the table, the following subfields are included:
Operator Code: Indicates the mobile operator of which the customer is a subscriber and which provides the mobile payment facility that the customer wishes to use to make the payment.
Customer Account Number: It is the customer's account number with the payment service provider.
MSISDN: It is the phone number that the customer will use for mobile payment.
Reference Number: It is the unique reference number given by the customer's payment service provider and identifying the customer.
Table 2: QR Code Data Organization Provided by the Customer in Mobile Payments
| Field Name | Field Code | Subfield Code:Name | Data Type | Length | Presence Status | Example Data Value | Description |
|---|---|---|---|---|---|---|---|
| QR Code Format Indicator | 85 | - | N | 02 | Z | For the data organization in this document (version 1.0): 850210 | It is the value used for the QR code data organization provided by the customer. The last two digits (data value) indicate the version number of the TR QR Code data organization. For version number "S.s", the data value is created as "Ss" without using a punctuation mark. |
| QR Code Type | 01 | - | N | 02 | Z | For static QR code: 010211 For dynamic QR code: 010212 | It is used to distinguish between Static and Dynamic QR Codes. Data value: "11": Static QR Code in which the same QR code is used for more than one transaction. "12": Dynamic QR Code in which a different QR code is used for each transaction. |
| QR Code Producer Code | 02 | - | N | 04 | Z | For payment service provider with code 0742: 02040742 | The code of the QR code producer. Payment Service Providers and payment system operators deemed appropriate by the TCMB will be able to obtain a QR code producer code by applying to BKM for registration in order to generate TR QR Codes. Banks will use their EFT codes and do not need to register separately. Values shorter than 4 digits will be padded on the left with the '0' character |
| QR Code Reference Number | 03 | ÖAN | Variable up to 12 | K | For reference number 17652401: 030817652401 | It is a unique reference number created specifically for the QR code. It is mandatory if it is created as a dynamic QR code, and optional for static QR codes. |
| Field Name | Field Code | Subfield Code:Name | Data Type | Length | Presence Status | Example Data Value | Description |
|---|---|---|---|---|---|---|---|
| Commercial Transaction Indicator | 04 | N | 01 | İ | For a commercial transaction: 04011 | Indicates whether the payment made using the QR code is a commercial transaction or not: "0": Not a commercial transaction "1": Commercial transaction | |
| Creation Time | 06 | N | 12 | İ | For 02 October 2020 at 14.00:00: 061220100214 0000 | It is the time information when the QR code was generated. YYAAGGSSDDss YY: Year, AA: Month, GG: Day, SS: Hour (24 hours), DD: minute, ss: Second | |
| Last Validity Time | 07 | N | 12 | İ | For 31 December 2020 at 23.59:59: 071220123123 5959 | 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 | |
| Mobile Payment Template | 32 | ÖAN | variable up to 99 | İ | 32uuVD | It is the data template that can be used for the customer to perform mobile payment. VD: Data value of the template. uu: Total length of the data value (VD) of the template in characters. | |
| 01: Operator Code | N | 1 | Z | If the customer is a Türk Telekom subscriber: 0101T | It is used to specify the mobile operator that accepts mobile payment for the customer. One of the following characters must be included as the data value. "T": Türk Telekom "C": Turkcell "V": "Vodafone" | ||
| 02: Customer Account number | ÖAN | variable up to 30 | İ | 020823145877 | The customer's account number with the payment service provider | ||
| 03: MSISDN | ÖAN | variable up to 15 | Z | 031059262312 14 | Mobile Station International Subscriber Directory Number – The phone number the customer will use for mobile payment | ||
| 04: Reference Number | ÖAN | variable up to 25 | İ | 0406612345 | The unique reference number given by the customer's payment service provider and identifying the customer. | ||
| Application Template | 61 | ÖAN | variable up to 99 | K | 61uuVD | Template containing customer account information or account information indicator. If the mobile payment template is used, one or more application templates may optionally be used. If the mobile payment template is not used, more than one application template may be used, at least one of which is mandatory. VD: Data value of the template. uu: Total length of the data value (VD) of the template in characters | |
| 01: | ÖAN | 26 | K | 0126TR1234 5678901234 5678901234 | The account number (IBAN) that the customer will use to make the payment. | ||
| Account Number (IBAN) | This field, the card number field with code “02” and the easy address type field with code “04”, at most one of them can be filled. | ||||||
| 02: Card Number | ÖAN | Variable up to 16 | K | 0216510112 3456789012 | The card number to which the customer will make the payment. It is created without spaces. This field, the account number (IBAN) field with code “01” and the easy address type field with code “04”, at most one of them can be filled. | ||
| 03: Card Expiration Date | N | 04 | K | For July 2021: 03042107 | If the field with code “02” (card number) is used, it indicates the expiration date of the card in YYAA format: YY: year AA: month | ||
| 04: Easy Address Type | K | 01 | K | For phone number use: 0401T | If an easy address is used, it indicates which type of easy address will be used. According to the defined values below, the relevant easy address must be in the field with code “05” (For current values, the “FAST Kolay Adresleme Servisi Referans Dokümanı” document must be consulted): “T”:Phone number “K”:TCKN “V”:VKN “Y”:YKN “E”:E-mail This field, the account number (IBAN) field with code “01” and the card number field with code “02”, at most one of them can be filled. | ||
| 05: Easy Address Value | ÖAN | Variable up to 50 | K | For phone number: 0512903121 234567 | If there is a valid value in the easy address type field with code “04”, it contains the easy address value corresponding to it. | ||
| 06: Customer Number | ÖAN | Variable up to 25 | İ | 0605A2451 | Tag that can be used for end-to-end customer recognition (subscriber number, membership number, etc.). | ||
| 07: Customer's Name and Surname | ÖAN | Variable between 2-26 | K | 0711HASANY ILDIZ | The customer's name and surname in the application. If the field “01” (IBAN) is selected, it is mandatory, in other cases it is optional. | ||
| 10-20 | ÖAN | Variable up to 25 | İ | - | These are free fields that can be used for information not defined in the other fields of the QR code. | ||
| Summary Security | 20 | ÖAN | Variable up to 32 | İ | QR code producer code, QR code reference | The summary security (hash) value calculated by the application that generates the QR code. The application used, | |
| Value (Hash) | for the hash created from the number and MSISDN fields: 2032F2675AB8 646A538D3183 46558012A764 | can use this field to verify the QR code. | |||||
| Location | 50 | N | Variable between 16-34 | İ | Latitude: 39.939432 Longitude: 32.851720 for: 50163993943 232851720 | It is the location information that can be used for payment transaction with QR code and created according to Decimal Degrees (DD) format. The location value consists of two parts of equal length, the first being latitude and the second being longitude. For Latitude: 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 precision level to be used. | |
| CRC | 63 | - | ÖAN | 04 | Z | 63048C75 | It is the integrity check value calculated over the entire QR code (excluding the CRC value) (see: TR QR Code Principles and Rules). It is the last field of the QR code data. |
Example:
85021001021102040742030817652401040110612201002140000071220123123595932410101T0208 231458770310592623121404066123452032F2675AB8646A538D318346558012A76450163993943232 85172063048C75
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 code
Unicode: Unicode Standard, specifically the UTF-8 encoding form
Regulation on the Generation and Use of TR QR Code in Payment Services, Official Gazette, 21 August 2020, Number: 31220
TR QR Code Principles and Rules 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.
“specified in subparagraph (d) of the first paragraph of Article 12 of the Law on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions dated 20/6/2013 and numbered 6493”
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