QR and Fare Collection - Online or Offline?
A giant leap for Japan, but a step backwards for the AFCS industry? (1)
That was the question that popped into my head when I read the news that JR East is planning to replace magnetic stripe tickets with QR codes in 2027. If the images associated with this announcement are to be believed, then Japanese railway passengers can look forward to printed QR paper tickets, no less!
I have no doubt that as long as Japan remains a low-crime, high-trust society, this will work as well as you would expect from Japan and especially from its railway operators.
Furthermore, this looks like a re-paid proprietary QR ticketing solution, which is easier to design and operate than an open system that combines re-paid with out-paid tickets.
The Department of Transport (DOTR) of the Philippines, in their preliminary statements regarding a national AFCS concession, left no doubt that any national AFCS system must be open, interoperable and ubiquitous.
In my article, I am trying to understand the issues that may arise from the use of QR codes for ticketing in high-traffic mass transit systems, such as the light rail systems in Manila.
I will leave the solutions that could address some or even all of the problems to a future post.
What does Online and Offline mean for QR payments
In the legacy payment systems, only the point of sale terminal could have a network connection. Therefore, whether the transaction takes place without or without an online real-time connection to the issuer depended entirely on the acceptance device.
In QR payments, we usually have networked devices on both sides of the transaction. Leaving paper tickets aside for a moment, the payer would have a mobile phone with a payment app that only works when there is a realtime connection to the payer provider. The payee device could be a dedicated terminal or a mobile phone as well.
In either case it would be connected to the payee provider. However, even if it is connected, there may not be enough time to wait for a response from the payer provider.
Bringing it all together we could classify QR system along the following parameters:
-
Do the payer and payee device have online connections?
-
How is the debit of the fare amount from the payer’s account authorized?
-
How is the credit of the fare amount to the payee’s account confirmed?
Payer |
Payee |
||
|---|---|---|---|
Device Connection |
Debit Authorization |
Device Connection |
Credit Confirmation |
Online (Mobile) |
Realtime |
Offline |
Batch |
Online |
Delayed |
||
Realtime |
|||
Offline (Paper) |
Pre-approved or Prepaid |
Offline |
Batch |
Online |
Delayed |
||
Realtime |
|||
Offline (Mobile) |
Either taken out of a secure pre-approved amount on the device or unauthorized |
Offline |
Batch |
Online |
Delayed |
||
Realtime |
|||
Another dimension to look at would be the authentication of the QR code data. Where is the QR code signature created and who is verifying the signature?
| Fare Media | Signature Creation | Risk | Signature Verification | Risk |
|---|---|---|---|---|
Mobile |
Online1 |
QR code refresh requires constant connectivity of the passenger device |
Online2 |
Key Management entirely in the backend. Breaks down when network is unreliable |
Offline4 |
Key Management has to distribute public keys to all gates and validation terminals and ensure no fraudulent keys are introduced |
|||
Offline3 |
Would require distribution of secure keys and certificates to all customer devices. Securiyt deoends entirely on the mobile phone secure processing environment |
Online2 |
See above |
|
Offline4 |
see above |
|||
Paper |
Offline |
Signature generation may be online at ticket creation, but at validation time the ticket is completely static |
Online2 |
Validator cannot distinguish a copy. There is no refresh. One-time use check with QR issuer possible. |
Offline4 |
One-time use can be maaged by a combination of ticket data and distributed databases |
1 Payer QR Provider (e.g. eWallet)
2 Payee QR Provider (e.g. AFCS Provider
3 Secure Processing Environment on the phone
4 Gates and Validators
QR Payments designed for Online Realtime
The nature of account-to-account payments based on QR code data exchange is not only that the payment amount leaves the payer’s account and arrives at the payee account almost immediately. Even the use of QR codes and camera scans does not define what is commonly referred to as QR Payments.
Instead, the unique nature of QR code account-to-account payments is based on the realtime online connections between payee and payer to their respective QR payment provider (aka backend) systems.
It is also characterized by the complete lack of trust between payer and payee. I use the word "trust" in its technical sense here.
When one of the parties scans the QR code presented by the other party, this QR code does not convey any proof that the other party is who they claim to be.
However, each party trusts their respective QR payment provider by virtue of trusting that the mobile phone application of that provider is not compromised and represents a trusted link to the provider.
In any QR payment scheme there is also a trust relationship between QR payment providers. Any payment provider will trust that a payment request or a push payment, is truly coming from a particular account holder as long as the request is coming from another trusted payment provider in the system.
For instance, in a push payment, the payer will use the trusted mobile phone app to send a payment instruction to their payment provider. The payment provider will deduct the money from the payer account and send a payment instruction to the payment provider of the payee. The payee’s provider will credit the amount to the payee account and inform the payee via their own trusted mobile phone app that a payment was made. The payee, who trusts the mobile phone app will then be satisfied that a payment has been made.
The payee does not need to communicate with the payer mobile phone app to be satisfied that the payment had been successful.
Everything changes when we attempt to use QR code scans for offline transactions.
Offline QR Payments
I am using the term offline payments for transactions in which the payer has a mobile phone application that is connected in realtime to the Payer’s QR payment provider and the payee has a device that can scan the QR code but does not have an online connection, either temporarily or by design, or the nature of the transaction does not allow enough time for the payment confirmation to arrive.
On the payer side, the offline transaction consists of more than just generating a QR code. The idea is that the payer QR provider takes the payment amount out of the payer’s account before creating the QR code. Only the amount dedicated to the transaction can be retrieved by the payee. In this regard it works a bit like a banker’s draft.
First, offline QR payments would always be payer-presented transactions.
To see this, just imagine how an offline payee-presented transaction would happen. The payer would scan the QR code and walk away. The payee has nothing but their own generated QR code. They would not even know whether the payer has scanned the QR code. They would definitely not know whether the payer has any intention to use the scanned QR code data to affect the money transfer at some later time.
One could argue that the payee could just wait for the payment confirmation from their own provider. That would work in some retail situation, but in general it would be difficult to match the payer with the payment. In unattended payments it might even be impossible to do reliably.
An exception to the rule are some offline payments that work the same as handing over my bank details to somebody so that they can pay me later. In this situation, the payee knows the payer and has options if the payment does not arrive. In a retail situation or in a fare collection system, this is usually not the case.
Online QR and Fare Collection
Online realtime QR payments can be incredible fast. I remember my excitement when I used my pair presented QR code at Starbucks for the first time. The payment was near instantaneous.
One could ask, if Starbucks can do it, why couldn’t we design a fare collection system that insists on realtime online authorization for every entry or exit transaction?
The answer is "may be we could", but there are number of problems with such an approach.
In order to be fast and reliable enough, each access gate would need to be connected more or less directly to the QR provider. That would create a spider web of connections that is hard to manage, and it would make integration of new QR payment providers incredibly complicated.
The connection would need to have a near 100% uptime. Even a few minutes of connection loss or slow down during rush hour would create catastrophic backlogs.
Brief periods of network deteriorations could be managed by temporary offline operation. Longer down times, however, are more common then one would think.
As usual, we could find technical solutions for most of these problems, but if the industry has no appetite or understanding of risk management, i.e., insists on risk avoidance rather than risk management, any operator of such a system would be in for a world of hurt.
Risk of offline QR Payments
This is a random collection of potential attack vectors. I have no doubt that the actual implementation and first-hand experience will give attackers plenty of room to come up with new tricks.
Also, some of my imaginary attacks are irrelevant or unlikely to occur in practice.
- Multiple payees submit the same QR code to the QR payment provider
-
Once the QR code was scanned and validated it does not change anymore. Multiple payees have plenty of time to share the QR code and submit payment requests to their provider. If multiple payment provider are involved on the payee side, the duplicates can only be detected at the payer side. The payer QR payment provider then has the problem to decide which request is the correct one. The payer does not receive anything from the payee at the time of generating the QR code. The QR code and therefore the payment request do not contain information what the correct payee identifier might be.
- Fraudulent payer mirrors the QR codes from another payer’s phone
-
A fraudster may mirror the screen of a genuine payer, thus showing genuine QR codes to the payee. Due to the constant streaming of QR codes from the genuine payer’s phone, refreshing the QR code in regular intervals cannot defeat this attack.
The fraudster may either collude with the genuine payer or hack into the genuine payer’s phone. It is also possible that a stolen phone is used to stream the QR codes via another phone with a video streaming application.
This is the QR variant of the old "man-in-the-middle" attack.
- The payee manipulates the payment request by inserting a transaction time that fits the QR code expiry period
-
The validity of a QR code is based on the expiry time and the transaction time. QR codes should only be accepted if the transaction takes place before the QR code expires. Once the QR code is stored on the acceptance side it is not linked to the transaction time anymore. It would be easy to change the transaction time in the settlement or delayed authorization record to a time that fits the QR code expiry time.
As a result, the payee can submit QR codes that have been "harvested" at some other time with or without the collusion of the payer.
Of course the payer payment provider knows that the QR codes was generated by them. But they do not know whether it was used by the payee at the time the payer presented the QR code or at some other time.
- The QR code has been generated by an unauthorized party
-
The EMV customer-presented specification has no provisions for cryptographic signatures. It is therefore easy to generate a QR code without the payer payment provider’s involvement. The payees device is offline and cannot check with their own provider whether there is a pending QR code present on the payer provider system.
- The payer generates a QR code and makes a payment that exceeds the available balance of the payer
-
The payer generates a QR code without providing an amount, so that the payment provider cannot check whether there is enough money on the payer account. Even if the payer provides an amount there is no guarantee that the actual transaction is higher than the amount that might have been set aside by the payee provider. The amount is not part of the EMV customer-presented QR code and therefore not be checked by the payee offline device against the actual transaction amount.
References
(1) Jiji, “JR East to shift from magnetic to QR code tickets in 2027.” https://www.japantimes.co.jp/business/2026/06/09/jr-east-qr-code-tickets/ , Jun. 2026, Accessed: Jul. 07, 2026. [Online].
Copyright Sources
Parts of the thumbnail for this post are taken from (1).