Agentic payments: payment infrastructure built for AI agents

What are agentic payments?

Agentic payments are payments where the software decides to pay. Not a human clicking "buy" while an app relays the click — an AI agent that evaluates a price, checks it against a budget, and moves money on its own to complete a task. The agent is the buyer: it discovers the offer, initiates the payment, verifies settlement, and consumes what it paid for, all inside one machine-to-machine loop.

That "decide-to-pay" step is what separates agentic payments from ordinary online payments with extra automation. A stored card on a subscription is automated; an agent choosing between three VPS providers, provisioning the cheapest one, and paying the invoice in USDC is agentic. We unpack the definition, the boundaries, and the edge cases in what are agentic payments? — this page focuses on the infrastructure underneath.

Why AI agents settle in stablecoins, not cards

Card rails assume a card-holder is present: a person who passed KYC, can answer a 3-D Secure challenge, and can dispute a charge. An agent has none of that. It has an API key and a wallet. Everything about card processing — fraud scoring built on human behavior, chargebacks, days-long settlement — gets in the way of software paying software.

Stablecoins fit the shape of the problem. A USDC transfer is a bearer instrument an agent can hold and send directly, settlement is final in seconds, and the fee is network gas — often well under a cent on fast chains, against the roughly $0.30-plus fixed minimum a card transaction carries before percentages. That fixed floor makes card rails economically absurd for the transactions agents actually make: a $0.02 API call, a $0.40 inference job, a $5 VPS hour. The market has already voted — across x402 agent payment traffic, USDC accounts for about 98.6% of settlement volume. If you are new to how on-chain settlement works, start with what are stablecoin payments.

The agentic payment stack

"Agentic payments" is not one protocol. It is a stack of layers that are converging fast, and it helps to know which layer each named protocol lives at:

• Checkout — ACP. The Agentic Commerce Protocol (OpenAI and Stripe) standardizes how an agent walks a merchant's checkout: product feeds, order state, delegated payment. It answers "how does an agent buy from a shop."
• Authorization — AP2. Google's Agent Payments Protocol defines mandates: cryptographically signed proof that a human authorized an agent to spend, within limits. It answers "was this agent allowed to pay."
• Settlement — x402. Coinbase's x402 revives HTTP status 402 so a server can quote a price in a response header and the client can retry with a signed stablecoin payment. It answers "how does the money actually move over HTTP." We break it down in x402 explained.
• Gateway — payment sessions. Underneath all three, someone has to generate deposit addresses, watch chains, confirm against finality rules, fire webhooks, and reconcile a ledger. That is the gateway layer, and it is where Plaidly sits: a payment session API that any of the layers above can settle through, across the twenty chains the platform supports.

These layers compose rather than compete. An ACP checkout can carry an AP2 mandate and settle via x402; every one of those flows still terminates in gateway infrastructure that touches the chain. Plaidly exposes an x402 facilitator endpoint for payment validation today, with full proof settlement on the roadmap — and payment sessions work for agents right now without any of the newer protocols.

What agent-ready infrastructure actually requires

Most payment products are human-shaped: dashboards, email verification, embedded card forms. Making infrastructure agent-ready means removing every step that assumes eyes and hands. In practice that comes down to four properties:

• Headless onboarding. An agent should be able to become a merchant without a signup form. On Plaidly, one unauthenticated POST /v1/merchants with sandbox: true returns API credentials — an agent goes from nothing to accepting testnet payments in a single request, with an idempotency key so retries are safe.
• Machine-readable lifecycle and diagnostics. Every session state — pending, paid, expired — and every failure reason must be structured, not prose. When something goes wrong, the agent needs a field it can branch on, not a support article.
• Signed webhooks and receipts. Settlement events arrive as HMAC-signed webhooks an agent can verify, with retry on failure, and each paid session can produce a PDF receipt — because an autonomous buyer still answers to an accountant.
• Policy-gated spending. Money out is where autonomy gets dangerous. Plaidly agent wallets run every outbound spend attempt through a policy engine that returns pending, approval_required, or denied — hard limits enforced server-side, with a human approval gate where the policy demands one.

Proof, not promises: six agents completed paid lifecycles

Claims about agent readiness are cheap, so we tested ours. We stood up a mock VPS shop as a Plaidly merchant and pointed six different AI agents at it with one instruction: rent a server and pay for it. Each agent had to onboard, create a payment session against our production API, fund it with real USDC on Solana devnet, and verify its own payment confirmed on-chain.

All six completed the full paid lifecycle — session created, on-chain transfer sent, payment confirmed, service delivered. To be plain about what that does and does not prove: these were real payments with worthless tokens. The transfers were genuine on-chain USDC settlements on testnet rails, exercising exactly the code paths mainnet uses — but no spendable value moved, and we make no claims about live mainnet agent volume. The full scoreboard, including where each agent stumbled, is in the case study.

Build it: two endpoints, an MCP server, and llms.txt

The core integration surface for an agent is deliberately small: create a session, read a session.

POST /v1/payment_sessions   →  amount, chain, deposit address
GET  /v1/payment_sessions/:id  →  status: pending | paid | expired

Around that core: /v1/sandbox/faucets funds test wallets so an agent can pay itself through a full loop without hunting for testnet tokens, the docs ship an agent quickstart and llms.txt so models can read the integration surface directly, and an MCP server exposes six tools an agent can call from inside a conversation — covered in MCP payments. If your product is an API, the same two endpoints turn into per-request pricing; see pay-per-use APIs for AI agents.

Onboarding is one curl — no account, no dashboard, sandbox from the first request:

curl -X POST https://api.plaidly.io/v1/merchants \
  -H "Content-Type: application/json" \
  -d '{"name": "my-agent-shop", "sandbox": true}'

Frequently asked questions

How do AI agents actually pay for things?

An agent calls a payment API the same way it calls any other API. With Plaidly, the agent creates a payment session over HTTP, receives a deposit address and exact amount, sends a stablecoin transfer from a wallet it controls, and then polls the session until it reads paid. Every step is a machine-readable request and response — no browser, no checkout form, no human in the loop unless a spending policy requires one.

Do agents use credit cards or crypto?

Both models exist, but they solve different problems. Card-based approaches tokenize a human’s existing card so an agent can spend on their behalf inside consumer checkouts. Stablecoin rails give the agent its own funds and settle machine-to-machine with finality in seconds and fees well under a cent — which is what pay-per-request pricing and autonomous workflows actually need. Plaidly runs the stablecoin side: payment sessions settled in USDC and other stablecoins, currently on testnet rails.

How do you stop an agent from overspending?

Spending limits live in the payment layer, not in the prompt. Plaidly agent wallets evaluate every outbound spend attempt against a policy — per-transaction caps, daily budgets, allowed destinations — and return one of three outcomes: pending (the spend proceeds), approval_required (a human has to sign off before it moves), or denied outright. The agent gets a structured answer it can reason about, and the operator gets a hard guarantee no prompt injection can talk its way past.

Who is liable when an AI agent makes a payment?

The operator who funded the wallet and set the policy. That is exactly why policy-gated wallets and signed, auditable records matter: an on-chain transfer is final, so the controls have to sit before the money moves. Plaidly gives operators the enforcement point (spend policies with approval gates) and the paper trail (signed webhooks, session diagnostics, PDF receipts) so responsibility is explicit rather than implied.