QR, AFCS and NFC - An exciting Ménage à Trois
The large-scale rollout of NFC terminals in the wake of QR acceptance, paired with the ubiquitous cross-border acceptance of EMV payment cards and the eminent suitability of contactless EMV for mass transit account-based ticketing, has put QR payment systems on the backfoot.
Just when we thought traditional payment cards have lost the race, they are rapidly eating into the QR payment lead.
The solutions are clear to me. QR payment systems must come together and build a cross-border system that deserves its name, and they have to transition to the NFC interface of the mobile phones[1] for mutual authentication.
One might ask why bother with some NFC-QR contraption when we already have EMV, which is proven and works globally. My answer would be that it would indeed be a waste of time if NFC-QR simply mimics the EMV-based payment schemes.
But if the QR payment providers remember that there is more to QR payment than just the mobile phone camera and a checkerboard of ones and zeros, NFC-QR can be more than an imitation of EMV.
In fact, when you add authentication and mutual data exchange at the point of interaction, you will find that many things are possible that would require cost-prohibitive changes to traditional payment schemes.
One such option would be a sender-centric QR-NFC system. In my article I am outlining such a system using the example of account-based automated fare collection.
- QR Code and NFC
- The benefits of real-time push-payments
- A Sender Centric NFC-QR Use Case
- The NFC-QR Entry Transaction Flow
- The NFC-QR Exit Transaction Flow
- The IOU QR Data
- Offline Authentication
- Reconciliation and Settlement
- Matching entry and Exit Records
- No Stop Lists (aka Blacklist) Needed!
- Terms and Definitions
QR Code and NFC
The recipe for the early success of QR payments was the combination of ubiquitous mobile phone cameras and the low-friction on-boarding of merchants with printed QR codes and dumb phones for receiving approval codes.
The ease at which payments could be accepted through P2P transfers also played a role.
Over time, the creation of domestic realtime money transfer hubs and the enforcement of national QR code standards opened up the sending side to a lot more players and consolidated the accepted side.
Due to the consolidation of the acceptance side - one device for all QR participants – it became economically viable to roll out payment terminals that support NFC as well as merchant-presented dynamic QR codes.
This put EMV payment cards on an equal footing in the acquiring market once again. The inability of the QR payment system to compete effectively in the account-based ticketing market now turned the table. QR providers cannot rely on a larger acceptance market to stay ahead of the general purpose EMV payment cards anymore.
The chaos that pretends to be a cross-border QR payment system may be the straw that is going to break the carabao’s back. I wrote about it here (1).
There is, however, one decisive issue that could keep QR payments in the race – Mutual Offline Authentication based on NFC.
While for merchant-presented QR codes, with both sides having a trusted real-time connection to their service providers, authentication might be optional, for customer-presented QR codes, especially in environments such as public transport, where the acceptance terminal may not have a connection, authentication is sooner or later a necessity.
I my view, the trick is to maintain the benefits of real-time push payments for customer-presented NFC-QR transactions[2].
If the QR systems decide to mimic the pull-payment of traditional card systems, possibly with the overhead of the two-pase authorization/settlement process and the intricacies in dispute resolution that come with it, they would have lost the match before entering the ring.
The benefits of real-time push-payments
What are the benefits of real-time push payments as practices by e-wallets?
-
Privacy
The merchant or AFCS provider does not need to keep customer account data to perform reconciliation and settlement. As I say later in this article, the merchant gets money, not customer data.
-
Customer Control
It is always the customer who initiates the actual money transfer. The merchant or the AFCS provider do not have the right or means to deduct money from the customer account.
On the other hand, the customer, and possibly their QR provider, have full access to the merchant account information and can decide whether this information agrees with the transaction the customer is currently deducting.
Merchants would have a huge incentive to ensure their account data matches their appearance on the internet or their physical presence. Criminals would have a much harder time concealing their true identity.
-
Better Risk Management
The transaction record can be enriched by the customer phone without relying on the acceptance side. For instance, it would be desirable to include GPS location information that can be compared with the merchant data (see point above).
The customer can also be given sophisticated and at the same time simple means to control their spending. Spending limits could be set at various levels or for different time periods. The actual spend vs. the respective limit is available almost immediately.
-
Reduced Data Security Cost
PCI DSS was created for one reason only, the proliferation and invariable compromise of customer data on the acceptance side. When there is no customer data, there is also nothing to protect, and PCI cost should come down, especially if EMV cards play less of a role.
The same applies to the cost of protecting personal data under the data privacy laws.
A Sender Centric NFC-QR Use Case
In the rest of this article I am describing a possible use case for an AFCS ticketing system.
In this use case the camera scan of a customer-presented QR code image is replaced by a data exchange over a NFC interface.
The proposed solution is sender-centric, which means that the AFCS only gets the minimum of data necessary for reconciliation of settlement records, while the passenger is in control of creating tickets and sending money. The AFCS does not get any passenger account data nor data that would identify the passenger across multiple ticketing transactions.
In other words, in this solution the AFCS validator provides "merchant account info and transaction data" to the passenger device even so it is a customer-initiated ticket transaction. This would ot be possible in the traditional QR code systems.
The same principles can be applied to retail payment transactions.
|
The term QR in conjunction with NFC does not have much meaning anymore. I am still using it to emphasiseze the link to the existing QR payment systems. One could say that I really mean customer-initiated, real-time fund transfer, account-to-account payment systems. |
The NFC-QR Entry Transaction Flow
|
The passenger’s mobile phone app asks the sending QR providee for a special QR Code, whihc we will call the IOU QR code. This code is really just some data such as the purpose of the code, a maximum transaction amount and so forth. |
|
The validator and the mobile phone establish a secure session in which each side is dynamically authenticated (see Offline Authentication and Data for Offline Authentication). |
|
Within the secure session that mobile phone app and the validator exchange data. The validator gets the IOU QR data. The mobile hone app gets enough data to identify the transport operator, the entry gate, the station, the route and so forth. |
|
The validator sends the IOU QR data to the ticket system, which should be the tier 2 and 3 of the AFCS. |
|
The validator makes sure that the IOU QR data is applicable for the potential route and transport mode the passenger may take. For instance, if the QR data is only valid for Jeepneys in Manila, it would be rejected on a provincial bus route or at the automated gate of the underground lines. The QR data may also contain a maximum authorized amount. The sendig QR Provider will only settle up the maximum amount. It would be the responsibility of the AFCS to ensure the final fare amount does not exceed the maximum authorized amount, or that the difference is settled some other way. |
|
Depending on the result of all the checks, the validator will grant or deny entry. |
|
The validator sends the entry transaction record to the AFCS and the AFCS sends the same record to the sending QR provider. |
|
The passenger mobile phone app has already received the result of the transaction from the validator and shows the QR code as in-use to indicate that the code was successfully used to start the journey. |
|
The passenger mobile phone app sends the entry transaction results to the sending QR provider who can reconcile the information with the records received from the AFCS. Depending on the frequency at which the AFCS will provide entry record information, the reconciliation can be more or less useful for risk management purposes. |
The NFC-QR Exit Transaction Flow
|
The validator and the mobile phone establish a secure session in which each side is dynamically authenticated (see Offline Authentication and Data for Offline Authentication). |
|
The Mobile Phone provides the QR code marked as "IN USE" and the data identifying the point of entry. |
|
The validator sends the data including the id of the exit gate, the station, the route, the transport operator and so forth. |
|
The validator confirms to the nobile phone whether exit was granted and opens the gate or keeps it closed. |
|
Validator sends the data received from the Mobile Phone and the additional location data to the AFCS, which will use it to reconcile the payment from the QR issuer. |
|
The Mobile Phone can now mark the QR code as invalidated. It cannot be used anymore. |
|
The QR issuer provides the entry and exit data and requests the AFCS to calculate the final fare amount. The fare amount will then be send to the AFCS via the usual channels that are used for any other QR payment. |
The IOU QR Data
The name IOU comes from the term "I owe you", and in connection with QR it signifies the nature of the QR data as a promise to pay later rather than the payment itself. It does not even include the amount to be paid. Instead, the QR data simply tells the AFCS that a particular sender QR provider is on the hook for whatever the final fare amount will be.
The IOU-QR contains the following data:
-
Data necessary for settlement.
This data only tells the AFCS which sending QR provider will be liable for the final fare for the trip. It does not contain data that can be linked to the passenger over multiple transactions.
There may be a reference number (aka token) that the sending QR provider could include in the data, but strictly speaking, even that would not be necessary. After all, the sending QR provider is the one who created the QR data in the first place, and they therefore know exactly which customer it was for.
-
Data necessary for offline authentication
Offline authentication is always based on public/private key cryptography. The mobile app will provide the public key and a certificate from a trusted certificate authority which vouches for the authenticity of the public key. The validator already has in its possession the public key of a root certificate authority, which allows it to validate the certificate provided by the mobile phone.
The validator and mobile phone can now exchange challenges and challenge responses that prove both sides are present and authentic.
-
Data necessary for matching entry and exit records.
This is probably the most challenging design decision in the whole system, as the need for privacy and anonymity has to be balanced with the need for data that supports settlement and reconciliation of transaction data. I have witten about here (2).
-
Data necessary for offline risk management.
It is not strictly necessary, but the sending QR provider could limit the use of their payment instrument to certain modes of transport, to certain geographical areas or even specific transport operators. The QCAT standard (3) contains a number of examples for data that could be included.
Offline Authentication
The sender-centric NFC-QR transaction flow described here depends on the authentication of the validator and the mobile phone. Without having positive confirmation that the NFC-QR data was used at a genuine validator, sending money to the receiving QR provider identified in entry and exit transactions would be risky.
In a normal retail transaction in which both terminal and mobile phones are connected to their resective QR providers in real-time, this is not an issue. But when the validator is offline, there is no positive handshake at the backend between sending and receiving QR provider. Without offline authentication of the validator, the system would be vulnerable to man-in-the-middle and redirection attacks.
Many fraud modus-operandi can be prevented by transaction data validation, but offline authentication of the validator would be much more future-proof as it does not require a constant chase after the latest fraud methods.
Using symmetric key cryptography would be a recipe for a key management disaster. Offline stored valued cards traditionally use Tripe-DES or AES, which requires distribution of so-called SAM-chips to all acceptance terminals and validators. For a single issuer of such cards it’s barely manageable. For an interoperable system it is near impossible.
This means mobile phone and validator should use asymmetric cryptography to authenticate each other.
Unfortunately, the EMV transaction flow does not include the authentication of the terminal. There is only an online authentication based on symmetric (i.e.,AES) encryption algorithms.
One solution could be to combine the exchange of PKI certificates with the mutual authentication similar to the NXP© algorithm implemented in DesFire© cards.
The basic flow is more or less the same with some additional features that address specific attacks, for instance, CDA as an extension of DDA in EMV.
-
Passenger device and validator exchange PKI certificates that contain their respective public key and a signature from a certification authority.
-
Each side uses their trusted certificate authority chain to validate the authenticity of the other side’s public key.
-
Mobile phone and validator create a session by exchanging cryptograms based on random challenges, which proves that each side is in possession of the private key linked to the public key exchanged earlier.
Reconciliation and Settlement
In an ideal system, the transport operator or the receiving QR provider do not get any information that would allow them to link entry and exit.
However, because the transport operator does not know which exit transaction belongs to which entry transaction, reconciliation would be challenging as the transport operator would have to trust the sending QR provider and the fare calculation service.
However, each entry and each exit record could contain a unique reference ID provided by the QR issuer. This way, the AFCS can at least make sure that all records that have been recorded are included in a settlement transaction.
Matching entry and Exit Records
I have written about the problem of matching entry and exit records for QR code tickets here (2).
Given the above, there are two issues that need to be resolved:
-
How can we ensure privacy and anonymity when transport operator, AFCS provider and other third parties have access to the ticketing data?
The creators of an AFCS system need to decide how much anonymity they want their system to provide by design.
The highest level of anonymity would prevent anybody from finding out what trip a customer has taken, even if they know when and where the customer entered the transport system. One way to achieve this would be to leave the matching of entry and exit record to the sending QR provider.
The transport operator and their service providers would only know when and how many people have entered the transport system and how many passengers have exited it. Depending on how the fare matrix is designed, it may be impossible to fully reconcile the money received from all the sending QR providers with the transaction data available on the transport operator side.
On the other hand, it is perfectly possible to make sure that multiple trips by the same passenger cannot be linked to the same person or the same fare medium.
Of course, this only applies to the transport operator side. The sending QR provider has all the information, including time, origin and destination of every trip. To achieve a modicrum of privacy, we would have to resort to data retention rules.
As soon as the fare has been calculated and the dispute-time-limits have expired, the trip data can be removed, maybe after sending Statement of Account to the passenger.
There is one more option. We could let the mobile phone app retrieve the final fare. The Sending QR provider only gets a "merchant account" and an amount, very similar to a standard retail transaction. The AFCS only knows that there has been an entry and exit transaction by a passenger with an eWallet from provider X, but they do not know which entry is matched with which exit. A reference number might be given to the validator, which would somewhat reduce anonymity, but probably to an acceptable degree. -
How can the QR data be designed to include a unique identifier that is the same for entry and exit transaction when the passenger creates new QR codes for the exit transaction?
This is the easier problem to solve because validator and passenger mobile phone exchange data on entry. Therefore, the mobile phone and the sending QR provider know which ticket is currently in use. The QR data currently in use can then be shown on exit.
Traditional QR ticketing systems struggle with tickets that were created but never used or that were used but cannot be found in the settlement data, or when multiple QR tickets are used for entry and exit transaction.
No Stop Lists (aka Blacklist) Needed!
Traditional account-based systems assume tha the customer payment media does not have a connection to the issuer system. Therefore, the system requires issuers to distribute lists of payment media that should be rejected by the validator, and the validator needs access to an up-to-date stop list.
In our system, the decision to exclude an account from the ticketing system is made on the sending side, which is also the side that generates the QR code. Since we work on the assumption that the customer phone must be online, there is no reason to maintain a stop list on the receiving side. The sending side simply stops generating QR codes.
Even if the system somehow supports offline QR code generation inside secure execution environments on the phone, there would be controls that allow the sending QR provider to set limits or disable the offline processing altogether.
Terms and Definitions
| IOU-QR |
"I owe you" QR data with a promise to pay the final fare. |
| Sending QR Provider |
Payment provider holding the account of the payer, i.e., customer or passenger. Money will be sent by this payment provider to the receiving QR provider. I am using this term to avoid the old-fashioned term issuer, which is associated with the issuance of physical cards. |
| Receiving QR Provider |
Payment Provider holding the account of the payee, i.e., merchant or transport operator. I am using this term to avoid the term acquirer which is associated with financial institutions that are members of one of the traditional payment schemes. |
| AFCS |
Automated Fare Collection System, used as a shortcut for whatever entity is in charge of conducting the ticketing transactions and settlement of fares. |
| NFC |
Near Field Communication. A set of specifications that standardize the exchange of data using electro-magnetic fields. |
References
(1) I. Noka, “QR Crossborder Payments in Asia.” AFCS Blog, Apr. 2026, Accessed: Jul. 09, 2026. [Online]. Available: https://afcsblog.ingonoka.com/post/qr-cross-border-how-difficult/.
(2) I. Noka, “Account-Based QR Ticketing - How to Match QR Entry and Exit Records.” AFCS Blog, Jun. 2026, Accessed: Jul. 25, 2026. [Online]. Available: https://afcsblog.ingonoka.com/post/account-based-ticket-matching/.
(3) AF Payments Inc. and I. Noka, “QCAT QR Ticketing Standard.” https://github.com/afpayments/QCAT_QR_TICKETING_STANDARD , Aug. 2022, Accessed: May 16, 2026. [Online].
Copyright Sources
OpenClipart, “NFC tag.” https://freesvg.org/nfc-tag , Jul. 2026, Accessed: Jul. 12, 2026. [Online].