Settlement guide

Understanding settlement paths: Stripe, Tempo, and external settlement

A signed Outcome Receipt records verified work and earned value before Stripe Connect, a gated Tempo testnet adapter, or an external platform applies its own settlement lifecycle.

Published August 12, 2026Availability: Stripe Connect is production-capable; Tempo paths use Moderato testnet; external settlement executes outside Spoolis

One receipt, different execution lifecycles

Spoolis applies the agreed economic rule to the verification results and signs an Outcome Receipt that records what passed and what was earned. It does not always establish the underlying real-world truth itself. Settlement infrastructure answers a different question: how an authorized payment action is executed.

The receipt can be verified for authenticity with @spoolis/receipt-verifier. Its Ed25519 signature proves that the receipt is genuine and unaltered, not that every underlying check is reproducible or that payment was authorized, captured, or settled. This separation lets the same receipt shape sit beside manual capture, a buyer-controlled testnet transfer, or a customer platform that executes payment elsewhere.

Unitized outcomes come before settlement

When a Spool defines units and a unit price, verification runs unit-scope checks per unit and batch-scope checks across the set. A determinate receipt records accepted and rejected counts, rejection reasons, and earned value calculated as accepted units multiplied by the unit price.

The automatic settlement transition captures an overall pass in full. For unitized work, a partial result captures the exact pro-rata earned amount through the same adapters. Fail and uncertain results stay unsettled for review. External systems can inspect the signed receipt, but they must supply their own payment policy and authority.

Stripe Connect: authorize, then capture

Availability: production-capable when Stripe is configured for a human payment path.

The Stripe Connect adapter creates a PaymentIntent with manual capture, a connected-account destination, an application fee, metadata containing the Spool ID, and an idempotency key tied to the Spool and transition. Supplying a payment method asks Stripe to confirm the intent.

On an overall pass, the adapter requests capture in full. A partial unitized result captures the exact earned amount. Fail and uncertain results hold locally rather than capture. Cancellation or expiry cancels the PaymentIntent. Stripe remains the payment provider and connected-account system.

Tempo keychain pilot: authorize, verify, transfer

Availability: allowlisted, capped, and on Tempo Moderato testnet with testnet pathUSD.

The adapter is selected only when SETTLEMENT_ADAPTER=tempo-keychain-pilot, the API key ID is allowlisted, and the amount is from $0.01 through $5.00. A failure in any gate falls back to simulation before a commitment. A committed Tempo Spool stays pinned to its adapter and fails closed if that adapter becomes unavailable.

Authorization creates a buyer-controlled delegated key limited by recipient, testnet pathUSD, transfer selector, maximum amount, and time window. On an overall pass, the adapter requires a signed passing Outcome Receipt, verifies it against configured trust material, checks receipt earnings against the Spool amount, and sends the exact earned amount on testnet, including the pro-rata amount for a partial unitized result. Fail and uncertain results hold.

Tempo MPP sessions: open, present, release

Availability: Labs, feature-flagged, testnet-only, and outside general adapter selection.

This separate adapter opens and verifies a buyer-owned MPP session on Tempo Moderato testnet. On an overall pass, it requires a buyer voucher whose cumulative amount equals the Spool amount; on a partial unitized result, it requires a voucher for exactly the earned amount and releases the remainder. It presents the voucher and validates the returned testnet settlement receipt. Fail and uncertain outcomes hold. Cancellation or expiry releases the session.

External settlement: verify here, execute elsewhere

Availability: a policy boundary, not a Spoolis settlement adapter.

For an external actor, the policy layer recommends external_settlement with no candidate rail because the customer platform owns payment behavior. Spoolis can compile the agreement, run verification, and issue the receipt while a marketplace, business system, or agent platform decides what action the result permits.

Spoolis does not claim to observe or control final settlement on that platform unless a separate integration reports it.

Each path keeps its own authorization and finality rules

  • Stripe Connect: licensed-provider custody, human payment methods, manual authorization, and deferred capture.
  • Tempo keychain pilot: buyer-controlled delegated authority and an exact-earned transfer on testnet after independent receipt verification.
  • Tempo MPP sessions: protocol-contract custody, session capacity, cumulative voucher presentation, and testnet settlement validation.
  • External settlement: no Spoolis execution adapter. The customer platform owns authorization and payment state.

The common input is the verified outcome: the signed receipt stays a verification artifact while each path keeps its own authorization, execution, and finality rules.

Read how Spoolis routes a payment for selection, when Spoolis decides and when you decide for control boundaries, and the MPP and x402 guide for protocol integration. Use payment paths for the concise technical model.

Understanding settlement paths: Stripe, Tempo, and external settlement · Spoolis