4 ms·
That’s exactly how online top-ups, and credits/refunds, work with the Oyster card system. In the old days you’d nominate a specific station, and the credit wou
by Reason077 2y ago
That’s exactly how online top-ups, and credits/refunds, work with the Oyster card system.
In the old days you’d nominate a specific station, and the credit would be transferred to the card the next time you tapped in at that station.
But now days I don’t think you need to do that: presumably it maintains the balance primarily on the server side now rather than on card.
- lxgr 2y agoI think Oyster cards are still stored-value based, but I suspect that either the backend servers and connections are now fast enough to poll pending top-ups in real time, or they just fan out the pending top up dataset to all turnstiles. I remember using that feature in the SF bay area, and while it took a day for the top-up to actually propagate to all readers, it even worked on buses, so they must be uploading that data everywhere. That type of connection needs to be there in any system that supports lost/stolen card value recovery, in any case, since that's how card block lists are distributed.
- Reason077 2y agoThe Oyster card balance is certainly maintained online in real-time (or near to real-time) since you can view it in the Oyster card app/website. But yes, for speed/redundancy they are still probably using the stored value balance too.
- lxgr 2y agoIt's most likely near real time. TfL likely need that mechanism primarily to synchronize the list of blocked open-loop bank cards with unpaid balances to all readers. Faster Oyster transaction list updates and any-station remote top-ups are probably just a side effect of that. Clipper doesn't (yet) support open-loop bank cards yet, so for them, it's probably enough to update more remote readers every time the bus goes back to the depot, for example.