Going to production
Swap the in-memory store for durable storage, pick a policy posture, validate before publishing, and harden the deployment.
The SDK is production-shaped out of the box; a few choices take it the rest of the way.
Swap the store
The default MemoryStore is single-process. Implement the SessionStore interface over
Redis/Postgres for durability and horizontal scale — it's the persistence seam.
import { createCheckout, type SessionStore } from '@veto-protocol/checkout';
class RedisStore implements SessionStore {
// create / get / update / findByIdempotency / countRecentByAgent /
// sumRecentByAgentUsd / isMandateConsumed / consumeMandate /
// tryConsumeMandate / releaseMandate
}
const checkout = createCheckout({ /* … */, store: new RedisStore() });tryConsumeMandate must be atomic (check-and-set). It's the double-spend defense — two
concurrent settles of one single-use mandate must not both win.
Validate before you publish
Run the shared validator over your config to catch problems before agents hit it:
import { validateConfig } from '@veto-protocol/checkout';
const { ok, reasonCodes } = validateConfig(myConfigInput);
if (!ok) throw new Error(`config invalid: ${reasonCodes.join(', ')}`);Checklist
Pick a posture
Start from STRICT / BALANCED / OPEN, then tune caps and rates
to your risk tolerance.
Wire a real rail
Inject an x402 facilitator for on-chain settlement; keep
mock out of production rails.
Publish your JWKS
Serve /.well-known/jwks.json so buyers can verify receipts.
Verify webhooks
Verify every delivery against the raw body with the shared secret.
Merchant privacy
What an on-chain settlement reveals, what per-checkout receiving addresses hide, and the honest tradeoffs — plus where pooling fits for full revenue privacy later.
Agentic Checkout Protocol
The self-describing Veto Checkout wire protocol agents talk to — every endpoint, status code, and error shape. All bodies are JSON; status codes are used semantically.