I don’t understand how offline ticket creation could work in any scenario, full-stop. Surely you need to have a data connection in order to purchase the ticket in the first place, right?
While still online, let people download a bunch of signed tokens from a server in exchange for their public key, which is linked to their phone number and thus identity and credit card.
Now when offline, they can create their tickets by linking a token to a fare and sign that with their private key.
At check-in, collect those tickets and when online again, charge the credit card.
Ah, so essentially require the inclusion of a pre-signed, server-generated token identifying the user in the ticket’s QR code and perform the actual charge when the ticket is used.
That’s much better, though it’s subject to some edge cases similar to the London Underground, caused by the potential for using invalid payment methods. Not bad though; probably low-enough potential for abuse to ignore.
Off the top of my head, if the backend holds either the payment details or an alias to them from a payment service provider, you could also implement a solution where the turnstile/conductor is connected to a network and the payment gets done on the backend once a ticket generated offline gets scanned/used
A bus ticket just says you've paid some money to get on a bus. It's not a booked seat or anything else like it.
Also, historically bus tickets do not exist to keep passengers honest. They exist to keep the drivers honest. A valid ticket tells the bus company that the driver isn't taking passenger money but not declaring that money to the bus company.
Surely Apple pay works offline because your balance is checked by the card reader before the transaction is approved, in the same way it is when you use a contactless debit card?
They don't really check your balance on the contactless debit card. They just try to charge you. (This may mean authorising an outline transaction they try to execute later) It either works or not. But basically if it works, it's now between you and the bank.
There are two separate transactions for payment cards. Authorization and Settlement. Only Authorization involves all this clever technology like encryption and PINs, only Settlement actually moves any money anywhere.
For some debit cards, the situation is that they only allow Authorization to occur online, and it will validate your balance before authorizing the transaction AND it will respond to Settlements which are unauthorised by always reversing them.
Most people don't want this, because it's annoying, but it can be an option for people who have (some) money but can't be trusted with debt, for example some problem gamblers. It would never be reasonable to give them a card they can spend more than they have on, because they will spend uncontrollably.
The distinction between Authorization and Settlement has a variety of weird consequences. For example:
If you lose a card and it has to be blocked by the issuer, transactions you Authorized with that card can still be Settled hours, days or even very occasionally weeks later despite the block.
Some merchants who determine their exposure to fraud is very low just don't bother with Authorization at all. They only do Settlement, and it Just Works™ because none of their customers were trying to defraud them or queries the bill. This is a really nice user experience, super low friction.
Modern Authorization has anti-replay features, because it's built out of technologies where that was essentially free. So you can't execute any Authorization more than once (but Light Blue Touchpaper has an example incident where bad RNG allowed bad guys to attack this). But Settlement still acts like reel-to-reel tape is exciting new technology so it has no anti-replay, and periodically a batch of Settlements will accidentally be executed twice, taking money from customers and giving it to merchants until enough related complaints happen for somebody to realise the mistake and fix it.
Oh, sure - I mean you could carry a balance, but that would be inherently insecure (clearly not something they are particularly fussed about).
Apple Pay is a little different in that the terminal is online - I was under the impression all contactless terminals perform auth in real-time, but I may be mistaken.
The EMV system (that makes contactless card payment work as well as "chip cards") has the card act as a representative for its owner (the card company, not you, you don't own the card and it tells you that when you get it) and it negotiates with the terminal for each transaction.
The card (on behalf of its owner) gets to say e.g.
"Hi, I am allowed to authorise $185 more offline before talking to my owner. I am allowed to do PIN transactions also I have a magstripe. What shall we do now?"
And a terminal could say "OK, let's do an online $28 transaction, with proof of PIN" or, "I'm good, $5.80 offline and no need for a PIN".
All this complexity opens up a bunch of potential problems (and EMV is guilty of not getting in a team of academics to figure out the cryptographic situation before shipping it, so it has had to be repeatedly patched and has a bunch of issues that needn't exist) but it allows Apple Pay to decide that e.g. you can spend up to $50 per time, and so long as you make an online transaction at least once per week and without spending more than $250 offline that's fine.
Both the issuer of the card and the terminal's owner get to decide on their appetite for risk. Probably if you sell $500 gold chains from a location with bars on the windows and an airlock entrance you want to do online proof-of-PIN transactions only, even if the card itself says it's happy to spend $500 offline contactless - and if your bank is trying to rehabilitate someone with spending problems (in a country where just exploiting them isn't legal) its card may tell the guy with a street cart that alas you need to go online and do a PIN transaction even for their $6 bagel.
London Underground and London Buses are both "semi-online". They don't generally try to immediately validate a transaction with your bank the moment you touch your card. Transactions are batched and applied overnight, after applying any discounts like daily/weekly fare caps, out-of-station interchanges, and the bus "hopper fare". The batching means that transactions can still be accepted if the terminal is offline for some reason.
However, there is also a blacklist of card numbers that have outstanding balances against them. If you try to use a card that is declined, it will work the first day but not on subsequent days. If you go on TfL's website and clear the outstanding balance, the card will work again after 30 minutes (or in practice, less) once it is removed from the blacklist.
Buses are online. I’ve seen them authenticate a new card in real-time (they charge £0.10 on a card they haven’t seen recently to check if it’s cancelled).
It wouldn't necessarily be insecure - the bus could reject an offline-generated ticket at the time the user tries to get on the bus if the user's account is unable to pay for it.
Sure, if the scanners are online that makes a great deal of sense (though you would have to perform that transaction in real-time, which would be slow)
What happens if you uninstall the app before going back online? You'd need to rely on the ticket being scanned at some point to ensure the person was charged, which isn't guaranteed on many transport systems (including the British rail network.)
Now when offline, they can create their tickets by linking a token to a fare and sign that with their private key.
At check-in, collect those tickets and when online again, charge the credit card.