A shop that can trade both ways

A merchant is online when it can be, and carries a card when it cannot. The record decides what happened; the card is how the shop keeps serving when the record is unreachable.

Two modes, one ledger

	Online	Offline
Where the float lives	The merchant's account at the issuer	A merchant secure card, holding notes in its slots
How a sale settles	The issuer moves the record; instant and final	The card moves the note; provisional until reconciled
What proves the customer's token	The issuer's record, checked live	What the card can prove on its own — see the constraint below
Exposure limit	None beyond the float balance	The value physically on the merchant card

The offline mode is not a second system. It is the same instruments, moved by the erase-first protocol, with the record catching up at the next connection. What changes is who is being trusted for the interval: online, the issuer; offline, the merchant's own float and the chip in the customer's hand.

Online: the shift is arithmetic

float       19 notes · 47.00   {100:12, 500:5, 1000:2}
sale        $10 presented, $7.60 purchase
change      240¢ → customer purse (no note matches)
float       unchanged: the $10 retires to the issuer's shelf
sweep       end of shift: collected notes → credit; float topped up

Because change comes from the float and the record does the moving, an online till never waits for a signature. That is what makes a queue move.

Offline: the card is the float

before      merchant card holds 2 × $5 and 4 × $10
sale        customer card $10 → merchant card; merchant card $5 → customer card
after       merchant card holds 1 × $5 and 5 × $10
later       on reconnection, the merchant card's contents are read and reconciled

Two readers do this: one for the customer's card, one for the merchant's. The protocol is the erase-first one — the sender's slot is relinquished before the receiver stores — so an interruption may destroy a note but cannot create two.

The constraint that decides whether offline is real. A 64-byte slot holds a type, a denomination, an eight-byte identifier and reserved space. It cannot also hold a 64-byte ECDSA signature. So an offline till cannot verify the issuer's signature over a token it is handed, because the signature is not on the card.

Three ways to close that gap, and they are not equivalent:

A short message authentication code in the reserved bytes — 8 to 16 bytes, keyed by the issuer, verifiable with a key the till holds. Cheap, and the right answer if the till can be trusted with the key.
The card's own attestation — trust that the chip is a genuine enrolled card and that only such a chip can have produced the token. Says nothing about whether the token has already been spent somewhere else.
Accept the risk within a limit — take the note, cap the value per card per day, and reconcile. This is what offline card payments do, and it is honest only if the cap is enforced by the till rather than promised in a contract.

Until one of those exists, "offline sale" means the merchant is trusting the customer's chip rather than the issuer's signature — which is a defensible pilot position, but only if the limit is small and stated. It should not be described to a merchant as verified.

Capacity, which is what pushes a shop toward the card

Each note is an instrument in a slot. Ten slots per card is a shift's float at best, and a merchant card carrying several secure elements multiplies it:

one chip      10 slots
ten chips    100 instruments on one card
             2 × $5, 4 × $10, 20 × $1 and still room

The reader sees one card, so the till addresses chip, slot rather than slot, and each chip is separately provisioned and registered with the issuer.

What exists today

Online float and till settlement — built and tested: float listing, sale with float change, purse for odd remainders, atomic retirement of the presented note.
Merchant receiving an instrument on its own card — built: the sale can credit the shop as a note rather than a balance.
Offline card-to-card sale — designed, not built. Needs the applet's erase-first transfer wired to two readers, plus the authentication decision above.
Merchant role — not built. Any account can currently call the till endpoints; a shop cannot be exposed until that is a checked role.
End-of-shift sweep — not built. Collected notes should redeem to credit and top the float back up.

Sandbox deployment, USD, English. Test values, not money. This page separates what is built from what is designed, because a merchant will ask which of the two they are being sold.