How a Tube gate gets paid: half a second at the edge, the maths in the back office

Tap a contactless card on a Tube gate and the paddles open almost straight away. Your bank hasn't approved a payment at that point, and nobody has worked out your fare yet. Charging you is something that happens later.

It's one of the best real-world examples of a pattern every cloud architect uses: make a fast decision at the edge with the data you have locally, then settle the details in the back end. This post walks through the whole process, from the tap to your bank statement. Watch the video first, or skip straight to the detail below.

The half-second budget

A ticket gate exists to move people. When TfL brought bank cards to the gates, the time a reader could spend on each transaction was capped at 500 milliseconds, roughly the time it takes to walk through without breaking stride. Mastercard's case study on the rollout puts the average entry validation at about 300 milliseconds.

Asking a card issuer to authorise a payment can't reliably fit into that window. Add peak-time crowds at a busy station, and a gate that waited for the bank would turn into a queue on the street.

What the gate checks on its own

So the gate doesn't ask. The yellow reader carries out EMV cryptographic authentication with the card entirely offline, with no key or data exchange with remote servers. The card proves it's a genuine card, which stops cloned or counterfeit cards, without a round trip to anyone.

The second check is about debt. TfL's conditions of use say you aren't allowed to travel on a contactless card that has unpaid fares against it until the amount is paid in full. If the card is genuine and doesn't owe anything, the paddles open.

The back office does the real work

Every tap, in and out, goes to TfL's back office, which handles fare calculation, capping and the online account. Three things happen there.

1. Taps become journeys

A tap in at Brixton and a tap out at Oxford Circus become one Victoria line journey. That's why touching in and out matters on the Tube, DLR, Overground, Elizabeth line and National Rail. On buses and trams you only touch in. If you don't touch in and out correctly, you may be charged a maximum fare. Take longer than the time limit between touching in and out, and the conditions say you can be charged two maximum fares.

2. Capping

Once your journeys are known, the system applies daily capping, and weekly capping from Monday to Sunday. You only get capping if you use the same card or device for every journey in that period. A few services, such as the London Cable Car, Thames Clippers River Buses, Heathrow Express, Gatwick Express and Southeastern high speed services, don't count towards it.

3. One charge

TfL charges your card after you've finished travelling for the day. The bank statement shows one TfL Travel charge for the day, not one per tap, and Barclays says it usually appears within three days. A small detail that surprises people: in some zones the daily cap is over £100. The charge is the day's total, so it can be larger than the £100 limit you'd hit if you tapped to pay in a shop.

When the bank says no

Because you travel first and pay later, some payments will be declined. TfL's conditions spell out what happens next:

• TfL tries again, but not more than three times, no more than once a day, and only within 30 days of the decline. On a statement, these show up as unpaid fares.
• It also tries to collect the unpaid amount the next time you touch the card on a yellow reader.
• Until the debt is paid in full, you can't travel on that card. You can pay through your TfL online account or by calling TfL.

That last rule is what makes the offline check work. The gate doesn't need to know whether today's journey will be paid for. It only needs to know whether this card already owes money.

TfL did the maths

Letting people through before they've paid means some fares will be lost. The alternative is making millions of people wait at the gates every day. The numbers suggest it was worth it: Mastercard's case study reports that TfL's cost of collecting fares fell from around 14 percent of revenue to just below 9 percent, with a target of about 6 percent.

Ask the bank at the gate

• Every tap waits on a remote approval
• Queues at peak times
• No capping without extra work

Decide at the gate, bill later

• About 0.3 seconds per tap, offline
• Journeys and caps worked out centrally
• A few unpaid fares, recovered or blocked

How big it is

• Contactless bank cards were accepted on London buses from December 2012, and on the whole network from September 2014.
• By early 2017, contactless was handling about 1.8 million journeys a day, from cards and devices issued in more than 100 countries.
• Cubic, which runs TfL's revenue collection system, lists 2,808 gates and around 10,000 Oyster readers, and says more than five billion journeys have been made by over 40 million unique cards and devices.

Where Microsoft and Azure come in

A couple of public examples link TfL to Microsoft, with one caveat: they're from about a decade ago, so the current setup may well be different.

• Live Tube data on Azure. TfL moved its Trackernet feed, which publishes real-time train locations and line status to developers, to what was then Windows Azure. It was built to handle more than seven million requests a day. Feeds like this are what travel apps use.
• Contactless billing on SQL Server. In 2015, Microsoft said the data behind TfL's contactless system was held centrally on Microsoft SQL Server. Unlike Oyster, where much of the data sits on the card, contactless keeps the account data in the back office.

The lesson for cloud architects

Strip away the paddles and the pattern is one you'll recognise:

• Decide at the edge with local data. The gate never waits on a far-away system. The same is true when an API validates an Entra access token by checking its signature locally rather than calling Entra on every request. You can see what's inside a token with the JWT decoder.
• Keep a short list of what's not allowed. The gate refuses cards that owe money. In identity, continuous access evaluation plays a similar role, letting services react quickly to critical events such as a disabled account instead of waiting for a token to expire.
• Reconcile centrally, later. Journeys, caps and charges are worked out once there's a full picture. That's eventual consistency, chosen on purpose.
• Put a number on the risk. A small, bounded loss is acceptable when the gain in speed and cost is this large, and the retry and block rules keep the loss bounded.

Why do I only see one TfL charge a day?

TfL adds up all your journeys for the day, applies any cap, and then charges your card once for the total.

Can the charge be more than £100?

Yes. Some daily caps are above £100, and because the charge is made after you travel, it isn't limited in the same way as a single tap-to-pay in a shop.

What if I use two different cards?

Capping only works when you use the same card or device for every journey in the day or week. Watch out for card clash: if you touch a wallet with more than one card in it, the reader may pick the wrong one.

Is this exactly how TfL built it?

This explains the process using TfL's published conditions of use and public case studies. TfL's internal design isn't public, so the detail inside the back office is described at the level those sources give.