Take the human out of a checkout and count what breaks. The form assumes someone will type a card number. The card assumes someone will answer a 3-D Secure challenge. The catalog assumes someone will read a marketing page. For an autonomous agent to buy a digital good end-to-end, with nobody tapping "confirm", you have to replace all three, and the replacements make up what we call the agentic commerce stack.
There are three layers. First, a payment protocol it can actually complete, which is x402. Second, a settlement asset that clears instantly and finally: USDC on Base. Third, a tool interface it can read without scraping, meaning MCP plus an agent-native API. The human web takes each of the old defaults for granted, and an agent can't use any of them.
We're going to stay at the ecosystem level here and look at what each piece does and what happens if you leave one out. The question of which market goes first we've covered already. Our answer was digital goods, with game keys as the cleanest consumer example (why agents won't buy pizza first). Consider this post the plumbing under that argument.
| Layer | Human-web default | Agent-native replacement |
|---|---|---|
| Payment protocol | Checkout form + 3-D Secure popup | x402 — payment instructions in HTTP itself |
| Settlement asset | Card authorization → multi-day capture | USDC on Base — final in ~10 seconds |
| Tool interface | Paginated HTML catalog, geo-IP pricing | MCP / agent-native API — structured, one product per request |
Each layer, and the default built for humans that it replaces.
Layer 1: a payment protocol an agent can complete (x402)
On the human web, "you owe money" means a checkout form. You type a card number, expiry date, CVV and billing address, and then a 3-D Secure popup sends you over to your bank's app to approve with a tap. All of it is UI built for fingers. An agent has no fingers, no card on file and no banking app to switch to.
x402 gets rid of that wall by putting payment into HTTP instead of onto a page. It uses HTTP status 402, "Payment Required", a code that has sat in the spec unused for decades, and adds a structured body that explains how to pay. When an agent asks to buy something, the server replies with 402 and machine-readable instructions covering the amount, asset, chain, destination address and a quote identifier. The agent pays and returns with proof. The server verifies it and releases the goods. There's no form, popup, account or callback URL along the way. Where a card flow asks a human "are you sure?" to guard against fraud, x402 relies on cryptographic proof that the payment actually happened.
Plenty of things could be called crypto checkout. x402 counts as an agent primitive because both ends are programmatic. A merchant can verify the payment deterministically, since it either confirmed onchain or it didn't. An agent can complete it deterministically too, with no human challenge arriving out of band. Cards have the opposite profile: a person can start a card payment easily, but a merchant can't trust it without a fraud stack. With x402 it's the other way round.
In our implementation, the fast path takes one call. The agent sends a purchase request with an X-PAYMENT header containing a base64-encoded EIP-3009 "exact" transferWithAuthorization, signed for the accepts[] the server advertises. A facilitator settles it on-chain gaslessly, and the key comes back in the same response. The agent never needs a tx_hash, never makes a second round trip and never pays gas. That's the canonical x402 "exact" scheme, in which the client signs an authorization and a facilitator settles it.
Some wallets would rather move the USDC themselves, so there's a two-step flow as the universal fallback. The agent sends a purchase request and gets a 402 back with payment details and a quote_id. It transfers USDC to the address, then posts again with the transaction hash and the quote. On both paths the server takes the sending wallet from the transfer and binds it to the order, and only that wallet can claim the key.
Layer 2: a settlement asset that's instant and final (USDC on Base)
Cards settle slowly. The network approves a hold, the merchant captures it later, the money may take days to arrive, and a chargeback can reverse the whole thing weeks afterwards. An agent can't work like that. It needs to confirm that the money moved and the deal is done in the same moment it pays. A dollar-pegged stablecoin on a fast chain takes care of the timing problem.
We settle in USDC on Base, on chain id 8453 with token contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. For unattended commerce it has the right properties:
- It's dollar-denominated. Prices, quotes and refunds all use the same unit. Between quoting and paying, the agent carries no FX or volatility risk. A stablecoin keeps the accounting boring, and with money, boring is good.
- It's final fast. On Base we wait for 5 block confirmations, which takes about 10 seconds, and then the payment is settled. Nothing is pending, there's no capture step and no clearing window. As soon as the agent sees confirmation it can move on.
- It's irreversible by default. USDC has no chargeback mechanism. That looks like a drawback until you remember the merchant hands over a digital key the moment payment clears. Instant delivery only works because both sides get finality. On a reversible rail you'd need an escrow or hold step, and that would put a human back in the loop.
Finality also pairs with the price lock. The quote_id in the 402 response fixes the price for 5 minutes. Even if wholesale prices tick during those few seconds, the agent sends exactly the amount the merchant is expecting. With a payment that is instant, final and locked, "pay and immediately receive" becomes one motion that nothing interrupts, and nobody negotiates.
Layer 3: a tool interface an agent can read (MCP / agent-native API)
The last wall is the catalog. Human storefronts serve paginated HTML, titles padded with marketing copy, prices that change with geo-IP and "related products" arranged for the eye. Give that to an agent and it has to scrape, de-duplicate and guess. It will pick the wrong platform or region often enough that nobody ships it to production. An agent-readable tool interface fixes this.
We offer two surfaces that work together. One is MCP, the Model Context Protocol, which is the standard way to hand a model tools: named, typed functions an LLM calls directly. Our MCP server lives at https://mcp.cdk.bot/mcp and has 8 tools: search_games, get_game_details, browse_filters, get_price_quote, confirm_purchase, check_order, request_refund, and submit_review. Paste the config into Claude Desktop, Cursor or Cline, and the model can shop the catalog through tool calls without scraping or glue code. The other surface is the REST API that sits underneath the MCP server, for agents that would rather speak HTTP. It's the same data behind both doors.
The design rules that make an API agent-native
Putting tools on MCP doesn't finish the job. The data behind those tools has to suit something that reasons, not something that renders pages. A human storefront with a JSON wrapper is not an agent-native API, and these rules are where the two part ways:
- Structured filters, not search-and-scroll. Platform, device, region and language are explicit fields the agent can filter on. Finding "the cheapest legitimate Steam key that activates in the EU" then takes one query instead of a page of results to skim.
- One product per request. A detail call returns a single product, fully specified, with one canonical price, one platform and one region. The agent doesn't have to untangle a marketing grid. Reasoning models decide much better over one clean object than when ranking twenty fuzzy cards.
- Competitor prices inline. Each product response includes a
marketplace_offersarray holding the cheapest current offer from major keyshops (G2A, Eneba, Kinguin and peers) in USD. An agent's first question is whether the price is good, and answering it in the same response spares it a scrape. You'd never see a human storefront list its rivals' prices. For an agent-native one the incentive flips, because the agent will check anyway and you may as well save it the round trip. - Machine-readable discovery. Before an agent can call you, it has to find you. We publish an agent discovery card at /.well-known/agent.json, an OpenAPI spec at the docs endpoint and an
llms.txtfor crawlers. An agent can learn what we sell and how to buy it without anyone reading our homepage first.
All four rules come from one difference. A human storefront is tuned for a person browsing, and an agent-native API is tuned for a machine making a decision. They may share a database, but they're different products.
Why all three layers, and why now
Take away any layer and the purchase needs a human again. With no x402 you're back to a checkout form and a tap. With no instant, final settlement asset you wait out a capture window, or you add an escrow step to fend off chargebacks. With no agent-readable interface the agent scrapes and guesses and never gets as far as paying. That's why we talk about a stack. One clever payment API wouldn't be enough, because the layers only hold up together.
None of them is big or exotic, either. x402 is a status code and a JSON body. USDC on Base comes down to a token transfer and a confirmation count, and an agent-native API is a handful of choices about how responses are shaped. The new part is timing. HTTP-native payments, cheap and fast stablecoin settlement, and a tool-calling standard that models actually speak all matured together. A transaction that used to need a person at every step now fits inside an API call and a wallet signature.
CDK Bot is this stack, implemented for digital goods
CDK Bot is procurement infrastructure for AI agents. It's these three layers wired up for one category: video game keys, gift cards and subscriptions, more than 40,000 products sourced from authorized wholesale distributors. Payment runs on x402, either as a gasless one-shot or through the two-step fallback. Settlement is USDC on Base. One catalog sits behind both an MCP server and an agent-native REST API.
We chose this category because it clears the bar for unattended commerce cleanly. The stack itself is general, though. Nothing in the layers depends on the digital good being a game key.
This post came at the stack from the top down. For the bottom-up version, the companion post goes through building a game-buying agent in about 200 lines with x402 + MCP. The live API and OpenAPI spec are at api.cdk.bot/docs, and other agents can discover us programmatically at /.well-known/agent.json.
Working on another layer of this stack, or want agents to be able to buy a product category they can't buy yet? Write to info@cdk.bot.