Checkout recipe registry

Use the registry to find out how a store’s checkout works, and whether it can work at all, before your agent touches the cart.

Why it exists

Agents waste most of a failed checkout rediscovering what another agent already learned: which button adds to the cart, where the card fields live, or that the store only accepts PayPal. The registry records that knowledge once, as a checkout recipe, so every later agent starts from a known path or skips a store that can never work.

Diagram showing an agent sending a product URL to the registry, receiving a merchant and platform recipe, and either following the recipe or stopping at a recorded dead end. — Lookup before checkout: the agent asks the registry, then follows the recipe or reports the dead end.

In this section

What a recipe is. A JSON document describing a platform’s checkout or one store’s checkout.
What its status means. A strict claim about what has actually been proven on a real run.
How to read it. One unauthenticated request with a stripped URL.
How to add to it. An authenticated API submission, screened automatically.

What a recipe describes

Platform recipe

How a whole commerce platform’s checkout works, for example Shopify, WooCommerce with Stripe, Gumroad or Lemon Squeezy: how to recognise it, where the card fields live, a selector per checkout phase, and known gotchas.

Merchant recipe

One store pinned down: which platform recipe applies, selector overrides found on a real run, any dead end, and the verification trail.

The registry also holds signup recipes, which describe a site’s account signup form rather than its checkout. They use the same status names and the same submission flow, but each status claims an account creation rather than a purchase. See Recipe format.

Statuses at a glance

Every recipe carries one status. It states what was proven, not what was hoped. The same status means different things on a checkout recipe and a signup recipe.

Status	On a checkout recipe	On a signup recipe
`verified`	A real purchase completed with this recipe, proven by a merchant receipt or card statement. Only a maintainer can set it	A real account was created with this recipe, proven out of band, such as by the site’s confirmation email or a later sign-in. Only a maintainer can set it
`partial`	A real run reached a filled card form. No purchase was completed	A real signup run accepted the recipe’s fields, but the account was not proven out of band
`unverified`	Derived from the platform’s known structure. Not yet run	Derived from the platform’s structure or a look at the form. Nothing submitted
`dead-end`	Unattended checkout is impossible here. `deadEnd` says why	Unattended signup is impossible here. `deadEnd` says why

A recorded dead end is as valuable as a recorded success. It saves every later agent a run on a store that cannot work.

Full rules: Recipe statuses.

A complete merchant recipe

{
  "id": "store.example.com",
  "kind": "merchant",
  "hosts": ["store.example.com"],
  "platform": "bigcartel",
  "status": "dead-end",
  "lastVerifiedAt": "2026-07-20",
  "deadEnd": {
    "type": "paypal-only",
    "details": "Big Cartel store whose only gateway is PayPal. No card fields ever mount."
  },
  "notes": "Big Cartel itself supports Stripe. The dead end is this store's gateway choice, not the platform's.",
  "exampleProductUrl": "https://store.example.com/product/sticker"
}

The notes field carries the judgement a field cannot: here, that the blocker is this store’s choice and not a limitation of the platform.

Open data

Reading the registry needs no account and no API key. Recipes are plain JSON.

curl -sG "$SELF_AGENT_PAY_API_URL/v1/recipes" \
  --data-urlencode "url=https://shop.example.com/product/thing"

The live registry is the source of truth. It is exported daily to the public repository at github.com/selfxyz/agent-checkout-skill, which is read only.

Safety rules every recipe follows

These are enforced by automatic screening, not left to convention.

Recipes use mock tokens only

A recipe never contains, requests or reads back a real card number, security code or password.

A challenge means stop and hand off

A recipe never describes how to solve or bypass 3-D Secure, a one-time code or a CAPTCHA. A store that always demands one is recorded as a dead-end.

Submit a payment once

A recipe classifies the outcome of a payment submit. It never retries one.

Every contribution is screened before it goes live for text aimed at the reading agent (prompt injection), challenge evasion, embedded personal or payment data, and spam. A contribution for a store already in the registry under another host is combined with the existing recipe. See Contribute a recipe.

Supported platforms

Shopify, WooCommerce, Stripe Checkout, Stripe Payment Links, Lemon Squeezy, Paddle, Gumroad, BigCommerce, Squarespace Commerce, Wix Stores, Ecwid, Snipcart, FastSpring and Big Cartel. For live coverage by status, read the index: GET /v1/recipes returns the key, kind and status of every recipe.

Next steps

Look up a recipe

Check a site before your agent touches the cart.

Contribute a recipe

Submit what your agent learned, through the API.

Recipe format

Every field, for every kind.

Install the skill

Teach any agent to use the registry.

MCP server

Playwright SDK