Tap & Go Ticketing: The Middleware Behind Contactless Public Transport

What makes a contactless transit journey work is rarely the reader at the gate — it is the middleware sitting behind it.

One kernel, both loops

Transit authorities are rarely choosing between closed-loop transit cards and open-loop bank cards; most end up running both. A single ticketing kernel manages card data organisation, operator business rules, issuing and acquiring, activation and top-up, sales logistics, and the security infrastructure underneath — while supporting NFC, HCE and BLE alongside plastic. That common rule set is what stops closed loop and open loop becoming two separate programmes with two separate cost bases.

Fares are decided after the tap

In an open-loop model the validator authenticates the card, tokenises the data and passes it on; the middleware infers the journey from the sequence of taps and applies the tariff. Multiple journeys inside an hour or a day resolve into the right pass. Overnight, the back office produces one charge per card — student discounts, daily and weekly capping included — and sends authorisation, clearing and settlement messages in standard payment-industry formats.

Ogloba's role is to supply that kernel: issuing, acquiring, top-up across retail terminals, cash registers and vending machines, plus the financial and logistic flows behind them. The gate is the visible part. The economics live in the layer nobody sees.

FAQ

Why do transit authorities end up running closed-loop and open-loop schemes together?

Most authorities do not treat it as a choice. Closed-loop transit cards and open-loop bank cards usually run in parallel, and a single ticketing kernel applies one set of card data rules, operator business rules and security infrastructure to both. Without that common rule set, each loop becomes a separate programme with its own cost base.

Does the same kernel support mobile ticketing as well as plastic cards?

Yes. The kernel supports NFC, HCE and BLE alongside conventional plastic, so a passenger can travel with a card or a phone under the same programme. Card data organisation, issuing, activation and top-up follow the same operator business rules whichever form factor the passenger presents at the gate.

How does the middleware work out the right fare after a passenger taps?

In an open-loop model the validator authenticates the card, tokenises the data and passes it on. The middleware then infers the journey from the sequence of taps and applies the tariff, so multiple journeys inside an hour or a day resolve into the right pass rather than separate fares.

What happens overnight, once the day's taps have been collected?

The back office produces a single charge per card for the whole day, with student discounts and daily or weekly capping already applied. It then sends authorisation, clearing and settlement messages in standard payment-industry formats, so the programme settles using the same message formats as any other card payment.