The story of one lonely and offline validator in account-based ticketing

Today we will dive into Kentkart’s state-of-art technologies. We have already touched upon what account-based ticketing is. So this time, we will answer the number one question we receive from our clients and industry partners – continue reading, and you will find out which one.

The main distinction of Account-based Ticketing

To set the stage, let us first point out the difference between the old-fashioned card-based ticketing (CBT) and the modern account-based ticketing (ABT) systems. All relevant data like card balance or passenger fare type in CBT is stored on transport cards. This means that validators should read the information, calculate the fare, and then decide on whether to allow passengers on board or not.

In ABT, however, the data is shifted to the cloud and linked to passenger accounts. So everything that a transport card (or any other payment media) now holds is just a single account ID. That leaves validators with a simple task – to share the ID with the cloud and wait a couple of seconds for the answer while everything is calculated online in the back office. Thanks to ABT, the system is always up-to-date, super customizable, and open to any third-party integration.

This raises an important question: how do validators allow passengers on board if the connection gets lost?

Sometimes not everything goes as planned. The internet is not an exception – there are places in cities with low coverage, or just days with bad weather conditions (typhoons, blizzards, or heavy rainfalls), which affect the connection. So every ABT system has to be ready for offline work.

Our answer here is effective offline list management. kentkart uses its status lists with predetermined sets of rules, which are crucial for risk minimization. The lists are constantly shared among all online validators so that devices have their plan B in case the connection is lost. It requires advanced infrastructure able to support the management of the lists on the server side, as well as its quick distribution. Here are some examples of data kept:

• – Account ID
• – Available balance
• – Blacklist condition
• – Risk level
• – Ticket type
• – Passenger type
• – Expire Date
• – Tap limits for trip

To give an example, transit operators can limit risky accounts to only one tap on the same bus. Finally, when validators go back online, they immediately share all the collected information with the cloud, and the system gets fully synchronized. As a result of such effective offline list management, account-based ticketing provides cities with the latest and greatest technologies while still remaining low-risk.