Guarantees

Stating limits is part of being trustworthy. This page is the contract.

Tollstile guarantees

• A protected handler never runs unless an access policy grants access, a balance reservation succeeds, or a payment proof has been verified against the quoted or configured price.
• Retries and recovery reuse operation keys to avoid duplicate settlements and refunds, subject to the rail/provider contract and the verification limits stated on each rail page. Separate requests without an idempotency key can create separate charges. Every rail must be able to look up a charge at its provider; rails that cannot are refused at startup.
• Every charge transition is recorded in your ledger before its effect is acknowledged.
• Ambiguous outcomes are recorded as unknown and surfaced for reconciliation.
• A single-use proof must match its quote commitment; the commitment covers the route, request, or custom fields you selected.
• When settlement after the handler is rejected, adapters withhold the output and send a fresh 402.

Tollstile does not guarantee

• That your handler runs only once across failures and retries.
• That a response reaches the client after it is sent.
• That costs your handler incurred before failing are recoverable.
• The behavior, availability, or finality of a rail's provider.
• A refund for a payment that moved during verification on a rail that cannot refund. Tollstile records it as settled with failed fulfillment and reports it; you refund the payer yourself.

Fail closed

A failure while verifying access always denies the request: 402 for payment problems, 503 for infrastructure failures. There is no code path where an exception results in serving the protected resource.

Never takes custody

Tollstile verifies proofs, asks the rail's provider to settle, refund, or release, and records the outcome. It never holds balances, never routes funds through its own accounts, and never converts assets.