{
  "slug": "agent-checkout-vs-human-checkout",
  "title": "Agent Checkout vs. Human Checkout: Why Your Payment Flow Fails Machine Buyers",
  "description": "Why checkout built for a person watching a screen is unusable by an AI agent, and what a checkout flow that actually completes for a machine buyer looks like — 402 + API key versus native x402.",
  "kind": "sub",
  "order": 1,
  "target_query": "why human checkout flows fail for AI agents",
  "secondary_queries": [
    "can an AI agent complete checkout",
    "machine readable checkout flow",
    "agent friendly payment flow",
    "402 vs x402 checkout"
  ],
  "tags": [
    "checkout",
    "monetization",
    "402",
    "x402",
    "agents",
    "payments",
    "api-keys"
  ],
  "published": "2026-07-29",
  "updated": "2026-07-29",
  "words": 1646,
  "premium": false,
  "license": "https://changegamer.ai/license.xml",
  "canonical": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout",
  "markdown": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout.md",
  "takeaways": [
    "A checkout built for a person fails an agent at a specific, listable set of steps: email verification loops, a confirmation-inbox requirement, CAPTCHAs, cookie-dependent sessions, JS-rendered forms with no API equivalent, and multi-page redirects that assume a human is watching a screen.",
    "Two rails exist today that a machine can complete: a self-hosted HTTP 402 gate with API keys (fiat, no crypto, one human step at first purchase) and native x402 (the agent signs and pays end-to-end, no human step at all — dormant on most sites, including this one, until an operator turns on-chain settlement on).",
    "The dividing line is not \"is a human involved\" — it is \"is a human involved on every purchase, or only the first one\". A key rail asks for one human checkout ever; a human-only checkout asks for one on every single transaction.",
    "Fixing a checkout for agents is mostly not a payments problem, it is an idempotency and header problem: mint keys idempotently against retried webhooks, accept both `Authorization: Bearer` and `X-API-Key`, give the buyer a retrieval path for a lost key, and never gate the flow behind a cookie session.",
    "Test your checkout the way an agent will use it: with `curl`, no browser, no cookie jar. If the loop cannot be completed in that shape, no agent can complete it either."
  ],
  "outline": [
    {
      "depth": 2,
      "text": "Why a human checkout is unusable by an agent",
      "anchor": "why-a-human-checkout-is-unusable-by-an-agent",
      "url": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout#why-a-human-checkout-is-unusable-by-an-agent"
    },
    {
      "depth": 2,
      "text": "What a machine-completable checkout looks like instead",
      "anchor": "what-a-machine-completable-checkout-looks-like-instead",
      "url": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout#what-a-machine-completable-checkout-looks-like-instead"
    },
    {
      "depth": 3,
      "text": "Rail 1 — HTTP 402 + API key (fiat, no crypto)",
      "anchor": "rail-1-http-402-api-key-fiat-no-crypto",
      "url": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout#rail-1-http-402-api-key-fiat-no-crypto"
    },
    {
      "depth": 3,
      "text": "Rail 2 — Native x402 (the agent pays end-to-end, no human step)",
      "anchor": "rail-2-native-x402-the-agent-pays-end-to-end-no-human-step",
      "url": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout#rail-2-native-x402-the-agent-pays-end-to-end-no-human-step"
    },
    {
      "depth": 3,
      "text": "Where the human step sits, contrasted directly",
      "anchor": "where-the-human-step-sits-contrasted-directly",
      "url": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout#where-the-human-step-sits-contrasted-directly"
    },
    {
      "depth": 2,
      "text": "Where a human step is genuinely unavoidable, and where it is a self-inflicted wall",
      "anchor": "where-a-human-step-is-genuinely-unavoidable-and-where-it-is-a-self-inflicted-wall",
      "url": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout#where-a-human-step-is-genuinely-unavoidable-and-where-it-is-a-self-inflicted-wall"
    },
    {
      "depth": 2,
      "text": "Concrete design fixes",
      "anchor": "concrete-design-fixes",
      "url": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout#concrete-design-fixes"
    },
    {
      "depth": 2,
      "text": "The test that actually matters",
      "anchor": "the-test-that-actually-matters",
      "url": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout#the-test-that-actually-matters"
    }
  ],
  "faq": [
    {
      "question": "Can an AI agent complete a checkout form the way a human does, by filling in fields?",
      "answer": "Not reliably. A checkout form is designed around a human reading labels, clicking into fields, solving a CAPTCHA, and watching a confirmation screen. An agent operating headlessly has no screen to watch and often no way to solve an anti-bot challenge that is deliberately built to be hard for automated clients. The fix is not a smarter agent — it is a checkout that offers a non-visual, API-shaped path alongside (or instead of) the form."
    },
    {
      "question": "Does a machine-payable checkout mean no human is ever involved?",
      "answer": "Only on one rail. Native x402 removes the human entirely: the agent receives a 402 with machine-readable payment terms, signs a stablecoin authorization from its own wallet, and retries — no account, no sign-up. A self-hosted 402-plus-API-key rail still typically needs a human to complete checkout once, to buy the key; after that the key is reusable by the agent indefinitely with zero further human steps. Which one you need depends on whether your buyer is a wallet-holding agent or a person's agent operating on a company card."
    },
    {
      "question": "Is a CAPTCHA on my checkout page actually stopping agent purchases?",
      "answer": "Yes, by design — a CAPTCHA exists specifically to distinguish a human from an automated client, so a checkout that requires solving one is, definitionally, a checkout an agent cannot complete unless a human intervenes. If you want agent purchases, the machine-completable path (a 402 body, a payment link, a webhook-minted key) has to bypass the CAPTCHA entirely, not present an easier version of it."
    },
    {
      "question": "What is the minimum fix if I already run a human checkout and cannot rebuild it?",
      "answer": "Keep the human checkout for people and add a parallel machine path for the same product: a 402 response with a `payment_url`, `price`, and retry instructions, backed by the same Stripe (or equivalent) checkout link you already use, with a webhook that mints an API key on completion. The human page does not need to change; what has to exist is a second, API-shaped entry point that never requires a browser session."
    }
  ],
  "body": "A checkout built for a person and a checkout built for a machine buyer are not the same product wearing different clothes — they fail at different steps for different reasons, and most sites that report zero agent revenue have only ever built the first one.\n\nThis is the deep dive on Stage 4 of the machine purchase funnel in [how to sell to AI agents](/articles/selling-to-ai-agents): discovery and evaluation can be perfect, the price can be fair and machine-readable, and the sale still dies here, at the one step that has to be completed without a human present.\n\n## Why a human checkout is unusable by an agent\n\nA human checkout fails an agent for mechanical reasons, not intelligence reasons — none of these require the agent to be \"smarter\"; they require the checkout to stop assuming a person is watching a screen.\n\n- **Email verification loops.** A flow that pauses to send a confirmation link to an inbox and wait for a click assumes a human owns that inbox and will act on it within the session. An agent has no browser tab to leave open waiting for a click, and often no access to the inbox at all.\n- **CAPTCHAs and other human-proof challenges.** These exist specifically to separate humans from automated clients, so by design a checkout gated by one cannot be completed by an agent unless a human steps in to solve it — at which point you no longer have a machine-completable flow.\n- **Cookie- and session-dependent state.** A checkout that tracks progress through a browser session (cart state in a cookie, a CSRF token tied to a page load) requires the buyer to hold and replay that session exactly, which is a fragile, non-obvious contract for a stateless HTTP client to reverse-engineer and was never documented for it to follow.\n- **JS-rendered forms with no API equivalent.** If the only way to submit a card number or confirm a purchase is by executing client-side JavaScript against a rendered DOM, an agent that fetches HTML and reads text — the common case — has literally nothing to act on. There is no request it can construct, because the real request only exists inside a browser's JS runtime.\n- **Multi-page redirects assuming a human is watching.** A flow that bounces through an intermediate \"please wait\" or \"check your email\" page, timed for human reading speed, has no defined machine contract for what to poll, when, or what a successful outcome looks like.\n\nNone of these are edge cases. They are the default shape of checkout on the web, and the fix in every case is the same: publish the missing machine-readable contract, or route the agent around the step that has none.\n\n## What a machine-completable checkout looks like instead\n\nTwo rails exist today that a competent agent can complete without a human intervening at every purchase, and they put the human step in a different place.\n\n### Rail 1 — HTTP 402 + API key (fiat, no crypto)\n\nThe origin server answers `402 Payment Required` with a JSON body carrying the price, a `payment_url`, and explicit retry instructions; the buyer completes checkout at that URL; a webhook mints an API key; the agent retries the original request with `Authorization: Bearer <key>` (or `x-api-key`) and gets the resource. This is the rail this site runs in production, documented in full — the exact field set, the key-delivery contract, the header precedence — in [paying for access: the HTTP 402 flow](/resources/paying-for-access-402).\n\nThe honest limitation, stated plainly rather than buried: **a human usually has to complete checkout once.** The `payment_url` typically opens an ordinary Stripe-style checkout page, and an agent has no card of its own to complete that page end-to-end. What is machine-completable is everything *after* that one purchase: the key, once minted, is retried by the agent indefinitely with zero further human steps. That is the entire point of a key — it converts one human transaction into an unlimited number of machine ones.\n\n### Rail 2 — Native x402 (the agent pays end-to-end, no human step)\n\nNative x402 removes the human from the loop entirely. The server answers `402` with an `accepts[]` array of machine-readable payment requirements; the agent's client library signs a stablecoin transfer authorization locally from its own wallet and retries with an `X-PAYMENT` header; a facilitator verifies and settles the transfer on-chain; the server returns the resource with an `X-PAYMENT-RESPONSE` settlement receipt. No account, no sign-up, no card, no person — see [agent wallets: paying per run with x402](/resources/agent-wallets-x402) for the full buyer-side loop and the client libraries that automate it.\n\nOn this site, that rail is scaffolded but **dormant**: `/api/x402/<slug>` answers every request with `HTTP 503 x402_not_configured` today, because none of the five operator environment variables it requires (`X402_FACILITATOR_URL`, `X402_PAY_TO`, `X402_NETWORK`, `X402_ASSET`, `X402_MAX_AMOUNT`) are set. That is not a hypothetical caveat — it is the exact, current, verifiable behavior of the endpoint, confirmed live at [/api/payment.json](/api/payment.json), which is the source of truth for which rail is actually live at any moment. The live rail here is the Bearer-key flow above.\n\n### Where the human step sits, contrasted directly\n\n| | Human step required? | When |\n|---|---|---|\n| Human-only checkout | On every purchase | Every time the agent needs access |\n| 402 + API key | Once, typically | Only at first key purchase; every later request is machine-only |\n| Native x402 | Never | No human step at any point, once a wallet is funded |\n\nThe useful question is not \"does this rail involve a human at all\" — the self-hosted key rail does, and that is fine. It is \"does a human have to show up *again* for the next hundred requests\". A checkout that asks for a human every single time is the failure mode; one that asks exactly once, ever, is not the same problem.\n\n## Where a human step is genuinely unavoidable, and where it is a self-inflicted wall\n\nNot every human touchpoint is a design failure. The first-time purchase of a key on the 402-plus-key rail can legitimately require a person: someone has to authorize spending real money the first time, and a company's procurement or card-holder may reasonably want a human decision at that point, once. That is a defensible, bounded cost — one checkout, ever, per buyer.\n\nWhat is not defensible is requiring that same human step on every subsequent request. If your flow re-runs email verification on each purchase, or routes a *retry with a valid key* back through the same CAPTCHA-gated form the first purchase used, you have rebuilt the human-only failure mode on top of a rail that was supposed to remove it. The tell: count how many times a human has to act to serve one buyer across a hundred requests. On a working key rail, the answer is one. On a broken implementation of the same rail, it is still a hundred, because the \"machine\" path was never separated from the human page — a key-retrieval endpoint instead of a buried email link, a webhook-driven mint instead of a support ticket, is the difference between the two.\n\n## Concrete design fixes\n\nA checkout that actually completes for an agent needs a short, specific list of properties, all of which are implementation choices rather than new payment technology:\n\n- **Idempotent key minting.** Payment webhooks retry — a single purchase without a session-keyed guard mints several keys, and the agent ends up with no stable credential to reason about.\n- **Accept both header spellings.** `Authorization: Bearer <key>` and `X-API-Key: <key>` — agent frameworks default to different ones, and accepting both costs one line of code.\n- **A key-retrieval path.** An agent may complete checkout in a context where it cannot hold on to the response body. A `GET /key?session_id=…` endpoint that returns the key for a completed session — with an explicit \"pending\" state if the webhook has not landed yet — closes that gap without a support inbox in the loop.\n- **No cookie-dependent sessions in the retry path.** The retry that uses the key must work as a single, stateless HTTP request — no prior page load, no CSRF token, no session cookie the agent had no way to acquire.\n- **`curl`-testable, end to end.** If you cannot complete your own checkout with `curl` and no browser, an agent cannot either. Write it as a permanent test, not a one-off manual check.\n\nThe implementation detail for building the gate itself — the exact 402 JSON shape, the webhook handler, edge validation, and caching rules that keep a paid response from leaking — is covered separately in [implementing an HTTP 402 paywall an agent can actually pay](/articles/http-402-paywall-implementation); this article is about the checkout step, that one is about the whole gate.\n\n## The test that actually matters\n\nBefore shipping a claim that your site is \"agent-payable\", run the loop the way an agent will, with nothing else in the room:\n\n```bash\n# 1. Hit the wall — no auth, no browser, no cookie jar\ncurl -s -i https://example.com/resources/premium-thing\n\n# 2. Read payment_url and how_to_pay straight from the JSON body\n# (a human completes this step once, on the 402+key rail)\n\n# 3. Retry with the minted key — this step must need nothing but a header\ncurl -s -i -H \"Authorization: Bearer $KEY\" \\\n  https://example.com/resources/premium-thing\n\n# 4. Confirm the same call also works with the alternate header spelling\ncurl -s -i -H \"x-api-key: $KEY\" \\\n  https://example.com/resources/premium-thing\n```\n\nIf step 3 or step 4 needs anything beyond a single header on a single request — a cookie, a CSRF token, a second confirmation click — the checkout is still built for a human, whatever the marketing copy says. An agent will hit that wall exactly the same way `curl` does, and leave the same way `curl` would: with nothing to retry against.",
  "cluster": {
    "id": "selling-to-agents",
    "title": "Selling to AI agents",
    "description": "How to sell content, APIs and tools to buyers that are software — discovery, machine-readable offers, spend ceilings, payment rails, and what breaks.",
    "status": "complete",
    "pillar": {
      "slug": "selling-to-ai-agents",
      "title": "How to Sell to AI Agents: The Complete Guide to Machine Buyers",
      "description": "The operator playbook for selling content, APIs and tools to buyers that are software: how agents discover, evaluate, authorize and pay — and the four rails you can charge them on today.",
      "kind": "pillar",
      "order": 0,
      "html": "https://changegamer.ai/articles/selling-to-ai-agents",
      "markdown": "https://changegamer.ai/articles/selling-to-ai-agents.md",
      "json": "https://changegamer.ai/api/articles/selling-to-ai-agents.json"
    },
    "articles": [
      {
        "slug": "agent-checkout-vs-human-checkout",
        "title": "Agent Checkout vs. Human Checkout: Why Your Payment Flow Fails Machine Buyers",
        "description": "Why checkout built for a person watching a screen is unusable by an AI agent, and what a checkout flow that actually completes for a machine buyer looks like — 402 + API key versus native x402.",
        "kind": "sub",
        "order": 1,
        "html": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout",
        "markdown": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout.md",
        "json": "https://changegamer.ai/api/articles/agent-checkout-vs-human-checkout.json"
      },
      {
        "slug": "machine-readable-pricing-pages",
        "title": "Machine-Readable Pricing Pages: How to Let an Agent Evaluate Your Offer Before It Pays",
        "description": "Why a prose pricing page cannot be evaluated by an AI agent, what fields a machine-readable offer catalog needs, and how to keep it in lockstep with your human pricing page and your 402 body.",
        "kind": "sub",
        "order": 2,
        "html": "https://changegamer.ai/articles/machine-readable-pricing-pages",
        "markdown": "https://changegamer.ai/articles/machine-readable-pricing-pages.md",
        "json": "https://changegamer.ai/api/articles/machine-readable-pricing-pages.json"
      },
      {
        "slug": "acp-vs-ap2-vs-x402",
        "title": "ACP vs. AP2 vs. x402: Which Agent Payment Rail Should You Implement?",
        "description": "A decision framework for choosing between ACP, AP2, and x402 (plus the self-hosted 402 gate) — sorted by who your buyer actually is, what you are selling, and what is live versus waitlisted today.",
        "kind": "sub",
        "order": 3,
        "html": "https://changegamer.ai/articles/acp-vs-ap2-vs-x402",
        "markdown": "https://changegamer.ai/articles/acp-vs-ap2-vs-x402.md",
        "json": "https://changegamer.ai/api/articles/acp-vs-ap2-vs-x402.json"
      },
      {
        "slug": "accepting-x402-payments",
        "title": "How to Accept x402 Stablecoin Payments: A Seller Implementation Guide",
        "description": "A build guide for sellers who have already decided x402 is the right rail: the 402 response shape, the wallet/facilitator/network choices, the verify-then-settle retry flow, exact vs. upto pricing, and how to ship it dormant until you are ready to go live.",
        "kind": "sub",
        "order": 4,
        "html": "https://changegamer.ai/articles/accepting-x402-payments",
        "markdown": "https://changegamer.ai/articles/accepting-x402-payments.md",
        "json": "https://changegamer.ai/api/articles/accepting-x402-payments.json"
      },
      {
        "slug": "api-key-issuance-for-agents",
        "title": "Issuing API Keys to AI Agents Automatically: A Build Guide",
        "description": "How to design a system that mints and delivers API keys to agent and software buyers with minimal human friction: trigger models, storage, delivery, key format, tiering, rotation and revocation — illustrated with ChangeGamer's own Stripe-webhook mechanism.",
        "kind": "sub",
        "order": 5,
        "html": "https://changegamer.ai/articles/api-key-issuance-for-agents",
        "markdown": "https://changegamer.ai/articles/api-key-issuance-for-agents.md",
        "json": "https://changegamer.ai/api/articles/api-key-issuance-for-agents.json"
      },
      {
        "slug": "pricing-tiers-for-machine-buyers",
        "title": "Pricing Tiers for API and Corpus Access: What Actually Varies Between Them",
        "description": "The axes that actually distinguish one pricing tier from another for a machine buyer — rate limits, content scope, deliverables and license grant — and how ChangeGamer structures its own four tiers around deliverable and license, not gated content.",
        "kind": "sub",
        "order": 6,
        "html": "https://changegamer.ai/articles/pricing-tiers-for-machine-buyers",
        "markdown": "https://changegamer.ai/articles/pricing-tiers-for-machine-buyers.md",
        "json": "https://changegamer.ai/api/articles/pricing-tiers-for-machine-buyers.json"
      },
      {
        "slug": "agent-spend-limits-and-trust",
        "title": "Agent Spend Limits and Trust: What a Seller Should Verify Before Granting Access",
        "description": "The seller-side counterpart to agent spend controls — how an API operator reads an inbound agent's spend ceiling before granting access, which payment protocols actually prove that ceiling, how to revoke access, and what \"trust\" operationally means for a seller when no portable agent-reputation standard exists yet.",
        "kind": "sub",
        "order": 7,
        "html": "https://changegamer.ai/articles/agent-spend-limits-and-trust",
        "markdown": "https://changegamer.ai/articles/agent-spend-limits-and-trust.md",
        "json": "https://changegamer.ai/api/articles/agent-spend-limits-and-trust.json"
      },
      {
        "slug": "refunds-and-disputes-with-agent-buyers",
        "title": "Refunds and Disputes with Agent Buyers: What a Seller Actually Does",
        "description": "What happens on the seller side when an autonomous agent's purchase needs to be reversed or is disputed — API-key refund mechanics, why x402 settlement cannot be undone, what card-token revocation does and does not prove, and what to log before you reverse anything.",
        "kind": "sub",
        "order": 8,
        "html": "https://changegamer.ai/articles/refunds-and-disputes-with-agent-buyers",
        "markdown": "https://changegamer.ai/articles/refunds-and-disputes-with-agent-buyers.md",
        "json": "https://changegamer.ai/api/articles/refunds-and-disputes-with-agent-buyers.json"
      },
      {
        "slug": "packaging-a-corpus-as-a-product",
        "title": "Packaging a Corpus as a Product: Format, Schema, Versioning and Delivery",
        "description": "The packaging decisions behind selling a content corpus as a dataset product — export format, the free-sample/gated-full split, a per-record metadata schema, a corpus version number, and which of three delivery mechanisms to use — grounded in ChangeGamer's own three real export formats.",
        "kind": "sub",
        "order": 9,
        "html": "https://changegamer.ai/articles/packaging-a-corpus-as-a-product",
        "markdown": "https://changegamer.ai/articles/packaging-a-corpus-as-a-product.md",
        "json": "https://changegamer.ai/api/articles/packaging-a-corpus-as-a-product.json"
      },
      {
        "slug": "discoverability-for-paid-agent-apis",
        "title": "How Do AI Agents Discover Paid APIs? A Guide to Every Surface",
        "description": "How an AI agent finds out a paid API or resource exists before it ever reads a price: llms.txt, the JSON API index, MCP registries, incidental 402 discovery, x402 auto-listing, and what .well-known does and does not cover.",
        "kind": "sub",
        "order": 10,
        "html": "https://changegamer.ai/articles/discoverability-for-paid-agent-apis",
        "markdown": "https://changegamer.ai/articles/discoverability-for-paid-agent-apis.md",
        "json": "https://changegamer.ai/api/articles/discoverability-for-paid-agent-apis.json"
      },
      {
        "slug": "fraud-and-abuse-from-agent-traffic",
        "title": "Fraud and Abuse from AI Agent Traffic: What a Seller Should Detect",
        "description": "How a seller of APIs, content, or tools to AI agents spots and mitigates abuse once access is already granted — key sharing, over-scope scraping, spend-ceiling circumvention, spoofed identity, and rate-limit evasion patterns specific to autonomous agents.",
        "kind": "sub",
        "order": 11,
        "html": "https://changegamer.ai/articles/fraud-and-abuse-from-agent-traffic",
        "markdown": "https://changegamer.ai/articles/fraud-and-abuse-from-agent-traffic.md",
        "json": "https://changegamer.ai/api/articles/fraud-and-abuse-from-agent-traffic.json"
      },
      {
        "slug": "measuring-agent-revenue",
        "title": "Measuring Revenue from AI Agent Traffic: Beyond the Traffic Log",
        "description": "The revenue-layer fields and queries a seller adds on top of a general traffic log — authorized-vs-settled, revenue per rail, revenue per tier, and how to avoid double-counting a webhook retry as two sales.",
        "kind": "sub",
        "order": 12,
        "html": "https://changegamer.ai/articles/measuring-agent-revenue",
        "markdown": "https://changegamer.ai/articles/measuring-agent-revenue.md",
        "json": "https://changegamer.ai/api/articles/measuring-agent-revenue.json"
      }
    ]
  },
  "navigation": {
    "pillar": {
      "slug": "selling-to-ai-agents",
      "title": "How to Sell to AI Agents: The Complete Guide to Machine Buyers",
      "description": "The operator playbook for selling content, APIs and tools to buyers that are software: how agents discover, evaluate, authorize and pay — and the four rails you can charge them on today.",
      "kind": "pillar",
      "order": 0,
      "html": "https://changegamer.ai/articles/selling-to-ai-agents",
      "markdown": "https://changegamer.ai/articles/selling-to-ai-agents.md",
      "json": "https://changegamer.ai/api/articles/selling-to-ai-agents.json"
    },
    "previous": null,
    "next": {
      "slug": "machine-readable-pricing-pages",
      "title": "Machine-Readable Pricing Pages: How to Let an Agent Evaluate Your Offer Before It Pays",
      "description": "Why a prose pricing page cannot be evaluated by an AI agent, what fields a machine-readable offer catalog needs, and how to keep it in lockstep with your human pricing page and your 402 body.",
      "kind": "sub",
      "order": 2,
      "html": "https://changegamer.ai/articles/machine-readable-pricing-pages",
      "markdown": "https://changegamer.ai/articles/machine-readable-pricing-pages.md",
      "json": "https://changegamer.ai/api/articles/machine-readable-pricing-pages.json"
    }
  },
  "resources": [
    {
      "slug": "paying-for-access-402",
      "html": "https://changegamer.ai/resources/paying-for-access-402",
      "markdown": "https://changegamer.ai/resources/paying-for-access-402.md",
      "json": "https://changegamer.ai/api/resources/paying-for-access-402.json"
    },
    {
      "slug": "agent-wallets-x402",
      "html": "https://changegamer.ai/resources/agent-wallets-x402",
      "markdown": "https://changegamer.ai/resources/agent-wallets-x402.md",
      "json": "https://changegamer.ai/api/resources/agent-wallets-x402.json"
    }
  ]
}