Concept guide
Acceptance-gated settlement
Acceptance-gated settlement means the payment completes only after the agreed conditions return an accepted result. Depending on the payment path, funds may be released, captured, or made claimable.
The verdict controls the next payment action
Settlement is the step where a payment is completed. Before that can happen, the verification layer produces a signed result and an approved amount. Spoolis doesn't submit settlement before its verdict. Your runtime or payment system checks the result, then performs only the action its own authority and rail allow.
If the work passes, that action may capture an authorization, increase a cumulative voucher, or add an accepted unit to a later batch. If it fails, the authorization can remain uncaptured, the voucher can stay at its prior amount, or the unit can be left out. An uncertain verdict should not silently become a pass.
Each settlement policy names a different payment shape
direct_atomic_payment: payment and deterministic fulfillment happen together. No separate verification gate is needed.manual_authorization_capture: a licensed payment provider authorizes an amount first, then a passing verdict allows capture later.metered_session: a bounded session accumulates value as verified units pass, usually through cumulative vouchers.batch_channel: many verified interactions accumulate before one later claim or settlement.pay_then_verify: payment intentionally happens first. Verification supports records, quality control, or a later remedy rather than blocking payment.external_settlement: another platform owns payment execution, while Spoolis supplies the verification result it may use.
Release can happen by capture, voucher, or batch
Manual authorization and capture
You authorize a bounded amount through a payment provider. After the work passes, the provider captures the approved amount. This fits work that finishes later and has one or a few release points, subject to the provider's authorization windows and account requirements.
Cumulative vouchers
You sign a voucher for the total earned so far. Each passing unit raises the cumulative amount. A failed unit leaves it unchanged. The provider later settles the latest valid voucher. This can reduce the number of final settlement operations for incremental work.
Batch settlement
Multiple verified interactions build up and get claimed together. This can lower the overhead for each interaction, but it introduces batching rules, provider exposure, replay handling, and recovery requirements that must be tested.
What is live and what is simulated today
Current product status: production settlement is live. On Base mainnet, verification-gated settlement of USDC has run end to end: the configured adapter, the connector that carries out a payment path, settled the exact earned amount and the quoted fee under buyer-granted, bounded authority. Stripe card settlement is production-capable for human payment methods. Sandbox and demo settlement remain simulated and move no money.
Separately, a live Tempo testnet run released the exact earned amount in about 832 ms at a recurring settlement cost of about $0.009, excluding the one-time Safe deployment. Testnet pathUSD has no production monetary value, and that result doesn't establish production readiness for the Tempo path.
The repository models these policies and rail capabilities. Manual capture and x402 batch paths are architectural candidates, not published production integrations. Payment path documentation records the implemented adapters and their availability boundaries. Spoolis never receives the principal's signing key or payment credentials. The receipt is signed before settlement.