VetoVetoDocs
Guides

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.