EMV in transit: migration in a nutshell

Written by: Joost Flipse

September 30, 2016 - Three steps to EMV in transit

Most public transport operators still rely on card-centric fare collection systems where the travel rights or funds are stored on the transit card. Thereby faced with challenges not directly in line with their core responsibility, such as: issuance and management of transit-specific travel cards, security issues concerning their specific AFC implementation and deployment and maintenance of a top-up infrastructure. These characteristics of typical AFC schemes are in sharp contrast with the payment world, in particular EMV contactless implementations. Next to that, EMV in transit offers barrier free access for banking customers, stimulating the use of public transport by occasional travelers. While at the same time frequent travelers can couple travel rights to their central transit account associated with their EMV card. For both types of travelers the travel costs can be charged directly to their bank account.

Although many public transport operators might want to offer new forms of fare payment, such as EMV, their current validation devices do not offer such support without upgrading or replacing them. In this blog we show how you can migrate in three steps to a system that can accept many forms of fare payment, including (mobile) EMV bank cards issued by most banks worldwide. The benefit of following these three migration steps is that new fare payment functionality can be offered even before replacing your validation devices.

Step 1: Introduce proxy fare products

As a first step, a proxy fare product is introduced. A proxy fare product is not a real fare product in the sense of a ‘sales package’. Although it is stored on the travel card and the terminals will recognize it as a valid product, it only acts as an identifier for the customer account in the back-end. Consequently, the usage rules stored on the terminals for the proxy product are set to ‘valid everywhere and always’. The pricing rules are set to ‘free travel’. Effectively, this means that the card and the terminals are no longer involved in the fare calculation and payment processes.

Step 2: Central fare calculation and payment

The second step is implementing central fare calculation logic for proxy fare product transactions. Every time the proxy product is used to check in or check out, the system sends a transaction to the back-end, just as it does for any other product (possibly in periodic batches). However, whereas for other products these transactions are mainly used for validating the ticketing process that took place between card and terminal, the transactions for the proxy product are fed into a fare calculation engine. This engine is responsible for determining which account-based fare product must be used and to calculate the travel fare, in the same way as a terminal in a card-centric system does. The fare will be paid from the traveler’s central account which can be topped up using any payment service you wish to support (e.g. PayPal, Bitcoin, cash) or the fare is directly debited to the customer via for instance an on file credit card or direct debit mandate.

In order to be able to process EMV in transit transactions to the traveler’s bank account it is important to be able to authorize those via your acquirer or have a Payment Service Provider (PSP) handle this for you. In the EMV aggregation model the first tap triggers a pre-authorization to reserve a certain amount of funds on the traveler’s bank account. When successful, travels are aggregated by the transit operator for a certain time period or maximum total fare amount, before actually debiting the amount to the bank account.

Step 3: Front end replacement (end of life)

Once all travelers in a card-centric system use the proxy fare product, the system is in principle fully account-based, because terminals and cards are no longer involved in fare calculation and payment. Therefore in the third step, the existing terminals can be replaced by simpler terminals that are less expensive and easier to maintain. Note that the replacement of terminals can be done when they reach their natural end of life; forced replacement or updates are not necessary. Make sure to choose terminals that are EMV certified if you want to accept EMV bank cards. Once all terminals have been replaced, a replacement of the cards can be started too, switching to cards that only have an identification and authentication function. The big benefit of accepting EMV bank cards is that most of your travelers will already been issued one of them by their bank, relieving transit operators from issuing transit specific cards and travelers from carrying an extra card. Furthermore, the fare is directly debited to the customer’s bank account, or at least within the aggregation time window.

Conclusion

We hope to have shown you that migration towards a fare system that supports EMV in transit can be divided in to three structured and manageable steps. With the advantage that the first two steps provide travelers with account based advantages without replacing your current validation devices.

For more information or help on migrating to EMV in transit or central automatic fare collection systems in general please contact us or have a look at our following whitepapers:

“Next generation ticketing – Go central”
“Next generation ticketing – Go open”
“EMV in transit – Issuer implementation guide” 

Disclaimer

These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.