The cards are stored-value - meaning that the card actually stores how much money it is worth. For cost saving and legacy reasons, most Clipper readers are offline and simply read and update the card value.

When you add value online, there is no way for the service to write to your card, so instead Clipper terminals throughout the system are informed of the value add and apply it next time they interact with your card. Online terminals, e.g. most vending machines, frequently synchronize with the online service and can transfer value added online almost immediately. Offline readers like those on buses, though, obtain a batched list of online value adds from time to time, often in the bus yard overnight via short range wireless networking - but in some areas this may happen less frequently than once a day. For Muni, I believe it should always happen overnight.

When you add value at Walgreen's, they set your card on a terminal that updates it directly.

This limitation is common to all stored value systems with offline terminals, including all Cubic transit card systems such as Clipper, Oyster, SmarTrip, etc. It's a compromise involved in rolling such a system out to a vehicle network without the expense of long range radio networking in every terminal - these systems were designed and implemented well before this was practical.

As a side note, design of offline systems that would generally be online is an interesting problem. For example, Onity/TESA door locks store an incrementing counter for determining the validity of keys. If you need to revoke a key, you make a new key with a higher counter value and insert it in each lock. When the lock sees a larger number, it increments its internal counter, and the old key will then have too small of a number and not work.

What's even trickier is when you want thorough logging. Clipper terminals report back card usage information when they update on value adds. Some locks struggle with this - for Onity locks, retrieving user history requires connecting a bulky diagnostic device to the lock. An interesting solution is that used by Cyberlock. In that system, an audit log is stored in the key itself and the key has a short expiry, forcing the holder to frequently reprogram it, during which the log is retrieved. The locks must still store a log too in case of disappearing keys, but it allows for fairly accurate logging without frequently having to visit every lock.

Thanks for that post — that's interesting, and explains a considerable bit. I ride CalTrain often, but their readers are bolted to the concrete… I'm surprised they're not updated more frequently? (Even the CalTrain operators say to give a week.)

The whole "tag on/off once at the beginning of the month" (which I've always thought was the weirdest thing…) then is to sync the on-card value w/ what you own I suppose, so that it scans properly on their readers. Now I wonder that given that I buy from Walgreens, if that's an absolute necessity, or a hardship imposed by people being too lazy to explain the inner workings of the card; it's a pain b/c if you forget to tag off, you get charged full-fare (and your monthly pass is deactivated until you re-add value to the card…), as I'd much rather just buy the monthly pass and not have to do the monthly tag dance.

Probably because they have "the specific scanning hardware" mentioned?

If it's the case that Walgreens has "the specific scanning hardware" (note that the parent to my comment had that hardware on a bus), then that's exactly my point.

I don't ride the buses; I take CalTrain. There's three pieces of hardware of concern here: the scanner that checks your pass, the Clipper website, and whatever Walgreens uses. The scanners take a week to pick up payments through Clipper (first party), and instantly from Walgreens (third party). I find it exceptionally odd (and mightily inconvenient) that a third-party is able to add value into the system faster than the owners of the system themselves.

(edit: and see the sibling response to yours from jcrawfordor for more info!)