Three events, not one, when a return machine accepts a bottle

A bottle-return point that writes a single "recycled" row will lie the first time the link drops.

Split one visit into three facts the device can prove on its own:

1. accept — the machine matched a container (barcode or shape) and committed to taking it. Persist this on the device before the compactor or shutter moves. Key it on machine id plus a local sequence, not a server clock.
2. store — the container was actually retained (compacted or dropped in the bin). An accept with no store is a jam, or a person who pulled the bottle back out.
3. payout — the deposit or reward was issued (cash, voucher, or scheme credit). This fails on its own when the scheme API is down. Queue it. Do not roll back the accept, or you end up with a bottle in the bin and no record.

Replays after reconnect should return the original ids. If accept and payout share one transaction, a timeout makes you either double-pay or delete a container you already kept.

A short public note on what the machine checks per insert: how a reverse vending machine handles one container.