Making ways for contactless ticketing in IR

Indian Railways, keeping in view the ongoing COVID-19 pandemic, will adopt the facility of contactless ticketing similar to facilities at airports with QR code-enabled tickets. The QR code-enabled tickets will be scanned on handheld devices and mobile phones at railway stations and on trains. Last month, an automatic QR code-based ticket scanning system was introduced by Indian Railways at the Prayagraj junction railway station, in a first-of-its-kind initiative. The contactless ticketing system is believed to help passengers as well as railway staff to prevent the spread of novel coronavirus. The contactless QR code-based ticket scanning system will work:

• CRIS has rolled out an application, for contactless ticket checking of reserved tickets, covering all the zones of Indian Railways to display PRS ticket details as QR Code.
• Once the tickets are booked, an SMS will be sent to the mobile number of the passenger, containing the URL of the QR code.
• During the station entry or during the checking of the train ticket, passengers will have to click on the QR code URL available on his or her SMS.
• After doing this, the QR code of the reserved ticket will be displayed on the mobile browser of the passenger.
• The TTE will scan the displayed QR code of the reserved ticket on the passenger’s mobile browser, through his or her mobile device having the capability of scanning the QR code. According to Indian Railways, any free QR code scanner mobile application available in iOS App Store or Google Play store such as QR and Barcode Scanner, QR Code reader, etc. can be used for this purpose.
• Moreover, the HHT application is also capable of scanning this QR code and it will fill the PNR details in the application automatically for TTE for turn up action. Currently, the facility is live and SMS with links for generating QR code is being sent on the provided mobile number.

The ongoing COVID-19 pandemic has completely changed how we go about our lives nowadays. It has also altered how businesses operate, taking precautions to curb the spread and stick to delivering goods. The Indian Railways has gone back and forth in restarting travel over the past couple of months. And now, it is taking cues from the advanced air travel system to introduce a contactless ticketing system at railway stations.

The railways are planning to issue QR code-enabled tickets, which can easily be scanned at the station or on the train to verify your identity. The train conductor can either use a handheld device or rely on a mobile phone to scan these tickets, further simplifying the whole process. This also applies to platform tickets and not just train tickets.

QR Ticketing System

The QR Ticketing System for Transit Operators is an integrated system of using QR Codes as prepaid tickets to avail mainly transit services of all modern operators like Metro, Bus, Rental Cars, Rail, Flight, etc. This part – QR Ticketing System Implementation Guidelines provides some valuable tips and insights to implementing the QR Ticketing System and integrating it with AFC systems. An annexure, addressing some of the most ‘frequently asked questions’ is also provided here.

Basic Implementation

The basic implementation of a QR Ticketing system involves few important steps outlined as under :

• Ticket Purchase Mobile and Webclient Application
• Ticket Office Machine (TOM) Application
• Ticket Validation in QR Ticketing System
• Validating Terminal and AFC System Updates
• Simple Customer Care Application Integrated with TG
• Implementing Products and Passes in QR Ticketing System

Ticket Purchase Mobile and Webclient Application

This is the customer face of the QR Ticketing System. Customers must be able to use an App (like a Mobile or Webclient App) to buy Bus or Metro journey tickets. The Apps can also provide facility to buy tickets for Rail or Air journeys. Some of the salient features that every App must support are :

1. An UI that is integrated with the QR Ticket Generator (TG) which, in turn, is integrated with PTO’s AFC. The App Provider may be any third-party commercial application but integration with TG is mandatory. CDAC’s Travel Mozo App is one such example of a third-party system that is easily integrable with PTO’s AFC via CDAC TG Services.
2. The App must follow the QR Specifications to generate QR Tickets in the typical QR Ticketing System format.
3. Due to constraints of security and other services like ‘location’, App must ask for the user’s permission.

The minimum set of Access Permission can be detailed as per table below :

Service Parameter	Description
NFC (Near-field communication)	It totally depends on the PTO station center if they need it for communication with the device to scan a QR Ticket. NFC is available only on some high-end mobile devices.
Internet Connectivity (Mobile Data & WiFi )	Device must have internet connectivity for booking a ticket. Internet connectivity may be either mobile data or WiFi.
Bluetooth connectivity	It totally depends on the PTO station center if they need it for communication with the device to scan a QR Ticket. Application will ask for this.
Live Geo-Location	The QR Ticketing System can optionally maintain the actual physical latitude and longitude of the device at the time a ticket is being purchased. This is a precautionary measure that the PTO may enforce in order to prevent misuse or fraudulent tickets. Furthermore, in case of booking a cab or rickshaw or for tracking the device, the app needs the live location of device.
Contact number	For account security verification like OTP app needs phone number of user.
SMS and Phone call	In case of cab and rickshaw, app may need to call the driver for getting the information about booked rides. SMS may be required for OTP and other purposes.
Push Notification (Message Notification)	Device must allow this for getting the notifications like:  The day of journey notification When user uses the QR Ticket, the real-time transit update should be sent via push notification and the App must update the information in the Ticket History accordinglyTo send QR Ticket validity (Expiry time of ticket) alert

Ticket Office Machine (TOM) Application

Issuance of Paper QR Tickets intended to replace the tokens used in Metro station. So all Metro operators must provide an Application in their Ticket Office premises that can facilitate such purchases. These applications may be attended or unattended (Ticket Vending Machines). TOM applications must also have the same integration with the PTO’s own AFC. 

TOM – Workflow and Design: 

There are mainly 4 components to the TOM Application.

1. Super Admin – This is only required for administration purposes. If the PTO requests the TOM APP Provider to check some problem, the App Providers DB and Application Administrator can intervene and look into the issue. The Super Admin console may also be used by the PTO to create and manage the Executive/Personnel handling the requests for ticket.
2. PTO-specific TOM application tailor made for PTO’s needs.
3. Ticket Issuing Person / Teller – Handles day to day ticket issuing work
4. Station / Depot specific TOM Application Engine
5. Ticket Generator (TG) – The interface with the TG is almost exactly the same as the Mobile APP except that there is no Payment Service Provider Interface required. The PTO collects the Ticket fare using its own mechanisms like Cash, Card, etc. The TG may be local to the PTO and also operated by the PTO itself. But it can also be provided by a third-party service provider. In that case the TG Provider should settle the service charges for all the Paper tickets issued through it. 

Ticket Validation in QR Ticketing System

TRM or Transit Rules Management is normally PTO-specific that implements the PTO’s business rules pertaining to usage of tickets purchased by the customers. For QR Code Tickets, some common validations that shall be necessary to perform are as follows. Please note that these points are only a set of Recommended Rules.

1. The Ticket Serial Number is valid
2. Activation Date and Validity time of journey information is correct
3. Entry/Exit station information is correct.
4. Please note that some PTOs allow entry anywhere between the Source and Destination stations. Similarly, the commuter maybe allowed to deboard or exit at any station that falls before the actual Destination station specified on the QR Ticket.

Validating Terminal and AFC System Updates

After a QR Ticket is validated at a terminal the process of updating transit information in the AFC Systems – its protocol, communication mode, architecture, etc. – is actually not within the scope of the QR Ticketing System specifications. For the sake of illustrating a real situation, we shall assume that the target AFC System is an NCMC-compliant one. 

Flow of transit information into NCMC-compliant AFC:

• When QR is presented at the validation terminal, terminal performs required validation checks and generates QR transit file which is then sent to the AFC.
• Any type of transit file generated at the terminal shall be divided into two blocks – Common Transit Data Block and Variable Transit Data Block. The Common block consists of elements which are common for all media types (viz. NCMC, Cash, Token and QR) while the Variable block consists of only media-specific information.
• Each data block is further split into two sub-blocks. First sub-block consists of fixed set of data elements and second sub-block consists of operator defined data which may be decided by operator according to requirements.
• The source of some data elements in the Variable Data Block is the QR Payload present in the ticket. Other elements are generated by the terminal itself. 

Simple Customer Care Application Integrated with TG

Customer Care is a very important feature for all transit service providers. In order to provide customers top quality service and a value for their money PTOs usually employ many Customer Care personnel. To aid the Customer Care executives in their job, a good Customer Care application is a necessary requirement. In case of the QR Ticketing System the QR ticket that the customer presents at a validation gate or terminal may run into some problem. A ticket may fail validation for a variety of reasons – genuine or due to some glitch. In all such cases, the commuter can approach the Customer Care centre. The purpose of the Customer Care application is to provide the operator with enough information about the ticket based on which the operator can take the correct decision to alleviate the problem faced by the customer. A simple Customer Care application must support at least the following minimum requirements:

1. An Application that is integrated with a QR code scanning device. These devices are readily available and are usually referred to as HID – Human Interface Device. For simplicity, it is recommended to use a USB-based HID that works as a Keyboard Emulator. That way when the operator places the cursor on a Standard Input text field and scans the QR – emulated keystrokes – which is the actual QR payload – becomes available to the Customer Care application for further validation.
2. The QR payload can then validated and displayed on the Customer Care App Form.
3. Based on the validation, the Customer Care operator takes the decision. Decisions are entirely the PTOs own business rules and policies.
4. It is quite possible that the Customer Care App to have the option to print a duplicate QR ticket.
5. Interface of the customer care should obviously be directly interfaced to the correct Ticket Generator. Since one QR ticket can be issued by one and only one TG, the ticket validation of the issued ticket must land at the same TG.

Implementing Products and Passes in QR Ticketing System

Trip Passes are an integral part of any transit application. PTOs of all types – Bus or Metro operators – often issue many passes like – Senior Citizen Pass, Student Pass, Day Pass, Monthly Pass, etc. In the QR Ticketing System, the Product ID parameter is used to populate Passes. It is sent as a Policy Update Request.

Example of a QR Ticket using a QR Pass Ticket (Monthly Pass for Metro): 

The ticket issuing Application must provide only one QR Ticket that should contain the information for a Pass. Essentially, the following criteria are of importance –

1. An App that must provide the option to User to buy Passes. Passes are PTO-specific and cannot be used for inter-operator journeys unless some operators decide to issue joint passes.
2. If a user has already bought a Pass and the validity of the pass has expired, then it is desirable for the App to disable the ticket on the Phone so that it cannot be presented. In order for the TG to determine the current status of passes, PTO’s AFC shall share relevant details like transaction amount (To update remaining balance in Pass), trip count (To update remaining trips in case of trip based Pass) etc. with TG.
3. A Global “All Access” Source and Destination ID in the Policy DB that would imply a ‘Pass’ QR Ticket. The Station Code for “All Access” can be fixed as 255 or ‘FF’ Hex.
4. Validity Period = 43200 minutes. One QR Pass Ticket is for a maximum validity of 45 days only.
5. The User must pay up at least the minimum amount specified by the PTO for the Pass. This is also a Policy DB parameter as shown in the figure above. The user cannot purchase a QR Pass Ticket without paying up this minimum amount.
6. For all types of Passes, the APP must provide a facility to query the ‘Query Balance’. Actually the TG must send the updated QR Payload reflecting the actual available balance on the Ticket_Fare field.
7. After the Ticket (or Pass) is purchased, like any other QR Ticket, the TG sends the ‘Purchase QR’ information to the AFC. The AFC must notify all the terminals as a Start of Day (SOD) object the Passes information. These SOD objects must contain the ‘Ticket Serial Number’ of the QR the ‘Available Balance Amount’ and the ‘Minimum Required Balance’.
8. When a Pass is presented on the terminal, the TRM Validation Rules must ensure that the Product ID is correct (= 5 in our example) and the ‘Balance Amount’ on the scanned QR (this is the same as the Ticket_Fare value) and the data available on terminal must match. Then the remainder amount must also be at least equal to the ‘Minimum Required Balance’. As a side note, the APP must also send notifications to user when the Minimum Balance Amount is about to exhaust so that the user can recharge the pass.
9. If the ‘Minimum Balance Amount’ is not enough, then – whether the commuter oversteps or not – all the Exit terminals should deny the commuter to pass through and direct him to go to Customer Care. Any additional due amount can be recovered there and then.
10. Since the ‘Entry-Exit’ pairs of a ‘Pass’ journey would always be available with the AFC, it must update the balance in that Pass accordingly. These updated balances (along with the Tkt_Sl_No) must be resent to the terminals again. The updated balance information must also be sent to the TG.
11. So the next time the user sends the ‘Query Balance’ request to the TG, the TG updates the Ticket_Fare with this balance to reflect the correct available balance. It must actually send the entirely new QR Payload as the Digital Signature would have to be updated. The APP must display the ‘Updated Balance’ to the user and also render the new QR.
12. This cycle can repeat from Step 6 until Step 9 is reached or the user actually recharges the Pass.

Example of a QR Ticket using a Senior Citizen / Student / Special Pass: 

Senior Citizen, Student or Special (for differently-abled persons) products or passes are not as straightforward as the other passes. There is a mandatory requirement of Verification required before these can be used. The following steps provide a simple yet effective method to implement these type of Products in the QR Ticketing System.

1. In this method, the APP provides user to the option to buy a Senior Citizen or Student or Special Pass as any other Product or Pass.
2. The APP must mention that these Passes need ‘Verification’ and the process as described in these steps must be clearly mentioned.
3. For these type of Passes, it must be mandatory to fill the Personal Info, which is part of the Static Block of the QR Dataset. In the Personal Info all information in the  Name, Age, Gender, ID No and ID Type must be filled out
4. The user must specify the date from which he wishes to make the Pass active. This should be filled in the Activation_Date field of the Ticket (or Pass in this case).
5. Once all the information is filled, the user must be asked to agree with these rules and can then proceed and buy the ticket. If the payment is successful, the APP must render a QR having only the Tkt_Sl_No.
6. On the TG, these serial numbered tickets must be marked as ‘Requires Verification’ or something in those lines.
7. On the APP, there must be a button like ‘Request Ticket’. Until the ticket is actually verified, till then clicking this button the TG should simply respond with ‘Ticket Not Validated’.
8. On the date of Activation, the user must proceed to Customer Care with his QR. Naturally, this QR will not work on any Validation terminal as it does not have any journey information.
9. The Customer Care executive shall scan the QR and fetch the Pass details from TG. He must then proceed to verify the actual Physical Identity of the user with the information fetched from the TG.
10. Once the Customer Care executive is satisfied that the information provided when purchasing the QR Ticket (or Pass) is consistent with the actual ID, he must send the request to the TG to mark the Pass as ‘Valid’. The TG must acknowledge the Customer Care application affirmatively. The Customer Care executive must then inform the user that he can now ‘Request Ticket’.
11. This time when the TG receives the request, it must then return the QR Payload.
12. The APP can then proceed to render the actual QR Pass on the user’s APP and the user can start using it just like any other QR Pass.

Futuristic Implementation

Some further advanced implementation features of the QR Ticketing System can be outlined stated as under:

Advanced Features in QR Ticketing System

These are desirable features that should be taken up to add value to both the customer and PTO.  

• Applying Machine Learning and Artificial Intelligence to the System that shall be useful not only to the public but particularly to the PTOs with valuable insights.
• Different Media scanning not just optical or camera scanning but also Bluetooth, WiFi, NFC scanning
• Designing and developing cost-efficient Android based Validation Terminals that can be quickly adopted by the transport industry and quite possibly by other industries as well for e.g. the tourist sites, parking areas etc.

This may involve below mentioned steps further :

1. Sending Real-Time Transit Notifications to Customer’s Mobile Route Request – Consumer Mobile Apps must be informative and user-friendly. Notifications like (a) Reminders on the date of journey, (b) Transit updates – journey completion, (c) real-time schedule changes, (d) Traffic conditions (e) Availability of tickets, etc. can be sent to the user’s mobile phone and shown in the App to give a clear picture to the customer. The general way to send all such updates to the user’s mobile is called ‘Push Notification’. Technology Service Providers like Google, Apple, Microsoft and Amazon provide Subscription-based Push Notification services that Application Providers can avail to send business updates to their customers in real-time. The concept of Push Notification Service is simple and can be described in a nutshell as follows:

1. Subscription to a cloud messaging service like Google Firebase Cloud Messaging (GCM – also called Firebase Cloud Messaging – FCM since 2019) or Apple Push Notification Service (APNS) – These are mobile notification services that enable third-party application developers to send notification data or information from developer-run servers to applications that either target the Google Android Phone or the Apple iOS Phones. The GCM and FCM may also be viewed as  two separate entities operated by Google wherein the GCM does registration/authentication jobs and the FCM delivers the real-time messages to the user devices.
2. Cloud Messaging Services has the ability to send push notifications, deep-linking commands, and application data well up to 4 KB of payload data. Push Notification Services are usually a paid- service and so in order to take advantage of this technology the APP Provider must pay up and subscribe annually with a good Messaging Service Provider like GCM.
3. All App Providers must inform the user and seek permission to send ‘Push Notification’ to their personal mobile. This can be done during App set and installation as a onetime pre-requisite. Here we assume that the user gives consent to the App Provider to send Transit Updates to his/her phone.
4. Upon allowing the App permission to receive and display notifications, the client APP sends a registration API request to the Cloud Messaging Service, say GCM, interface to begin the registration process.
5. The GCM Service receives and acknowledges the request and responds by giving the device a GCM Registration ID – a unique identifier that is used later to send notification to the individual mobile device. The identifier is stored onto the device, and is typically sent to the developer’s Application Server (App Provider) to be stored. The Registration ID is a randomly-generated identifier that does not contain any personal or device information that could allow a developer to discover the personal identity of the user.
6. When the App Provider wishes to send a notification event to an individual device, the process begins with an API request to the GCM Authentication Service. The request must include the Registration ID among some other data like the content that is to be displayed on the device.
7. Upon successful verification of the Registration ID and other credentials, an authentication token is returned. Both these identifiers are then sent back to the GCM Service to be ‘Enqueued’ and delivered to the device
8. Upon receipt of the Push Notification Message, the App can then update the necessary tickets for journey updates or other such information.

2. Route-agnostic Intra-PTO QR Code Ticket – In ordinary day-to-day commuting in cities, it is commonplace for commuters to travel on more than one Line or Route to reach his/her destination. For example, if a person uses three different routes to reach his office or home, it essentially means that his source station (starting point) falls in the first route and his destination station (ending point) falls in the third route. But in order to complete the entire journey, he has to learn not only about all the available routes including the connecting intermediate routes, but also the stops where he needs to descend and then ascend again in order to continue towards his destination. This is applicable for both Buses and Metro transport. Although, most of the bus transport operators have implemented route based ticketing system currently, it is desirable that the QR Ticketing System should support a Route-agnostic QR Ticketing form of implementation when issuing tickets to customers. This essentially means that the customer should only mention his Starting and Destination stations and the system must be smart enough to determine and show all the possible combinations through which these two points can be connected. The customer can then make an informed decision of which combination he or she wants to avail.

3. Urban transport has advance by leaps and bounds in the last 10-15 years in our country. Not only Metro rails, but high-speed Rapid Bus Transit, Rapid Rail, Suburban Rail, Mono Rail, etc. have made their presence felt in our country providing commuters the comforts of fast travel within the city and even to long distance satellite towns and cities. In an effort to provide further convenience to commuters, different PTOs – operating different transit medium within a city or even between cities – are now collaborating with each other to issue combined single journey tickets from each other’s premises thereby sparing the customer from the burden to procuring multiple tickets when hopping from one mode of transport to another. This type of collaboration or interchange is called Paid-2-Paid interchange. One example of Paid-2-Paid interchange are Delhi Metro (operated by DMRC) and Airport Rapid Transit (operated by Reliance). In the city of Mumbai, 14 PTOs operating under MMRDA, running different modes of transport have already collaborated or are in the process of doing so to allow customers to inter-travel on any mode of transport with a single ticket. In general, the PTOs that support Paid-2-Paid travel have common interchange points using which the commuter can hop from the premises of one PTO and move to the premises of the other.

Acronyms and Abbreviations

• AFC – Automatic Fare Collection System
• CAFC – Centralized AFC system
• ECC – Error Correction Code
• GSM – Grams Per Square Meter
• HID – Human Interface Device
• PTO – Public Transport Operator
• QR Code – Quick Response Code
• RFU – Reserved for Future Use
• Stn Code – Station Code
• TOM – Ticket Office Machine
• TRM – Transit Rules Management
• TXN Ref. No. – Transaction Reference Number

Conclusion

Over the last 4-5 years, QR codes have become the most popular medium of choice for instant payments in our country and across the globe. With the ever-increasing demand for deployment of QR Codes as fare media, it is important that the Public Transport ecosystems provide a consistent and seamless experience to their customers. The system should enable people to remotely book tickets not just for urban transport operations like Metro and Buses, but also other varied services like hotel reservations, entertainment events, tourist spot reservations, etc. The popularity of QR codes also means that there is a good availability of online technical support. This allows service providers to quickly develop and implement solutions compatible with most existing payment gateway systems. 

The specifications described in the preceding pages above are only a first step towards achieving a world-class QR Ticketing Ecosystem that strives to provide customers a hassle-free travel experience on one hand, and to service providers a fully automated state-of-the-art ticketing solution, on the other. However, this is only just the beginning. The road ahead is surely long and winding. In due course this ecosystem must evolve towards route and operator agnostic ticketing solutions and encompass other non-transit services under its umbrella. The not-so-distant future should also address some of the most pertinent needs of the modern world like vehicle capacity management, real-time traffic updates, attractive pricing, etc. through the use of Industry 4.0 technologies viz. artificial intelligence, machine learning, big data and IoT.