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:

  • Store or receive any card, cardholder, or personal data from its counterparts: TAs and TSMPs.
  • Perform any card payments functions.
  • Communicate directly with transit riders.

Transit Agency

Transit Agency is a transit operator or an agency 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 card 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 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.
  • Validates trips 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 do not need to store or transmit sensitive card or personal cardholder data to UniTiAg but may retain private rider data for internal purposes (e.g., senior concessions), which falls outside UniTiAg’s processing scope.

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 the Card during the cEMV tap process, capturing Tap Data. 

  • 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 Tap Data accuracy, conducting ODA, and timekeeping.
  • Validator (or rather its card reader) stores encryption key materials necessary: to protect PAN/DPAN and conduct ODA.
  • The Validator comprises EMV Level 2-capable equipment.
  • The Validator’s 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 card data does not need to leave the card reader.
  • The Validator executes cEMV sessions, computes hashed PAN/DPAN, performs ODA, records tap time, and reports tap events to the TA.

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 card 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