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, replays, and crash recovery do not produce duplicate settlements or duplicate refunds. 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 quote pays only for the request it priced.
• When settlement after the handler is rejected, adapters withhold the output and send a fresh 402.

Tollstile does not guarantee

• That your handler executes exactly once.
• 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.