Card mode funds the same budget object with a card authorization-backed budget: ONE manual-capture authorization on the buyer's card is the funded ceiling. Captures never exceed it, split transfers pay each service node's connected account per voucher totals, and refunds/releases mirror the escrow semantics. The rail runs Stripe TEST mode only at this stage — a live key is a configuration the tooling refuses at parse time.
Launch instances run Control Mode only; the card rail is disabled at the configuration level and enabled per instance, on request — sandbox (TEST mode) first, always. A half-configured card mode refuses to boot; test payment methods only (e.g. pm_card_visa); no card numbers ever touch the system — payment method tokens only.
Nothing in your code: openBudget({ funding: "card", ... }) becomes available on your instance, and the same flow settles against the authorization instead of the control ledger.
card-on-file drawdown, no top-up without a fresh explicit authorization.
vouchers bill, and never beyond the authorized ceiling.
engine halts cleanly at the last funded voucher — nothing accrues beyond the funded ceiling.
other rails (holdback & refunds).
More depth: card authorization-backed budgets. Every card-rail session can be exported as an offline-verifiable evidence bundle — the dispute-ready record of what was signed, delivered, settled, and refunded.