How Veto works — discover, pay, deliver

If you've used Stripe, the mental model is familiar: a customer pays, and you then fulfill the order — Stripe just tells you the payment happened. Veto is the same shape, with one twist: your customer is an AI agent, not a person clicking a button.

This page is the honest, end-to-end picture. Three parts: discover, pay, deliver. The third part — "after the agent pays, how does the buyer actually get what they paid for?" — is the one merchants ask about most, so it gets the most room.

1 · Discover — the agent finds your checkout

An agent has to find you before it can buy. There are three ways in, and you don't write any code for them:

The agent reads agentic-checkout.json, follows the next field through your catalog and checkout, and never needs to read these docs at runtime — the wire protocol is self-describing. (Full detail: Connect your site and the Agentic Checkout Protocol.)

2 · Pay — the agent pays you, Veto governs the spend

When the agent decides to buy, it opens a checkout and Veto quotes a price. The agent pays in USDC over x402 — a gasless stablecoin payment. You do not touch any crypto plumbing, hold a wallet, or manage gas: you set your receiving address once, and settled USDC lands there.

Two things happen on every spend, and they're the heart of Veto:

• Veto governs. Before any money moves, Veto verifies the buyer's mandate and runs your acceptance policy. The rail only ever executes a spend the gate already approved. (This is the buyer-side promise too: the agent's own Veto policy decided it was allowed to spend here.)
• You get the money + a signed receipt. On a successful settle the agent receives an order_id, a signed merchant receipt (an Ed25519 JWS anyone can verify offline), and a small fulfillment stub whose reference is the on-chain transaction hash.

Here's the honest part that leads straight into delivery: the settle response does not contain your product. It confirms the payment and hands back a receipt — that's it. There is no in-band product delivery. So how does the buyer get what they paid for? That's part 3.

3 · Deliver — YOU ship it, Veto tells you when

This is the question every merchant asks: "the agent paid — now what?"

The honest answer: Veto does not deliver the product to the buyer. You do. Just like Stripe doesn't ship the sweater — your fulfillment system does, once Stripe tells you the charge succeeded. Veto works exactly the same way, using a Stripe-style webhook.

Here's the loop:

The event your server receives

It's a normal JSON POST. The envelope is stable; the part you care about is data.object, the order:

{
  "id": "evt_01J…",
  "type": "order.settled",
  "created": 1750000000,
  "livemode": true,
  "api_version": "v1",
  "data": {
    "object": {
      "id": "ord_01J…",
      "session_id": "sess_…",
      "merchant_id": "mrch_01J…",
      "agent_id": "11111111-1111-1111-1111-111111111111",
      "total": { "currency": "USD", "subtotal": "39.00", "tax": "0.00", "total": "39.00" },
      "items": [{ "sku": "slipper-cloud-9", "qty": 1 }],
      "rail_name": "x402",
      "settlement_ref": "0x…txHash…",
      "receipt_id": "rcpt_01J…",
      "mandate_type": "veto",
      "trust_tier": "trusted",
      "buyer": {
        "name": "Ada Lovelace",
        "shipping_address": {
          "line1": "12 Mathematician's Way",
          "city": "London",
          "postal_code": "EC1A 1BB",
          "country": "GB"
        }
      }
    }
  }
}

settlement_ref is the on-chain transaction hash (your proof of payment). receipt_id points at the signed merchant receipt. items is what to fulfill. buyer is who and where to deliver — present when the checkout captured a shipping address. The full field list and event types are in Webhooks.

A real webhook handler

A tiny Node endpoint that verifies the delivery and then fulfills. The only Veto-specific line is verifyWebhook from @veto-protocol/checkout:

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

export async function POST(req: Request) {
  // 1. Read the RAW body — never JSON.parse → re-stringify before verifying.
  const raw = await req.text();
  const signature = req.headers.get('veto-signature'); // "t=…,v1=…"

  // 2. Verify it really came from Veto (positional args; returns { ok, reason? }).
  const result = verifyWebhook(raw, signature, process.env.VETO_WEBHOOK_SECRET!);
  if (!result.ok) {
    return new Response(`bad signature: ${result.reason}`, { status: 400 });
  }

  // 3. Dedupe — delivery is at-least-once, so the same event can arrive twice.
  const eventId = req.headers.get('veto-event-id')!;
  if (await alreadyHandled(eventId)) return new Response('ok'); // no-op replay
  await markHandled(eventId);

  // 4. Deliver. Fulfill on order.settled (the rail has confirmed the money).
  const event = JSON.parse(raw);
  if (event.type === 'order.settled') {
    await fulfill(event.data.object); // <-- YOUR delivery logic (below)
  }

  // 5. Return 2xx fast (<10s) to ack. Anything else triggers a retry.
  return new Response('ok', { status: 200 });
}

Digital good — grant or return access

For a download, a license, or an account upgrade, fulfillment is a database write and a notification. There's no shipping address to read:

async function fulfill(order: any) {
  // 'items' tells you what was bought; settlement_ref / receipt_id are your proof.
  const link = await mintDownloadUrl(order.items, order.receipt_id);
  // Deliver out of band: email it, expose it on your own /orders/:id API,
  // or unlock the buyer's account. Veto carries no product bytes for you.
  await emailBuyer(order.buyer, link);
}

Physical good — ship using the buyer's address

For a parcel, read the shipping address straight off the event and hand it to your carrier or fulfillment provider:

async function fulfill(order: any) {
  const ship = order.buyer?.shipping_address;
  if (!ship) throw new Error('no shipping address on a physical order'); // 4xx → Veto retries

  await createShipment({
    to: { name: order.buyer.name, ...ship },
    lines: order.items,            // [{ sku, qty }]
    reference: order.id,           // ord_… — your idempotency anchor
  });
}

The whole arc, in one glance