Settlement

A gift card cannot be locked

The merchant owns the balance and does not know we exist, so it will not cooperate. Nothing can reserve or hold the card. Two people can hold the same number at once, and only the merchant's own ledger says who spent it. For some merchants we can read that ledger. No one can reserve against it.

So the design keeps the race short. It checks the balance before and after, and settles on what happened.

The reveal window

1. Buyer taps use.
2. Balance check before revealing anything. A dead card never reveals.
3. Reveal, with a countdown. Escrow held throughout.
4. Balance check after the window closes.

In store, "escrow" is a hold on the shopper's own card, placed when the barcode opens. "Release to the holder" captures that hold, and "refund the buyer" cancels it, so the shopper is never charged. No seller is paid yet. See Where the money goes.

On the card-hold rail there are five outcomes. The crypto rail has none of them; see below.

Balance movement	Outcome	Money
Fell by ≥ what the buyer bought	consumed	Release to the holder
Fell by less	partially_consumed	Release (split tender is normal)
Unchanged	unused	Refund the buyer, card returns to the pool
Fell, but buyer disputes	contested	Dispute window; escrow held
Could not be read afterwards	undetermined	Hold. Neither party paid

Why the pre-reveal check refuses on an unknown balance

A revealed code cannot be recalled. With an unreadable balance we do not know what we would hand out, so the reveal is refused and the buyer refunded automatically.

The balance-watch sweep deliberately does the opposite, leaving the listing up on a failed probe: failing open costs nothing there, and the next sweep decides. Here, failing open would hand over a live card number blind.

Why undetermined holds rather than refunds

Without a reading after the window, we do not know if the buyer got value. Refunding could pay a buyer who spent the card. Releasing could pay a holder for a scan that failed. So the money stays in escrow until a retry reads the balance or the deadline sweep resolves it. It is deliberately the one outcome not resolved automatically.

On the crypto rail, an open is a sale

Salvo Pay, the crypto rail, settles when the card opens, not after the till. Nothing above applies to it. At the till (the second escrow, SalvoEscrowV2) the one tap pays for the value used of each card, opens them all, and puts a deposit at face on what is left on the last; Done has nothing to capture.

• The money moves before the card reaches the phone. The shopper's one transaction pays the escrow and records the card as opened. Lit releases the card only once that is final on chain.
• No balance check after. A shown number cannot be taken back, so a refund after the sale would hand out a free card. Nothing goes back to the shopper on a timer.
• The check comes first instead. At Best Buy and Nike the template can read the balance before it signs a ticket, so a dead or short card is never sold and the shopper is never charged for it. Every listing made today is unchecked, because those readers have not been tried from Lit. That is how Target and Walmart work anyway.
• At a store nobody can check, a dispute holds the seller's payout 48 hours longer and counts against the seller in public. The seller can refund any part. A new seller cannot sell a card over $25 until finished sales have paid them that much.
• The seller is paid 24 hours after the Load, by anyone's call. Our 15-minute job makes that call when the rail is on and its keeper key is set, and the seller can make it from the sell page with Get paid.

Status

Built, and deployed on Tempo's test network on 2026-10-10. Its live smoke passed. Not reviewed: on the testnet a listing is taken as the operator's own card. Off unless ESCROW_RAIL=testnet. Our refund, reconcile and fulfilment code skips every crypto-rail order, and tests prove our wallet can never pay one.

Evidence tiers, for platforms with no balance

A balance-blind platform has no before/after comparison, so a channel that only settles that way cannot operate there. So settlement becomes a hierarchy, and each settlement records its tier.

Tier	Source	Holdback	Why it ranks here
1 · merchant_balance_delta	The merchant's own ledger, read twice by us	None	Strongest available
2 · merchant_applied_amount	The merchant's checkout stating what it applied	None	Merchant-asserted
3 · buyer_confirmation	The buyer says it worked	Yes	Only tier where the evidence supplier benefits from it

Merchant-asserted beats buyer-asserted, always, because the merchant has no stake in our settlement and cannot profit from misreporting it. The buyer can.

Tier 2 is not a balance lookup: it says what this transaction consumed, not what remains.

At a store nobody can check: silence, and "it didn't scan"

Silence counts as worked. With no answer by 20 minutes after the window closes, when the settle credential has died and the shopper can no longer answer at the register, the stale sweep settles the code as used. It used to hold, then refund after 24 hours: a shopper who said nothing got their money back and kept a number a register had seen. This matches the crypto rail, where an open is a sale. Like every tier-3 settlement it opens the 48-hour dispute window with its holdback, and the report form stays open for it.

"It didn't scan" keeps the hold. A No used to cancel the hold and retire the card, so it was a free card too. Now the shopper says why (it did not scan, or the card was declined), the hold stays uncaptured, and the same card is listed again, first in line, on the same row and seal. The next shopper's try decides it:

Next shopper	The first shopper's hold
Their scan works	Released
They say No, for any reason	Taken at the normal price, with any deposit behind it. The next shopper is refunded from their own hold, the card is retired, and a person is told, who can undo it
Nobody comes in time	Released a day before the bank would drop it. The card stays marked: the next shopper's No refunds them, and the card is retired with a person told
The till told them not to scan it	Waits, as it was: only the next shopper's own hold goes back

This is open decision 2 as approved: a false "it didn't scan" gains nothing. Every No counts against the shopper who gave it.

The router uses a first-in-line card whole, before any other card, wherever it fits. The hold sweep finds a kept hold by the KEPT_HOLD event on its order.

Never silently downgrade

Skipping available stronger evidence is a bug. If merchant evidence exists, a buyer's account cannot override it: the settlement refuses rather than resting on the weaker claim.

The three controls on tier 3

Because tier 3's evidence comes from the party it benefits:

1. Buyer reputation gates access. Routinely-denied claims get the settlement refused outright.
2. A holdback is withheld from the holder through the dispute window, sized per return-risk category from the cash advance's table. An unstated category defaults to the strictest.
3. A dispute window opens on every tier-3 settlement, even with no conflict, because there is no independent record to contradict it later.

The holder bears the cost of these controls on platforms where we cannot see the balance. It is the price of operating there at all.

Full drain, and why the in-store channel breaks it

The strongest protection against a leaked card number is that the card is empty: match the basket to the whole balance, and a leak is worthless.

Full drain works in ecommerce: the basket is known before any reveal, so a plan leaving a large residual can be refused.

In a shop it mostly does not. Nobody knows the basket until the cashier finishes scanning. A $50 card against a $32 basket leaves $18. Against an $80 basket it leaves nothing and needs split tender. So full drain largely does not apply in store.

The residual cap becomes the primary tool

What we can compute before revealing is the exposure the reveal creates: card value beyond what the buyer paid for, handed over as a live number. That excess is the residual we control. If it exceeds the cap, the reveal is refused and the buyer refunded before any code is shown.

"What the buyer paid for" is the value their purchase applies at the register, not the price they paid. A shopper who pays $54 for all of a $60 card at 10% off leaves $0 on it, so the exposure is $0. Measured on the price, that card showed $6 and was refused at a $5-cap store, and listing had to cap the discount to match. Each card's applied value is recorded on its order at buy (SPEND_LEG), the reveal measures against it, and there is no ceiling on the discount any more. An order with no record is measured on its price, which can only refuse more.

Relisting a partly-used card

Retiring every partially-consumed card is safe but quietly ruinous: split tender is the normal case, so retiring burns most of the value on most cards.

A balance-readable platform reads the remainder. A balance-blind one can only infer it: face value at listing, minus everything we applied. That upper bound is exact only if nobody else spent the card meanwhile, and there holder self-use is invisible and explicitly permitted.

So the bound is never priced directly. It gets a haircut, and if the result does not clear the residual cap, the card is retired, with the loss booked as a number somebody can watch.

The till lists a remainder again when a deposit stands behind it. The shopper whose purchase leaves part of a card puts down a deposit for what is left, at face. When their code is settled as used, the rest of the card goes back on sale on the same row and the same seal, first in line for the next shopper at that store. Face and price stay as listed, so it sells at the seller's own discount. There is no haircut while the deposit stands: if the remainder turns out short, the deposit makes the next shopper whole. Once the deposit is gone the haircut comes off its price, never off the value planned.

• What is left: read from the card where the store lets us, otherwise what the plan left (SPEND_LEG on the order).
• Too small to list: under $1, or priced under 50c. Retired, and booked. The till asks no deposit for a leftover under $1.
• No deposit: retired, and booked. Only the card till's Pay places a deposit, so a remainder left any other way is retired, as before.
• The next shopper's order names the order that left it (REMAINDER_OF).
• Sold at the till only. The whole-card list and its buy leave it out: they would sell a few dollars at the whole card's price.

The relist is the release's own swap, executing -> offered, pinned on the window the release decided, so it happens once or not at all. The capture follows it, as it follows every release, and the hold sweep finishes a capture a request did not.

The deposit, on the card rail

The deposit is a hold on the shopper's card, never a capture and a refund. A captured deposit would be money we hold for a shopper, and the card processor keeps its fee on a refund. A cancelled hold costs nothing.

• Placed at Pay, beside every card's own hold, all at once, and counted in the same allowance. If the card will not hold it, the purchase is planned again with no leftover; if that cannot cover the total, nothing is charged.
• Released when the rest of the card proves itself: the next shopper's balance read at Best Buy and Nike, or their code going through at Target and Walmart with no report for two hours. Also released when nothing stands behind it, and a day before it would lapse. Then the rest stays first in line with no deposit, and the haircut comes off its price.
• Taken for the seller when the next shopper finds the rest short, up to what is missing. At Target and Walmart their word decides (open decision 1): they are refunded from their own payment, which is still only a hold. At Best Buy and Nike, balance-watch finding the rest lower while it is on sale is proof too: the deposit pays what is missing before the listing is lowered or cancelled, and it does not count against the first shopper. A shopper with two reports or shortfalls in 30 days gets no remainders and no part-used last card.
• Never taken under the smallest card charge. A shortfall under 50 cents is written off and booked, never rounded up to 50 cents.
• Nothing is taken before the register takes the card. When the total goes up with the part-used card on screen, the price of what more it covers is charged from the deposit only once that card has worked. A card that then does not scan, or a total lowered again, has taken nothing.
• A new deposit is held before the old one is touched. One capture releases the rest of a hold, so before anything is taken from a deposit, what is still left on the card gets a deposit of its own. The rest the shopper has seen is never on sale with nothing behind it.

A remainder at Target or Walmart is captured two hours after it works, not at once, so a report in that window cancels a hold instead of refunding a charge.

At Best Buy and Nike the till's read bills what the card paid. Both reads bracket the shopper's own window, so whatever left the card between them is theirs. More is taken, at the card's price, from their own deposit. Less than planned is billed less, in one partial capture, only within the cap and only behind a deposit for all that is left, at face, held first: a typo within the cap costs nothing. When that deposit cannot be held, or the rest cannot be listed, the card is billed as planned, and the old deposit stays behind what the plan left: what the register did not take was paid for at Pay. Past the cap the read credits nothing, since a deposit is released a day before it lapses and the rest would then wait on sale with nothing behind it: the card is billed as planned. When what the shopper left on it is past the cap too, the next shopper's open would refuse it, so the card is billed whole, the price of what the plan left taken from the deposit behind it, and the card is the shopper's (spec 5.4). Nothing left on a number the shopper has seen goes unbilled with nothing behind it, past the plan's own leftover. Never at a store nobody can check. The shop's own orders, which hold no deposit, are charged their price as before.

A decided take is written before its money. The take from a deposit is recorded before the capture, so one that fails on a passing error is finished by the hold sweep on that same deposit, even when a newer deposit now stands behind the rest of the card.

"Do not scan this card" decides nothing about the card. When the total comes down past what can stay on the card on screen, the till says not to scan it. On the rest of someone's part-used card, or a card behind a kept hold, only this shopper's own hold goes back, and the card goes back on sale as it was listed: the deposit or kept hold behind it waits for a real scan.

A kept hold released before anyone tried the card leaves the card marked. The next shopper's No on it refunds them, and the card is retired with a person told. It is never sold as plain stock, where a No kept that shopper's hold and the one after paid for it.

The till's codes come one at a time: every card is held at Pay, and each code opens only when the shopper taps Next. A code never shown is closed by Done ("Register says paid"), by a report, or by the hold sweep after half an hour: its hold is released and its card goes straight back on sale.

Status

Built, not proven. Every tier, every refusal, and the relist arithmetic are implemented and tested against injected balances. No real card has been revealed at a real register, and no real merchant balance has ever been probed by the production reader.