That's about exactly as it is. There is no info stored on the card other than the account number (for want of a better term).
The card carries no balance information, that is held in the back end of the system somewhere. When catching PT, you wave your card, the computer pulls your account number, fare type and time, checks for funds, deducts funds, updates the balance and returns such to the validator screen.
When adding your finances to the card it is only placed on the machine to pull your account number, the balance is updated by the back end.
The reason for the 'user' recharge machines requiring you to put your metrocard in the slot first and remove it last after you credit card is due to credit cards also featuring pay wave etc.
Metrocard in first to pull account details without CC interference. CC requested to perform payment transfer, CC to be removed so that balance update and confirmation can be conducted on Metrocard, without CC interference.
I have a little experience with distributed transaction systems - but I have no knowledge of the Adelaide Metro system (beyond being a regular user)
I find it hard to believe the system doesn't store the current balance on the card.
I do know the cards are "Mifare DESFire EV1" smartcards, featuring optional AES encryption and 2, 4 or 8Kbytes of memory.
The AES encryption makes it hard to tamper with the system - eg cards are encrypted with the Admet private key, any foreign cards wouldn't work - and 4K of memory is plenty of space to store the current balance as well as a recent transaction history (eg 1k could easily store 100 transactions or more.)
Melbourne's Myki cards use the older, less secure and slower to validate "Mifare" standard - they store the current card balance and at least the last 3 transactions.
Given the validators HAVE to work every time - assuming an undamaged card and validator - and have to perform a validation within a second or so, and most of the validators are on moving vehicles, it's very unlikely the validators are pulling your balance from a central database somewhere, over a 3G connection. You couldn't guarantee blanket 3G coverage with sufficient speed and latency to do that with 100% reliability, under a second, every time.
Either every validator (or on-vehicle validation computer if there are multiple validators on the vehicle) has a local copy of the entire database, which is updated when the vehicle/validator is in radio contact with the backend, or - more likely - the balance is stored on the card, along with the last 10 or so transactions.
My guess is the card is the authoritative source of the "stored value" -
The recharge stations increase that value when the card is present, and store the transaction and the current card balance to update the backend database when available/in range.
The validators would reduce the card balance by the relevant fare, and store the transaction and the current card balance for database update.
So what about internet payments, or any balance increases where the card is not present?
My guess is any internet payment transactions to a card would be uploaded to all validators and recharge stations in the network within 24 hours, so if a validator sees a card that hasn't had a specific transaction applied to it, it updates the balance and reports the transaction is now on the card back to the central database.
This would only work if the card stores the last couple of transactions - if another validator sees the card it would probably notice the transaction is already on the card, and not reapply the transaction.
Again, this is all speculation - but if it works like this, then the card would reliably validate every time, without a real-time connection from the validator to a central database.
It would mean the validators would have to talk to the database once a day at least, which is probably acceptable for a validator in a moving vehicle.