Universal Ticketing Agent

UniTiAg Business Architecture

Let’s take a closer look at the business architecture of UniTiAg SaaS

 

Two-Sided Marketplaces

TSMP is an entity providing online services to Riders (as shoppers or wallet holders) and TAs (as e-merchants). In addition to its legacy relationships with shoppers-Riders, the TSMP determines with Riders so called Open-To-Ride Balance (OTRB) and informs UniTiAg about the OTRB status, currency, and amount, using UniTiAg’s TSMP API for this.

The Two-Sided Marketplace performs the following functions:

  • Implements the TSMP API.
  • Interacts with its Riders for the purpose of OTRB offering, creation, replenishment, and withdrawals.
  • Collects funds from the Riders to replenish OTRBs by means of CNP and e-commerce acquiring, interacting for the latter purposes with acquiring processors and payment schemes.
  • Provides the Riders with reports of the fares and fare refunds applied to their OTRBs.
  • Reconciles the TAs for their fare-related services.
  • Collects merchant fees and possibly currency conversion fees from the TAs.
  • Complies with the PCI DSS,  payment schemes, and acquiring processors regulations as a merchant handling CNP transactions.

UniTiAg

UniTiAg performs the following functions:

  • Collects fare and refund data from Transit Agency’s Account-Based (or Automatic Fare Collection) systems, via the TA API, and updates the affected OTRBs.
  • Replicates OTRB updates to Regional UniTiAg hosts.
  • Provides fast access to targeted OTRB data to TAs’ ABT systems via the TANB API through Regional UniTiAg Hosts.
  • Provides fare charge and refund reports to TSMPs for reconciliation via the TSMP API.
  • Provides activity reports to TAs’ ABT systems via the TA API.

UniTiAg does not:

  • Perform any card payments functions.
  • Communicate directly with transit riders.

Contactless Rider Device

Contactless Rider Device – CRD – is a device that communicates with a Validator to present credentials proving the Rider’s right to access transit services. In UniTiAg realm, the CRD is not a payment tool but a means of attributing service entitlement to the rider. CRD examples include, but are not limited to, cEMV cards in any form factor, UWB-enabled smartphone apps, Calypso cards, and QR code-based solutions.

For the simplicity we will call any CRD interaction with a Validator a “tap“.

Transit Agency

Transit Agency is a transit operator or an entity representing several transit operators. The TA acts as an online merchant or seller from the TSMP’s standpoint. The TA performs the following functions (usually through its ABT or AFC system): 

  • Manages fare policies, including fare schedules, discounts, passes, and concessions..
  • Calculates fares and validate trips at CRD taps or delegate these activities to its Validators.
  • Determines fare and dispute refunds.
  • Coordinates with government agencies on concession policies.
  • Manages routes, vehicles, stations and stops encoding.
  • Provides fare and refund information and service details to Riders.
  • Oversees and maintains validator operations. Ensures that Validators meet cEMV requirements and conduct ODA correctly.
  • Assigns and manages Validator IDs and terminal IDs for ODA handling.
  • Supplies validators with key materials for cEMV process.
  • Ensures Validators accurately record tap times.
  • Collects fare data from Validators.
  • Reports OTRB fare and refund data to UniTiAg via the TA API.
  • Provides Riders with fare and refund reports and manages disputes with Riders.
  • Inspects fares with fare enforcement devices.

Transit Agency ABT (AFC) systems are not replaced by UniTiAg. On the contrary, with UniTiAg, ABT and AFC systems continue to play an important role in the TA ticketing process, as they are responsible for implementing the TA’s fare policies and communicating with transit riders. From the ABT (AFC) system’s perspective, UniTiAg is just another method of acquiring, in addition to or in place of the classic open-loop and closed-loop acquiring methods.

TAs may integrate services from multiple transit operators that manage their own vehicles and systems. However, this is outside the scope of UniTiAg. UniTiAg operates at the TA level, presenting TA data to the TSMP as a single merchant’s activity for reconciliation. The reconciliation process between the TSMP, TA, and its operators is governed by the merchant agreement between the TSMP and the TA.

Validator

The Validator interacts with cards –  or other contactless tools storing the OTRB credentials – during the cEMV tap process, similar NFC or other short range protocols (e.g. based on UWB). 

  • The Validator does not originate card-present transactions and is not a Point of Sales. If a TA needs Point of Sales capabilities to be added to some of its Validators, these capabilities and the card-present-transactions acquiring are out of UniTiAg scope.
  • The Validator is a trusted device, relied upon for captured OTRB data accuracy, conducting ODA, and timekeeping.
  • The Validator performs ODA, records tap time, and reports tap events to the TA.

Specific requirements for cEMV compatible Validator:

  • The Validator (or its cEMV card reader) stores encryption key materials necessary to protect card number (PAN/DPAN).
  • The Validator comprises EMV Level 2-capable equipment.
  • The Validator’s cEMV card reader should be:
    • EMV Level 2 certified. This is desirable but not necessary as the Validator is not a Point-of-Sale.
    • PCI DSS-certified for card data protection. For UniTiAg processing purposes, clear-form sensitive cEMV card data does not need to leave the cEMV card reader.
  • The Validator executes cEMV sessions without completing card-present transactions.

Validator-TA interaction may use a proprietary protocol outside the TA API scope.

Validator Types Summary

From UniTiAg perspective, there are two types of Validators, distinguished by how they access ORTB data:

  • Wired Validators are embedded in turnstiles or terminals alike, installed on railroad or subway stations. They do not need to maintain their own copies of up-to-date OTRB data because they can obtain the required OTRB data from their TA or the Regional UniTiAg Host within milliseconds.
  • Wireless Validators are typically installed on transit vehicles. They should have local copies of up-to-date OTRB data because wireless connectivity to their TAs or Regional UniTiAg Hosts may sometimes be unavailable, slow, or unreliable. Replicating OTRB data across Wireless Validators does not need to be done in real time as it usually takes at least several minutes before a tapped CRD can be tapped again at another Validator. This category may also include handheld contactless devices used by fare enforcement or sales agents to sell fares or issue fines.

Classifying Validators in this manner is conditional; the main criteria are reliability and speed of wireless or Wi-Fi connections.

Next to Read

Our APIs

Frequently Asked Questions