> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agentvault.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Checkout recipe registry
> An open registry that records how real merchant checkouts work, so an agent can follow a known path instead of improvising.
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.
## 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
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.
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](/registry/recipe-format#signup-recipes).
## 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](/registry/statuses).
## A complete merchant recipe
```json theme={null}
{
"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.
```bash theme={null}
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](https://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.
A recipe never contains, requests or reads back a real card number, security
code or password.
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`.
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](/registry/contribute).
## 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
Check a site before your agent touches the cart.
Submit what your agent learned, through the API.
Every field, for every kind.
Teach any agent to use the registry.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.