OpenFare is now Universal Ticket Agent (UniTiAg). Please refer to that site for up-to-date information about UniTiAg business architecture and capabilities.

Let’s compare OpenFare (which is a proactive open loop transit system) with a classic open loop one.

How Classic Open Loop Works

Classics System Trip

When a patron taps his card for the first time at a turnstile or bus validator, in the classic transit system, the validator captures the card data and makes an attempt to obtain an authorization from the card issuer (a bank that issued the card to the patron).

This may take 1-6 seconds.

The patron cannot wait for so long at the turnstile. The acceptable tap latency  is 350 msec. Therefore the validator does not wait for the card issuer authorization and just opens the turnstile (gate). The patron enters the system.

While the patron is enjoying the trip, the transit host receives the authorization response from the card issuer. If it is not good, the card is placed in a stop list.

When the patron exits the system, he or she taps at an exit turnstile. If the card is OK (not in the stop list), the transit host just makes a record about the trip: where and when it was tapped on and off, so the patron can be charged (later).

If the card is in the stop list, the gates are not supposed to open. The fraudsters know this and do not try to tap on with bad cards on subways (undergrounds). The genuine patron can also be trapped if, by some reason, his card has appeared in the stop list. This can be an embarrassing situation. How it is usually resolved, depends on the transit system policy. The patron is lucky if he or she has other means of payment in his or her purse.

Here are some situations when such an embarrassment may happen:

• The patron used a wrong card by mistake, e.g. the bank provided a replacement but the patron used an old card.
• The card account does not have sufficient funds (mostly happens with debit or prepaid cards).
• The card was marked as risky by the card issuer because someone else made a suspicious transaction with a fraudulent copy of this card.

In some cases, instead of turnstiles, railway transit systems may use inspectors, with the validators wirelessly connected to the transit host.  As you can see, this case is pretty similar to the tap-off trap case.

Another story is a bus validator. Some bus routes have flat fares like in Transport for London. They do no have tap-off policies on the buses. In other transit systems bus routes may implement distance-based or zone-based fares and tap-off policies. In this case, if the card is already in the stop-list the patron will be let go because of the driver safety policy. Therefore, whether with or without tap-off, on the buses, the transit agency assumes the cost of the first trip in case of bad card. The second trip with the same card will not be possible because the card will be already in the stop-list.

Classic System: Payment

Later, at night, the transit host calculates the final cost of of all trips of this patron during the day, applies all discounts, and sends a payment charge transaction to the payment system. Most likely, the payment will be honored by the card issuer but in some cases it will be not.

This may happen if the patron’s day total exceeds the specific transit limits setup by the card system and the cardholder complains (“it was not me”). Some transit systems may have pretty expensive trips.

How OpenFare Works

OpenFare: Prepayment

Before a patron can tap at a turnstile or bus validator, he or she must create an OpenFare account and put some money on it. The patron must also associate this account with some contactless card or token.

The patron can always top-up his prepaid balance using his smartphone or desktop browser. The new balance will become “known” to bus validators within seconds.

Topping-up the account is the only case when the patron actually pays money using some credit cards, PayPal, direct bank billing or any other payment methods.  Tapping cards during trips within the OpenFare realm has nothing to do with payments and risks associated with them.

The patron can use his or her prepaid balance at any participating transit agency. It is a single balance shared between all such agencies.

Trip cost reconciliation is done between OpenFare and transit agencies participating in Open Fare.

OpenFare: Trip

When the Patron taps a card or token at the validator, the validator looks up for an associated account  in the validator’s memory (the validator does not connect to an external system at that time). If the account is the memory and the balance is sufficient for the fare, the patron is allowed to enter. Tap latency is below 350 msec.

There are no lengthy stop-lists in the validator memory which include all bad cards in the world.

While the patron is enjoying the trip the validator reports the patron’s fare parameters to OpenFare via a wireless data system and OpenFare propagates the new state of the patron’s card as well as up-to-date fare history to all validators in the system.  When the patron approaches another validator, this validator already “knows” everything it needs to apply all possible discounts and make a decision on granting access to the transit service.

To make all this happen, OpenFare must propagate quite a large volume of data to bus or street car wireless validators. It does not need to be done with stationary turnstile validators as they are wired to the transit host.

The good news is that the data propagated to the validators is the same for all of them. That is why data broadcast method can be used instead of the classic wireless one-to one data transmission protocols.