A multi-module network takes the hassle away for the passenger
Ridango operates travel card systems for public transport providers. They were looking for a solution that allowed passengers to pay for their journeys using their debit or credit cards. A task that seems simple, but which is actually a complex and multi-layered operation happening in a fraction of second.
With only a couple of systems operating worldwide, the debit/credit card payment solution is the perfect fix for the tourist, allowing them to pay easily without having to purchase a top-up card before they travel or a paper ticket on entry. The challenge was to devise a system that could seamlessly reference the user’s eligibility to pay for the journey, minimizing delay at the gates or doorways of the travel network.
Proekspert set out to build an Amazon Web Services (AWS) cloud-based modular solution to sit between (already existing) Ridango’s ticketing system and the (already existing) NETS system, Swedbank (Sweden) and Oschadbank (The State Savings Bank of Ukraine).
A balance between convenience and security
A challenge for us was to ensure that a real-time transaction can be carried out in the time it takes a passenger to climb aboard a bus or tram, that provides the security and speed required to make this as a viable and convenient solution.
The process that goes on behind the scenes when a passenger taps their contactless debit or credit card across the terminal has been intricately designed to follow a series of Visa and Mastercard mass transit payment rules.
The Visa’s Mass Transit Transaction (MTT) model and Mastercard’ Contactless Transit Aggregated Transactions are designed for multi-modal metropolitan public transport operators with the need for high passenger throughput and/or where complex fare calculation policies are operated. Nowadays the trend is to move from closed-loop fare collection systems based on proprietary technology to open-loop systems based upon standardized and certified technology.
As this kind of payment method was quite new and little-used around the world when the project was initiated, bank requirements and rules weren’t in place in Estonia. Our task in cooperation with teams from Ridango, banks and NETS was essentially to work out a solution that would comply with Visa and Mastercard rules, but would also work within the Estonian card payment infrastructure. After extensive experimental development and interaction with banks and NETS, a clear vision of how this kind of system should work was still missing.
The general operation of the system follows a relatively fluid process. When a new debit or credit card is held against the reader, a multi-level process goes into action. The validator checks whether the card being used to enter the transport network has not expired, been blacklisted nor counterfeited, then the request is sent to the ticketing system. The ticketing system calculates the price for a ride based on ticketing selling rules and system logic (built in the ticketing system) and sends the request for payment to the new payment gateway, built by us.
The payment gateway processes this payment according to Visa’s MTT model and Mastercard’ Contactless Transit Aggregated Transactions, and Known Fare Transaction (KFT) model rules and sends a request for payment through the NETS system to the Issuer bank. The Issuer bank then gives the answer if the card can be used or we should add it to the blacklist.
Giving the client a competitive edge
Because of the complexity of the software and systems required to achieve the desired outcome here, our solution has given the client an edge over competitors in the short term that will not be easy to replicate, keeping Ridango at the forefront, well into the future.
Our product for Ridango can be upgraded on a modular basis, allowing for improvements at all stages of the process to be easily implemented.
Although initially, the system was built in Estonia and for Estonia. Later on the system was amended for the Swedish environment, in which we integrated the system with Swedbank Sweden’s corresponding protocol, and even later amended it for Kiev, in which the system works against Oschadbank’s protocol via an intermediate party.