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.
Categories of Mass Transport Systems
To discuss the use of QR codes for automated fare collection, it will be useful to divide mass transport systems into the following categories:
- Category A
-
Mass transport systems with fixed stations in which the paid and unpaid areas are separated. Entry into the paid area is regulated by automated gates that validate tickets or conduct payment transactions. Usually there are many stations, and for most passengers it is not known where they will exit when they enter the station.
Except for some long-distance commuter trains, the vehicles usually do not have pre-assigned seats. Passengers use such systems frequently, often every day. (Examples: subway trains, light rail systems)
The fare will be calculated in real time based on the entry and exit station, which are linked to each other by the ticket or fare medium identifier.
- Category B
-
Mass transport systems with fixed stations that are very similar to the previous category, but where there is no clear separation of paid and unpaid areas. The ticket validation or payment takes place on-board the vehicle. The validator device usually does not have the ability to restrict entry of passengers without a valid ticket or payment instrument. (Examples: trams, city buses, Jeepneys)
- Category C
-
Mass transport systems that have few stations and in which the destination of the passenger is known on entry. The passenger will usually buy a ticket before boarding as there is no tap-in/tap-out type of fare validation or payment available. (Examples: airplanes, long distance trains)
In Category A systems, the rate of passengers passing through an automated gate will be high. For instance, in the light rail systems of Manila, we used to target 30 entries per minute. It is clear that an online realtime account transfer, complete with customer approval and backend confirmation, is not possible. The only realistic option for using QR would be a prepaid ticketing solution, with some limited offline counterfeit prevention. An example of such a solution is the QCAT protocol.
For Category B, more or less the same applies as for category A. However, there is the option of using conductors or "in-flight" ticket payments. Using a conductor somewhat defeats the whole purpose of introducing an automated fare collection system, but the electronic nature of fare collection and ticket validation offers some benefits even with the overhead of a conductor. Solutions such as QCAT would work quite well in such environments, regardless of whether a conductor is present. QR codes may just be used to pay for tickets while on board the vehicle. For all practical purposes, this is similar to pre-paid tickets.
Category C transport systems almost always use pre-paid tickets and boarding passes. The QR code is not part of the payment process. It is only there to simplify the validation of the ticket and the collection of ticket data by electronic validators. QR pre-paid tickets are just like boarding passes that are validated at different points along the journey.
Types of QR Ticketing
- Pre-paid QR code tickets
-
The QR code represents a ticket that was purchased before entering the vehicle or the paid area of the mass transport system.
- On-board ticket sales
-
The eWallet QR code only plays a role in the payment transaction.The customer buys a ticket, usually from a conductor, who has the necessary equipment to accept eWallet payments.The resulting ticket may also have a QR code, this QR code would have the same function as a pre-paid QR code ticket.
- Account-based ticketing (scan-in/out)
-
The eWallet QR code is scanned on entry and exit.The QR code data is used to link entry and exit record to calculate the distance based fare and to initiate a payment transaction.
Pre-paid QR code tickets
The most obvious application of QR codes in automated fare collection systems is to use them for conveying the data of a pre-paid ticket to the ticket validator device.
In this application, the QR code has nothing to do with the payment for the ticket. Instead, the QR code represents the ticket that has been bought online or at the ticketing booth or at a vending machine.
The QR code contains sufficient information for the ticket validation device to grant entry or exit to the passenger presenting the ticket with the QR code on it. Depending on the design of the system, the QR code may just contain a reference ID or, more likely, it will contain information such as the validity time period of the ticket, the allowable trips, potentially the entry and exit stations and so forth.
All the limitations of a QR code based ticket as described in my previous post apply here as well. The biggest problem is the potential for counterfeit and for multiple use of the same ticket. It is also difficult to decide whether the passenger has exceeded the time or route limitations of the ticket.
Let’s address the creation of fake tickets first. If the ticket only contains plain data, it would be very easy to generate a QR code with the desirable data. The validation terminal would have no way to distinguish such a ticket from a ticket that was generated by an authorized ticket issuer.
This type of counterfeiting can be solved by various means:
-
The most obvious and most secure solution is to include a cryptographic signature in the QR code data. The signature would have to be based on public key cryptography, so that the validation terminal can verify the signature without a secret key or an online connection to a validation service.
Due to the limited number of bytes a QR code can carry, the signature needs to be short and therefore will be limited to short keys. This limitation can be somewhat alleviated by using algorithms that utilize shorter keys, for instance, elliptic curves instead of RSA, and by changing keys frequently. Whatever the design, a key compromise cannot be ruled out and the potential impact must be properly mitigated and some amount of loss has to be accepted.
-
It is also possible to maintain a database of tickets which can be consulted by the validation terminal to check whether the presented ticket was created by an authorized ticket issuer. The ticket would need to include a ticket reference number that cannot be guessed easily.
This database of tickets would need to be populated by all ticket issuers and synchronized across all stations and validation terminals. This would introduce a large number of additional interfaces and connections and would only work in Category C systems, with a small number of validation points, relatively small number of ticketing transactions and "plenty" of time to distribute and validate the ticket information.
For the type of counterfeit in which the QR code is copied from a genuine ticket, the above methods will not work. The following risk mitigation methods can reduce such fraudulent ticketing transactions, but will not be able to eradicate them all together.
-
One solution is the "dynamic" QR code. Unfortunately, the term "dynamic" in connection with QR codes is already reserved for QR codes that are transaction specific. Here, I am using it for QR codes that are changing frequently, so that a copied QR code will quickly become invalid. Obviously, this method will only work for QR codes that are presented through a mobile phone. It is not an option for printed tickets. For timing reasons, it may also be necessary, to create a public key hierarchy, so that the ticket seller can generate their own QR codes.
The ticket data will have to carry an expiry time for the QR code and an expiry time for the ticket. The two expiry times are independent of each other. The QR expiry time will change with every new incarnation of the ticket’s QR code, while the ticket expiry period remains unchanged.
-
The validation terminal could also keep a record of all scanned QR code tickets and look up every presented ticket in the database to see whether it has been used already. The problem is to keep a synchronized database of all used tickets across all validation terminals.
This can be overcome by including the entry and exit stations in the QR code data. The QR code ticket will only be valid for an entry at the indicated station, and the passenger must exit at or before the exit station. This way, the system only needs to distribute ticket data to the specific stations and multiple uses of a single ticket can be detected and declined quickly by consulting a station-level database. This can be done fast enough to prevent most counterfeit ticket fraud.
Account-based Ticketing [1]
For the reasons outlined in part 2 of this miniseries, using QR codes for account-based ticketing is tricky.
From other account based ticketing systems, we know that we will have to provide the following features:
-
Offline counterfeit protection
-
Delayed, but timely, authorization
-
Mitigation of the use of lost or stolen ticket media
-
Delayed fare calculation
Let’s look at each in the following sections.
Offline counterfeit protection
As we already know, counterfeit copies of a QR code scannot be distinguished from a genuine QR code. However, we can apply the methods outlined in the previous section.
The problem is that we do not have free rein over the format and content of the QR code.
If we want to use the QR code that is generated by the respective QR-based eWallet, we will have to work with the data that is provided there. Unfortunately, the customer presented QR codes have not been standardized as much as the merchant-presented systems, which have by now transitioned to national standards that are all based on the EMV standards (see (EMVCo, 2020)). Even more unfortunate, the EMV standard for customer presented QR codes is as unimaginative as the proprietary variety.
None of the customer-presented QR codes I have analyzed so far contain any cryptographic signature that could be used to detect fake QR codes. While the EMV customer-presented QR code specification leaves enough flexibility to add such data, the ticketing system would need to be restricted to issuers that have agreed to include the additional data.
To me, it seems unlikely that the standard QR code of eWallets will ever support even a rudimentary support for offline authentication. This is understandable as QR code account-to-account payments happen in the backend, and there is no need for customer and merchant devices to authenticate each other.
|
The lack of offline authentication could enable fraudsters to create account references or customer IDs out of "thin air". Such identifiers would only ever be used once, which means, including such identifiers in the backlist will not stop the next fraudulent transaction. Any ticketing systems that uses QR codes in the manner described here will have to have some way to check in real-time whether an account or customer identifier exists, or even better whether the QR code data was created by a genuine eWallet provider. |
Delayed Authorization
In traditional account based ticketing systems, the gate or validation terminal will collect data from the "card", perform an offline authentication, check the blacklist and let the customer through or not as the case may be.
The data is then used to send an authorization request to the issuer (via service provider, acquirer, and so forth). Finally, the result of the authorization is used as a basis for a settlement transaction, or to create an entry in the backlist in case of a decline.
Most eWallets work differently. When the customer creates a QR code in their eWallet application, a pending transaction approval is created in the backend system. The merchant takes the data from the QR code, which contains a transaction or customer reference, and asks the eWallet backend whether a pending approval transaction is present for this reference number. The assumption is that the merchant will send the request almost in real-time. If no authorization request is received within a few minutes, the pending authorization will expire.
The merchant’s authorization request also contains the transaction amount, which the eWallet provider would check against transaction limits and wallet balance before sending back an approval or decline.
For ticketing systems, this means on entry, the validation terminal has to have a reliable and fast online connection in order to send an authorization request as soon as the QR code is scanned. The validation terminal also needs to include an amount in the authorization request, which could be the smallest possible fare or the maximum fare, depending on the policy of the transport operator. In case of the maximum possible fare, the eWallet scheme would need to be able to perform partial refunds, which is probably not commonly available.
Depending on the throughput requirements, an authorization request will likely only be completed after the customer has already passed through the gate or left the validation terminal. If the authorization request was declined, it may be possible to distribute this information to all possible exit terminals or stations, so that the passenger can be asked for an alternative payment method on exit.
Many eWallet systems seem to offer merchants the ability to check whether the balance in the customer eWallet is sufficient for a particular amount. This functionality could be used to check whether the customer has enough funds to cover the maximum possible fare. Instead of taking the maximum possible fare out of the account, the gate or validation terminal may then deny entry if the balance is not sufficient.
|
My experience is that customers who know the fare to their destination will be rather indignant if they are denied entry even so their eWallet contains the necessary balance to their destination. |
The "scan-out" transaction is a bit more difficult. First, the customer would need to generate yet another QR code, and it is necessary for the QR code to contain an eWallet (or customer) identifier that allows the validation terminal to link entry and exit station. With the knowledge of entry and exit station, the validation terminal can then calculate the fare. Of course, the fare needs to be calculated fast enough, so that the validation terminal can send an authorization request before the pending backend transaction of the QR code expires.
A better, and also more realistic, option would be to use "account on file" transactions for the final settlement. Instead of sending an authorization request in real-time, the AFCS system would use the QR code data to request payment at a later time. Ideally, the QR code data from entry and exit scan can be used as an implicit authorization by the customer to create better fraud protection, for instance, by checking against a log of expired QR codes.
Blacklist management
As explained before, there is usually no offline authentication available for payment QR codes. Fraudsters may therefore create their own account numbers or reference identifiers, which cannot be distinguished from identifiers created by the eWallet provider. That is why putting account numbers that do not actually exist on the backlist will not prevent further fraud with entirely fake accounts.
However, the system should keep track of genuine accounts that have outstanding settlement transactions, for example due to insufficient balance. If presented on entry, the passenger could be asked to settle previous transactions first, before being allowed to use the eWallet QR code for another transaction.
Delayed Fare Calculation
In account-based ticketing systems, the fare is calculated based on entry and exit records. The two records are linked via a unique customer or account reference number. For traditional card systems, this is not a problem, as the card (physical or on mobile phones) will always include an account number or a token that can be linked to the card number. The customer, does not have to create a new "virtual" card every time they use their card.
For QR-based eWallets, the customer generates a new QR code every time they intend to use their wallet for a payment transaction. As long as this QR code contains the same account reference number, the entry and exit records can be linked based on that number.
|
|
In my personal view, QR-based eWallets should not include any account or customer identifying information into the QR code data. There is no need for the merchant or the QR acceptor companies to have this information. The QR code should only contain a one-time reference number that links the QR code to a pending authorization record on the eWallet provider’s backend. While I doubt that my view will prevail in practical applications, if it does, the linkage between entry and exit record would have to be shifted to the issuing side, as only the issuer can link different transaction reference numbers to a single account or customer. |
Discounts, Passes, Products, Concessionary Tickets
Account-based ticketing works well for standard fares. However, as the "fare medium" is not part of the AFCS system, it usually does not contain information about special discounts, products, passes and so forth.
For pre-paid tickets that is not a problem, as the QR code on the ticket is generated by the AFCS system and during the ticket sales process (online, self-service or attended) the fare can be discounted as desired. But even then, products such as multi-trip tickets, which require a ticket to be valid for a longer period of time, measures such as dynamic QR codes and cryptographic signatures are indispensable.
Image Reference
Commons, W. (2022). File:Grönt sl kort.jpg — Wikimedia Commons, the free media repository. https://commons.wikimedia.org/w/index.php?title=File:Gr%C3%B6nt_sl_kort.jpg&oldid=664838799
