The card rail funds a budget with one manual-capture authorization: the buyer's card is authorized once, for the cap, and that authorization IS the funded ceiling. Dynamo never holds card balances, never stores value, and never draws on a card-on-file — the hold is the budget.
Dynamo runs the PSP platform pattern (Stripe in this repository, TEST mode only):
openBudget places a manual-capture authorizationfor the cap on the buyer's payment method. Payment method tokens only — no card numbers ever touch the system.
authorization — never more than signed vouchers bill, never beyond the ceiling.
transfers split captured funds per voucher totals. Every Dynamo application fee is its own explicit, ledger-auditable row tied to the settlement that produced it.
released back to the buyer's card — the mirror of escrow release.
refunded units reversed and netted against the payee (holdback & refunds).
the last funded voucher. Nothing accrues beyond the funded ceiling — "ceiling-dead" is a first-class halt reason, not an error path. make demo-card-decline runs the full sequence.
stops the stream — never a silent over-capture, never a retry against a bigger hold the buyer didn't approve.
The phrase is chosen for accuracy. Card networks have a specific meaning for escrow, and this is not that: the buyer's bank holds the authorization, the network's rules govern it, and Dynamo's engine decides only how much of it signed vouchers justify capturing. What the protocol adds is the enforcement graph — caps, envelopes, revocation, voucher-gated captures — on top of a hold the cardholder already understands.
Card sessions end with the engine==PSP table: every intent, capture, transfer, refund, and release the engine believes happened, matched against the PSP's own records, to the cent. make demo-card prints it; make demo-evidence exports it as an offline-verifiable evidence bundle with the PSP references embedded.