
Manila MRT3 EMV and QR Acceptance - The GCash Commuter QR Code
As reported earlier, on July 25, 2025, MRT-3 in Manila started to accept GCash QR codes directly at the gate, without the need to buy a prepaid ticket.
I have not found reports of first-hand experience with this new feature. All I can talk about here is what I can deduce from the user experience with the GCash application and from comparing the QR code data to the QCAT specification. I cannot say anything about processing until I have tried it myself.
In summary, there does not seem to be much support for interoperability. I would say that the e-wallets may have missed a chance to compete with the payment cards schemes in the AFCS market.

Manila MRT3 EMV and QR Acceptance - I have some answers
As announced, MRT-3 in Manila, Philippines, started accepting payment cards and GCash QR codes at some of their automated gates (see (1) and (2)).
According to the DOTR facebook posts, two stations (Ayala and Cubao) have two upgraded gates for entry and exit, while one gate was upgraded at all other MRT-3 stations.
Based on the pictures and video clips and the information I get from Facebook posts and press releases, I got answers for some of my earlier questions.

Manila MRT3 EMV and QR Acceptance - I have questions
The secretary of the DOTR said on radio that on July 25, 2025, MRT-3 will start piloting the use of QR code wallets, credit cards and debit cards at one automated gate in each of the MRT-3 stations.
Previously, on May 30, 2025, the government already announced that Gcash, as well as Debit and Credit cards, will be accepted for payment of train fares.
It seems that kentkart provided and installed the solution. They probably didn’t start in June, but even if they already started last year, the speed of getting to a working pilot is impressive.
As the use of e-wallets is truly fascinating for me, I would love to know more about the user experience. Unfortunately, I don’t live in Manila anymore and can’t check it out myself. If anybody has the time to try out a few transaction with both payment cards and GCash, maybe they can comment here and let us all know how it went.
As the saying goes, those who believe that something cannot be done should get out of the way of those doing it.
Nevertheless, fancying myself to be an old "engineer", I cannot help myself but think of reasons why such an implementation would be difficult.
I therefore have a few questions:

Part 3 - QR, EMV and Fare Collection
In my previous post I outlined why QR-based payments are problematic for ticketing applications. However, there are ways to use QR codes in automated fare collection systems, which I will describe in this post.

Part 2 - QR, EMV and Fare Collection
In my previous post, I outlined why EMV is eminently suited for account-based ticketing. QR and eWallet payments, on the other hand, do not seem to fare so well in the fare collection world.
In this post, I am looking at the reason why that might be so.

Part 1 - QR, EMV and Fare Collection
The success of QR-based, realtime, account-to-account payment systems in Asia is remarkable. It introduced a long-overdue element of healthy competition into the payment industry that was dominated by banks and their card payments (domestic as well as Visa/MC).
However, contactless EMV gives traditional payment systems two huge advantages that cannot easily be overcome by the new QR systems: fast, tap-and-go style transactions and account-based ticketing in automated fare collection systems.
In this article, I am trying to explain why EMV is so suitable for mass transport ticketing. In the next article, I will then cover three topics:
-
Can and should QR codes be used for fare collection?
-
Is EMV technology the only solution for account-based ticketing?
-
Can (and should) the new players just pick and choose the parts of EMV that they need for mass transport ticketing?

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.

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.

QRPh Part 2 - The EMV Roots
:toc:preamble
Banks and their regulators have been conditioned to believe that EMV is the global standard for card payments. It is therefore not surprising that all domestic QR payment standards, including QRPh, are based on the EMV QR specifications. For this reason, I am covering the design of the EMV specification, before I will go into the QRPh specification in one of the next posts.

QRPh Part 1 - What is it, and why does it exist
Most, maybe all, countries in South East Asia have their own national QR code standard which is usually based on the EMV merchant-presented QR standard (for instance, Cambodia (1), Singapore (2) or Vietnam (3).
The Philippines, where the standard is called QRPh, is no exception. However, as far as I know, neither the QR code part nor the backend processing part of the QRPh standard are in the public domain.
But since the QR codes out there can be analyzed based on the EMV standard, and the backend processing can be inferred from press releases and other public sources, we know quite a bit about it.
In the next couple of posts on my blog, I will look at the QR code format, the user experience, the backend processing and the EMV underpinnings.