SIXPENCE
Back to Blog
•
7 min read

How Do AI Agents Pay for Services and Get Paid?

AI agents pay for services programmatically, usually with stablecoins over HTTP using the x402 standard. Here is how agent payments work, and how Sixpence uses x402 so agents can buy compliance reports.

Research

How Do AI Agents Pay for Services and Get Paid?

Direct answer

AI agents pay for services programmatically, without a human approving each transaction. The common pattern uses stablecoins sent over standard web protocols. A growing standard for this is x402, which uses the HTTP "402 Payment Required" response: a service replies to an unpaid request with a price, the agent signs a payment and retries, and the service returns the result. The same flow works in reverse, so a service an agent calls can get paid per request.

Why this matters

Most online payment systems assume a person is present to enter a card, click "approve," or hold an account. Autonomous agents break that assumption. An agent that researches, books, or buys on your behalf needs to pay in the moment, often in very small amounts, across many services, without stopping for a human. That requires a payment method that is programmatic, fast, and settles per request. For teams building agents, choosing how the agent pays is now a core design decision, not an afterthought.

How it works

The problem with traditional payment rails

Card payments and subscriptions are built around accounts and human approval. They are awkward for an agent that wants to make a single, tiny purchase from a service it has never used before. Setting up an account and a subscription for every possible service does not scale to autonomous, on-demand use.

The pay-per-request pattern

A cleaner fit is paying per request. Three things made this practical: stablecoins that can carry programmable payment authorisation, low-cost blockchain networks, and agents that can sign a transaction on their own. The x402 standard, an open protocol introduced by Coinbase, ties these together using a status code that has existed in HTTP for decades but was rarely used: 402, "Payment Required."

The flow is simple:

  1. The agent requests a resource from a service, with no payment attached.
  2. The service responds with HTTP 402 and the payment terms (price and accepted token).
  3. The agent's wallet signs a stablecoin payment and includes it in an HTTP header, then retries the request.
  4. The payment is verified and settled on-chain.
  5. The service returns the result, with confirmation that payment succeeded.

All of this can happen in the time it takes to make a normal API call, with no human clicking "approve."

Getting paid, not just paying

The same mechanism lets a service charge agents. If you expose an API that agents use, you can price each call and receive payment per request through the same 402 flow. So "how agents get paid" and "how agents pay" are two sides of one pattern.

Practical example or analogy

Think of a well-designed vending machine rather than a shop with a checkout. You do not open an account or sign a contract. You see the price for the one item you want, pay exactly that, and receive it. x402 gives an agent the same experience for digital services: a clear price per request, exact payment, and an immediate result, repeated as often as needed.

Key steps or considerations

If you are building an agent that needs to transact, plan for:

  1. A wallet the agent can use. The agent needs an x402-capable wallet or client library that can sign payments programmatically.
  2. A settlement currency and network. Stablecoins such as USDC on a low-cost network are common. Confirm which token and network each service accepts.
  3. Spend controls. Set limits so an agent cannot exceed a budget. Pay-per- request makes costs granular, which helps, but you still want guardrails.
  4. Identity and risk. When agents transact autonomously, knowing which agent you are dealing with, and screening the addresses involved, becomes part of the design.
  5. Auditability. Keep a record of what was paid for and when. Per-request payments produce a clean, itemised trail when you capture the confirmations.

How Sixpence supports agent payments

Sixpence offers two distinct pieces here. They do different jobs and are not the same product.

  • x402 is the payment channel. Through its x402 API, Sixpence lets an AI agent or API client buy a single compliance report with no account, subscription, or pre-purchased credits. An agent pays $1 per report in USDC on Base, and can buy a KYT (transaction risk), KYA (address risk), or KYE (entity intelligence) report on demand. Payment uses the standard HTTP 402 flow: the API returns 402 with payment terms, the agent's wallet signs and retries, and the report is returned. For teams that prefer fiat, Stripe USD settlement is available. Importantly, the agent's own wallet signs the payment; the Sixpence platform does not sign or hold funds on the agent's behalf.
  • The LedgerCore MCP server is the data-access channel. Separately from payment, Sixpence exposes its data to agents through a Model Context Protocol (MCP) server, alongside REST, GraphQL, and SDK access. This is how an agent connects to Sixpence intelligence, as distinct from how it pays for a report.

This matters for the identity and auditability points above. An agent can pay for and retrieve a risk check on an address or transaction as a normal step in its workflow, and the per-report flow gives a clear record of what was bought. Sixpence also lists a planned "Know Your Agent" (KYAg) report for AI agent identity and risk profiling, which is described as coming soon rather than available today.

Limitations and considerations

  • Availability and networks can change. The supported token (USDC), network (Base), and the set of available reports are defined in the current x402 API documentation. Check it before building, since these can be updated.
  • KYAg is not yet available. Agent identity profiling is described as coming soon, so do not design around it as a live feature today.
  • The agent holds the keys. Because the agent's own wallet signs, the security of agent payments depends on how that wallet and its spend limits are managed. That responsibility sits with whoever runs the agent.
  • Regulation depends on context. How stablecoin payments and agent activity are treated depends on your jurisdiction and the nature of your business. This article is general information, not financial or legal advice.

Frequently asked questions

What is x402? x402 is an open standard, introduced by Coinbase, that uses the HTTP 402 "Payment Required" status code to let a client pay for a request and retry it, typically with a stablecoin.

How does an agent pay without a human approving it? The agent's wallet is configured to sign payments programmatically. When it receives a 402 response with a price, it signs the payment and retries the request automatically.

What does an agent pay with on Sixpence? $1 per report in USDC on the Base network, with Stripe USD settlement available as an alternative.

Does Sixpence hold the agent's funds? No. The agent's own x402-capable wallet signs the payment; the Sixpence platform does not sign or custody funds.

Can an agent use Sixpence data without paying per report? Subscription users access Sixpence through accounts and the unified API, including the MCP server. x402 is the separate, account-free path for per-request payment.

Conclusion

AI agents pay for services by transacting programmatically, and the x402 standard makes that practical by turning the HTTP 402 response into a per-request payment. For teams building agents, the design questions are which wallet, which currency and network, what spend controls, and how to handle identity and auditability. Sixpence fits into that design in two distinct ways: x402 lets an agent buy a single KYT, KYA, or KYE report with no account, and the LedgerCore MCP server gives agents a way to access Sixpence data. To see the endpoints and the payment flow in detail, review the x402 API documentation at ledgerbrain.io/x402.

Sources

All PostsBack to Home