Card-Backed QR Payment - Good or Bad?
Two developments in the payment industry in the Philippines are casting a shadow over the future of QR payments as a credible competitor to traditional payment cards.
The first one is GCash announcing (1) that they will allow credit cards to back retail payment transactions if there is not enough money in the GCash account.
The second is the introduction of ApplePay (2).
Why would those two developments be good or bad? The answer is as always: It depends. It is good for the trainload payment card schemes, bad for the e-wallet providers, somewhat neutral for the customer, and disastrous for competition in the payment industry.
In my new article, I will first take some educated guesses how these two products likely work, and then I will discuss why I think that this is not good for a healthy competitive payment industry.
The GCash Credit Card Announcement
GCash said that sometimes in August they will add a function to their e-wallet application that will allow customers to link a credit card to their e-wallet account.
This is not the first time GCash has been trying to find a way to integrate traditional payment cards into their product portfolio.
The most prominent one is the issuance of a physical Debit card that can be used like any other MasterCard at the point of sale.
Transactions on this card are authorized against the GCash balance.
There also used to be a way to link an Amex virtual card, but this function has been discontinued and I never had an opportunity to find out how it worked.
The important point of the existing Debit MasterCard was that it added one more access channel to the customer’s money in the GCash e-wallet.
This, and the fact that at its introduction it was not at all clear that EMV capable terminals would proliferate as much as they are now, meant that the Debit card did not really compete with the GCash QR payment functionality[1]
The newly announced functionality, on the other hand, takes a different approach. The credit card, which will be linked to the e-wallet, provides access to the credit card credit line. The main relationship with the customer will therefore shift from the e-wallet to the card issuer.
The QR payment channel becomes just another option to use the payment card at the point of sale. In fact, it opens up the part of the acceptance market that still has no EMV capable terminals. And because of it, the natural advantage of e-wallets disappears.
But even at merchants that already have a terminal, the new product does nothing good for GCash. The customer will ask themselves: Why do I have to add my card in the GCash app first when I could use it by just tapping it?
That means customers who would otherwise have topped up their e-wallet balance to take advantage of the features of an account-to-account QR payment will simply reach for their payment card.
I know I would.
How GCash Might Use Credit Cards to Fund a Transaction
The statements above are based on the assumption that the GCash/Credit Card link will work as follows (the callouts refer to Figure 1, “QR Code Payment, Credit Card Funded”):
-
The customer enters the card details and authorizes GCash to use the card to initiate transactions.
It would work the same as card-on-file systems with all the negative implications for data security and unauthorized transaction fraud. * You could also say that this feature is similar to Apple Pay or Google Wallet. The e-wallet account is like a token that represents a card account which is tored in the backend.
-
At the point of sale, either the customer scans a P2B QR code presented by the payment terminal or the terminal scans a QR code created by the customer’s mobile phone
. -
The Mobile app will send the QR information to the backend of the QR provider, or it may have already received it during the creation of the customer-presented QR code
.The Payment terminal will also communicate with the backend of its own QR provider, which will send a payment request to the sending QR provider.
In any case the backend system will now have a pending transaction setup.
In the case of a merchant-presented QR code, the receiving QR provider may simply wait for a push payment to arrive.
-
The GCash backend will check whether the e-wallet balance is sufficient for the payment amount.
-
If it is, the amount will be deducted from the balance and the transaction concludes as normal.
-
If the balance is not enough,
the GCash app will initiate a card-not-present payment transaction instead.
-
-
If the payment transaction is authorized, the transaction concludes as normal.
-
The CNP transaction will likely take place in the backend system. The mobile phone won’t have access to the payment card details, which are therefore also not given to the merchant.
The transaction will likely happen in two phases.
-
First, there will be a CNP transaction to get authorization for the funding, and
-
Second, there will be a push transaction to the merchant just like with any other QR payment transaction
.
-
-
In a standard CNP transaction the merchant would send a settlement request to the acquirer who is settling the amount with the payment scheme and pays the merchant when the money has been received.
-
GCash, on the other hand, will have to act as a stand-in merchant for the actual merchant to request money from the acquirer.
-
A card-present transaction has thus been converted into a CNP transaction, which has implications for fraud liability.
GCash won’t be able to conduct a 3D Secure transaction, and the usual protection for card offline transaction does not apply because there is no offline authentication via EMV.
-
It would be interesting to know how they design the settlement and dispute resolution.
I imagine that the merchant will only get the money once GCash is getting it from the payment scheme.
-
Another question would be how they design the fee structure. The fee that GCash is charging for a QR transaction would have to cover the interchange and acquiring fee they have to pay to the acquirer.
The Apple Pay Announcement
I am not going to go into the details of how Apple Pay works.Only that much:
-
The cardholder will “install” the payment card into the Apple Wallet application.
Installation in this context means that a token is generated and stored in the Apple Wallet.
-
The token is then linked to the actual card number somewhere in the upstream systems.
-
The NFC interface of the mobile phone is used to “simulate” an EMV card. Tapping the phone on the payment terminal is the equivalent of tapping the physical card.
The difference is that the terminal will receive the token, which will have to be translated back to the actual account number somewhere in the backend systems on the way to the issuer.
-
Note that the transaction is completely offline on the Apple Wallet side. There is no connection to the Issuer during the transaction. This is very different from the GCAsh setup.
I admit that I have never used Apple Pay myself. Everytime, when this product was introduced in one country, I moved to another country where it wasn’t available yet.
But the fact is that once the card has been provisioned in the Apple Wallet, the customer does not even have to log into the phone anymore before tapping the phone.
The wallet also keeps track of the transactions so that the customer may list past transactions with merchant names and such.
We can see from all this that using the card within the Apple Pay wallet is very similar to using it from the GCash e-wallet. And, unless the GCash wallet is taking advantage of better transaction data, it may even be more convenient to use the Apple Wallet.
The Implications for QR code Payments
The general implication of both announcements will be that QR code payments become less relevant for payment transaction at merchants that have a payment terminal. For smaller merchants that accept payments using the P2P functionality of InstaPay nothing will change.
As I said earlier, at merchants that already have an EMV terminal, customers will reach for the Apple Wallet or the physical card and stop using GCash.
At merchants that use QR Codes only, GCash is demoted to being just another POS technology for providing access to the functionality of a payment card.
We should also not forget that merchants who accept QRPh usually already have a payment terminal that also supports EMV.
Smaller merchants often use P2P QR codes backed by InstaPay©, and I believe the payment card functionality within the GCash wallet probably only applies to actual merchant retail transaction (P2B), which means QRPh.
References
(1) D. L. Lucas, “Visa, GCash deepen digital payments with card-funded QR feature.” https://insiderph.com/visa-gcash-deepen-digital-payments-with-card-funded-qr-feature , Aug. 2026, Accessed: Aug. 10, 2026. [Online].
(2) Apple, “Apple Pay launches in the Philippines.” https://www.apple.com/ph/newsroom/2026/08/apple-pay-launches-in-the-philippines/ , Aug. 2026, Accessed: Aug. 10, 2026. [Online].
Copyright Sources
SVG Repo, “Winners And Losers Success And Failure SVG Icon.” https://www.svgrepo.com/svg/308165/winners-and-losers-success-and-failure , Aug. 2026, Accessed: Aug. 11, 2026. [Online].