Policies & trust

Your policy is the set of local rules the acceptance gate evaluates on every settle, before any money is captured. It's how you decide which agent purchases to accept, hold for review, or reject — by dollar amount, velocity, authorization (mandate), agent reputation, and intent. This guide is the practical "how do I set it up" recipe; the Policy concept is the field-by-field reference.

Start from a preset

Adopt a posture wholesale, then tune individual fields. The presets are functions (each call returns a fresh, isolated policy), so one merchant can never mutate another's:

import { BALANCED } from '@veto-protocol/checkout';

const policy = BALANCED();
// requireMandateOverUsd: 20, minReputationTier: 'standard', maxPerTransactionUsd: 500,
// maxPerAgentPerDayUsd: 2000, ratePerAgentPerHour: 60, ratePerAgentPerDay: 300,
// holdForReviewBelowTier: 'cautious'

import { STRICT } from '@veto-protocol/checkout';

const policy = STRICT();
// requireMandateOverUsd: 0 (mandate for ANY spend), minReputationTier: 'trusted',
// maxPerTransactionUsd: 100, maxPerAgentPerDayUsd: 250,
// ratePerAgentPerHour: 10, ratePerAgentPerDay: 50, holdForReviewBelowTier: 'trusted'

import { OPEN } from '@veto-protocol/checkout';

const policy = OPEN();
// requireMandateOverUsd: ∞ (never require), minReputationTier: 'risky',
// maxPerTransactionUsd: 10000, no daily cap, no rate limits, never holds

import { createCheckout, BALANCED } from '@veto-protocol/checkout';

const checkout = createCheckout({
  // …
  policy: { ...BALANCED(), maxPerTransactionUsd: 250, requireMandateOverUsd: 50 },
});

Every field is optional — safe defaults fill the rest. A field you don't set stays unset, and "no cap" is a distinct, legitimate posture from "default cap": leaving maxPerAgentPerDayUsd undefined means no daily cap, not the preset's value.

The dials, and the code each fires

The gate evaluates these in order and returns a verdict with one or more stable reason codes. Set what matches your risk:

How caps, mandates, and reputation interact

The three trust inputs aren't independent — they combine into one verdict:

Editing policy on the hosted plane

Hosted policies are immutable and versioned — you never mutate an active policy in place. Each change creates a new inactive version; publish flips it active in one transaction. A receipt embeds the policyHash, so every order provably names the exact policy version that accepted it.

curl -X PUT https://api.veto-checkout.com/v1/policy \
  -H "Authorization: Bearer veto_test_…" -H "Content-Type: application/json" \
  -d '{ "body": { "requireMandateOverUsd": 50, "maxPerTransactionUsd": 250, "minReputationTier": "standard" } }'
# → { "version": 2, "hash": "…", "active": false }

curl -X POST https://api.veto-checkout.com/v1/publish -H "Authorization: Bearer veto_test_…"
# → { "published": true, "active_policy_version": 2 }

Prefer the CLI? veto policy show prints the active policy and veto policy set <field> <value> creates a new version in one line.

Validate before you self-host

Self-hosting, run the same shared validator over your config before you ship it — it catches the foot-guns at build time instead of at an agent's first request:

import { validateConfig } from '@veto-protocol/checkout';

const findings = validateConfig(myConfigInput);
if (findings.length) throw new Error(`config invalid: ${JSON.stringify(findings)}`);

Recommended starting points