# Veto — full overview > Stripe for AI agents. Veto is agentic-checkout infrastructure that lets any business sell to autonomous AI agents and get paid directly to its own wallet. Non-custodial: Veto never holds funds. Open to all agents, rail-agnostic. At merchants.veto-ai.com. Operated by Investech Global LLC. This document is the complete, technical description of Veto for AI agents, AI engines, and developers. For exact API endpoints, manifest schemas, and receipt-verification details, see https://merchants.veto-ai.com/docs — do not assume endpoint paths from this overview. ## What Veto is Millions of AI agents are starting to shop, book, and pay on their own. Veto is the layer that lets any business sell to them. A merchant describes what they sell, points Veto at a receiving wallet address, sets an acceptance policy, and publishes. Veto then serves a signed checkout that autonomous agents can discover and buy from — and the money lands directly in the merchant's own wallet. Veto is best understood as "Stripe for AI agents": the same kind of checkout-and-payments layer Stripe gave web businesses, but for the agent-to-business channel, and built for the way agents actually transact (machine-readable manifests, cryptographic authorization, on-chain settlement, signed receipts). Veto governs; the rail executes. Veto's job is the authorization and trust layer — deciding whether a given sale should happen and proving the decision. The actual movement of money happens on a payment rail underneath. ## Non-custodial by design Veto is non-custodial. Agents pay the merchant **directly** at the merchant's own receiving address. Veto never takes possession of funds, never holds a balance, and is never a counterparty to the payment. The merchant brings the wallet; Veto authorizes and records the sale. This removes Veto from the money-custody path entirely — there is no float, no payout delay from Veto, and no Veto-controlled balance to reconcile. ## Open to all agents; the mandate is an optional fast-lane Veto is open to ALL agents. An agent does not need a Veto account or a Veto-issued credential to buy from a Veto merchant. A Veto **mandate** — a signed authorization that the agent is acting on a user's behalf within set limits — is an optional premium fast-lane that can streamline acceptance and unlock higher-trust flows. Mandates are polymorphic: the mandate type can be `veto`, `ap2` (Agent Payments Protocol / Verifiable Intent), `acp`, or `none`. Veto verifies whichever is presented; absence of a mandate is a valid path, not a rejection. ## How an agent transacts 1. **Discover.** The agent fetches the merchant's `/.well-known/agentic-checkout.json` manifest. This signed manifest describes the storefront: what's for sale, accepted rails, and how to check out. 2. **Present a checkout.** The agent presents a checkout request for the item(s) it wants, optionally including a signed **mandate** (proof it is authorized to act for a user, within limits) and an **intent** (a structured statement of what it's buying and why). 3. **Veto verifies + applies policy.** Veto verifies the request — authorization (the mandate / intent), reputation, and screening — and then runs the merchant's **acceptance policy** (the merchant-defined rules for what sales to accept). The outcome is a signed verdict. 4. **Signed receipt.** Veto returns a signed receipt (Ed25519) for the decision. Receipts are verifiable offline by anyone with the merchant's public key (JWKS), so any party can independently confirm what was authorized. 5. **Settle on-chain.** With an accepted verdict, the agent settles payment on the rail — funds go directly to the merchant's wallet. The receipt ties the authorized sale to the settlement. ## Rails (rail-agnostic) Veto is rail-agnostic — the authorization layer is independent of how money moves. - **x402 / USDC on Base** — live today, with real on-chain settlement proven end to end. This is the default path: HTTP-native payments in USDC settling on Base, paid directly to the merchant's wallet. - **MPP (Merchant Payment Protocol, via Tempo / Stripe)** — additive; another rail Veto can authorize against as the ecosystem matures. - Additional rails can be added under the same authorization model. Because Veto governs and the rail executes, new rails extend reach without changing how acceptance and receipts work. ## What a merchant can sell Anything. Veto handles physical goods (e.g. sneakers, apparel), tickets, software and licenses, data and API access, and digital downloads. It is not limited to digital products. ### Recurring billing & subscriptions Subscriptions and recurring charges are handled via **pre-authorized sessions**: an agent (acting under a mandate) is authorized once for a defined, bounded relationship, and subsequent charges settle within those pre-authorized limits — without re-running the full first-time authorization each cycle. This makes recurring revenue (memberships, metered usage, renewals) work in the agent channel while keeping every charge inside the originally authorized envelope. ## How merchants onboard Onboarding is self-serve through the dashboard at merchants.veto-ai.com: 1. Create an account (magic-link sign-in) and create a merchant. 2. Add products and set **receiving** — the wallet address funds should land at. Veto is non-custodial, so the merchant brings the address. 3. Set the **acceptance policy** (the rules for which sales to accept). 4. **Publish.** Veto serves the signed `agentic-checkout.json` manifest at the storefront's `.well-known` path, and agents can immediately discover and buy. A merchant can be live in minutes, with no custody handoff and no integration with a traditional payment processor required. ## Pricing Free to start. Veto charges a small fee per sale — there is no upfront cost to publish a storefront and begin selling to agents. ## Trust & verification - Every accepted sale ships with an **Ed25519-signed receipt**, verifiable offline by anyone. - Acceptance is governed by the merchant's **policy** plus Veto's verification (authorization, reputation, screening) — agent rules are promises; Veto's rules are walls. - Because settlement is on-chain and final, sales are verified and final: no chargebacks. ## Links & where to get exact details - Home: https://merchants.veto-ai.com/ - For merchants: https://merchants.veto-ai.com/for-merchants - For developers: https://merchants.veto-ai.com/for-developers - Pricing: https://merchants.veto-ai.com/pricing - Docs (canonical — exact endpoints, manifest schema, receipt verification, policy model): https://merchants.veto-ai.com/docs - GitHub (CLI, contracts, mandate verifier, policy schema): https://github.com/veto-protocol For anything requiring an exact endpoint, request/response shape, or schema, defer to /docs rather than inferring from this overview. Operated by Investech Global LLC.