QRPh Part 3 - An Actual Transaction
To find out a bit more about QRPh and how it works, I was looking for a place where I can actually conduct a QRPh transactions. An opportunity presented itself last year at the Landmark Department Store in Makati. In this post I am describing the customer experience and speculate what the backend transaction flow would look like. Since then, I have done a lot of QRPh transactions which all went even better, as cashiers are getting used to this.
-
I am at Landmark Department Store in Makati trying to buy some Christmas decoration for PHP 1458.31. (Yes, we start Christmas rather early in the Philippines.)
-
To my delight, I noticed a big sign next to the cashier, which announces the acceptance of QRPh together with a couple of logos of banks and e-wallets who should be able to scan the QR code.
-
That is interesting. I wonder how that will work. And so, to the annoyance of the cashier and the people behind me in the queue, I am asking to pay with QRPh.
-
In fact, my bank, BPI, is on the sign as well, so I will be trying to use the online banking application rather than an e-wallet. How exciting!
-
My better half starts rolling her eyes.
-
The cashier gets nervous and gives me one of the Standard answers of any Filipino shop attendant: "It’s offline/not available/out of stock, Sir."
-
My better half asks me what is wrong with me, so I insist on paying with QRPh anyway.
-
The supervisor is called who finds a button labeled QRPh.
-
After that, it works like magic. The POS terminal shows a QR code and even prints it out, so that I do not have to reach over into the cashier’s den to scan the code.
-
Here is the Merchant Presented QR code for me to scan.
-
I am opening the BPI app and without even logging in, find the QR option on the first screen.
-
Scanning is extremely fast, and the following screen is clear enough.
-
After one or two more taps, the whole transaction is over and the POS terminal prints a receipt almost immediately.
-
I love it. Well done, Philippines!
E-wallets and card companies must see this development with concern. Why load the e-wallet or deal with credit or debit cards, if I can pay directly from my bank account with my mobile phone.
The inner workings of QRPh
As far as I know, the detailed inner workings of such a transaction are not in the public domain, but a QR payment transaction will follow some common principles. We can therefore guess what happened.
Follow the transaction flow in the picture below.
-
The POS terminal will inform the receiver PSP that it expects a payment of a certain amount.
The receiver PSP will create a pending payment transaction, create a reference ID and return the formatted QR data or even a QR picture to the POS terminal.
-
The POS terminal uses the QR picture from the backend or creates a QR code, which is then displayed and maybe even printed.
-
The customer opens the mobile application of the e-wallet or bank they intend to pay with.
-
After reviewing the transaction data, which is taken from the QR code and displayed on the customer’s phone, an authorization is sent to the sender PSP. The authorization also contains information about the receiver PSP and the merchant account that should receive the payment amount.
-
It is straightforward to see how a fraudulent player could replace the destination account in the QR code while leaving the original merchant name untouched. To prevent this, either the mobile phone app sends a request to the backend system to check whether there is a pending payment request with the merchant name and account before showing the merchant name to the customer, or the transaction is cancelled when it turns out at a later step that the QR code data and the pending payment request do not match.
-
The sender PSP credits the customer’s account with the payment amount and sends a money transfer message to InstaPay. InstaPay routes that message to the receiver PSP.
-
The receiver PSP checks the reference ID and matches it with the id of the pending payment transaction. I assume that at this point a lot of checks are necessary, for instance, to ensure the reference ID hasn’t expired, that the reference ID hasn’t already been used and so forth.
It might be at this point that the receiver PSP already deducts the merchant fee for the transaction and only debits the discounted transaction amount. Or maybe, the fees are calculated periodically and billed separately. It is unlikely that for offline[1] transactions, the sender PSP would charge the customer a fee. However, a percentage of the merchant fee may actually go the sender PSP (in traditional payment systems that would be called an interchange fee).
-
If everything went well, the receiver PSP will send a notification to the POS, which will then print a receipt and conclude the transaction. It is also likely that the sender PSP will send a confirmation message to the customer.