QRPh Part 4 - What is in the QR Code?
In part one of the QRPh series I looked at the history of QR payments in the Philippines, in part two I described how a transaction might be processed, and in part three I was writing about the EMV roots of QRPh. In the fourth part, I dissect the data of a dynamic merchant-presented QR code.
The QR Code was presented by a payment terminal for a retail transaction at a department store in Makati. It worked with the QRh payment function of my BPI banking application.
The QR Code
The Raw QR Code Data
00020101021228560011ph.ppmi.p2m0111RCBCPHMMXXX031500060078800069 6050331052045311530360854071458.315802PH5918LANDMARK Makati DS60 06Makati62610012ph.ppmi.qrph031500060078800069605100000438638070 82000651988710012ph.ppmi.qrph0151000600788000696~000600788000696 ~20006519~000043863863049616
An Analysis of the Decoded QR Code Data
Payload Format Indicator: T:00 L:02 V:01 (EMV Merchant Presented QR, Version 1.1)
Point of Initiation Method: T:01 L:02 V:12 (dynamic QR)
Template: T:28 L:56 (Merchant Account Information Template, Proprietary, Section 4.7.11, Table 4.2)
Unique Identifier: T:00 L:11 V:ph.ppmi.p2m (1)
Acquirer Bank Swift Code: T:01 L:11 V:RCBCPHMMXXX (2)
Store Label: T:03 L:15 V:000600788000696 (2)
Unknown: T:05 L:03 V:310 (3)
Merchant Category: T:52 L:04 V:5311 (Department Store, see ISO 18245 for codes) (4)
Transaction Currency Code: T:53 L:03 V:608 (see ISO 4217 for codes)
Amount: T:54 L:07 V:1458.31
Country Code: T:58 L:02 V:PH (see ISO 3166-1 alpha 2 for values)
Merchant Name: T:59 L:18 V:LANDMARK Makati DS
Merchant City: T:60 L:06 V:Makati
Template: T:62 L:61 (Additional Data Field Template, Section 3.2, Table 3.7)
Unique Identifier: T:00 L:12 V:ph.ppmi.qrph (5)
Store Label: T:03 L:15 V:000600788000696 (6)
Reference Label: T:05 L:10 V:0000438638
Terminal Label: T:07 L:08 V:20006519
Template: T:88 L:71 (Unreserved Template, Proprietary, Section 4.11, Table 4.8) (7)
Unique Identifier: T:00 L:12 V:ph.ppmi.qrph
Proprietary Data: T:01 L:51 V:000600788000696~000600788000696~20006519~0000438638
Store Label: 000600788000696
Separator: ~
Store Label: 000600788000696
Separator: ~
Terminal Label: 20006519
Separator: ~
ReferenceLabel: 0000438638
CRC: T:63 L:04 V:9616| 1 | As I predicted in my post about the EMV foundation of QRPh, the reverse domain name option is used for a unique identifier. Equally, as predicted, the domain name is not registered to PPMI, and is therefore completely arbitrary and may therefore not be unique.
In any case, "ph.ptpmi.p2m" likely stands for customer to merchant payment, and I would guess that person to person payments would use "p2p". I wonder, however, what a business to business transaction would use - "m2m" or b2b"? |
| 2 | The merchant account is identified by two data elements:
Using the swift number here means that the QR provider must be registered with SWIFT, which adds an unnecessary hurdle for smaller players and startups. Other countries have chosen different approaches. If I had to design this, I would have created a registry under the respective scheme and let them assign incremental numbers on the first-come-first-serve basis. With a good encoding scheme, you would never need more than two or three bytes, and you can let anybody who meets your requirements into the system without adding unnecessary red tape. |
| 3 | I tried to work out what tag 5 might refer to, but could not find a standardized number scheme (currency code, country code, merchant category etc.) that would make sense here. |
| 4 | The top-level tags are being used as defined in the EMV specification. The only uncertainty here is the merchant name and city. The question is whether the name and city refer to the company or the acceptance location. I have seen other QR codes where the city was given as Manila, even though the store was in the province. |
| 5 | I believe that the QRPh specification, or at least this particular QR code data, deviates from the EMV specification. The "Additional Data Field Template" defines a couple of tags that can be included at the top-level of this template, and it defines a number of tag IDs that can be used for proprietary templates. The proprietary templates must have a unique identifier with tag '0'. The "Additional Data Field Template" itself should not have a unique identifier since all tags in this template are defined by EMV. Therefore, the unique identifier is misplaced here. It also seems unnecessary anyway because all the tags that are used here are being used with the meaning defined by EMV. |
| 6 | The store label is already included in the merchant account information and therefore redundant. |
| 7 | This one is truly puzzling. The proprietary template is in the PPMI (i.e., the QRPh domain), which means the meaning of the tag values is defined by QRPh. It is therefore strange that the store label, terminal label and reference label are repeated here. All this information is already in the additional data template. The store label appears even twice in tag '01', which is probably because the first and second elements of the value are there to distinguish branches or some other subcategory of the store/merchant. |
And that’s it.
I analyzed a couple of other dynamic QR codes from different stores. The main difference is in the proprietary template. The only commonality in the proprietary template of different QR codes which I could find is the separation of fields within the value of tag 1 by a tilde, ~. I have seen a similar design in proprietary payment QR codes and suspect that it is included as a concession to proprietary systems that might rely on this data. The fact that it is in the PPMI domain is telling me that there is a system-wide need for this data and that is not proprietary to the accepting/receiving QR participant or that most participants require that data. Maybe it is necessary for the backend real-time funds transfer system?