How AI Agents Pay for APIs: From HTTP 402 to Settlement and Delivery

An agent can discover and call an API in seconds. Traditional billing asks someone to create an account, add a card, buy credits and store a key before that first call. Machine payment protocols move the commercial exchange closer to the request.

The interesting part begins after the price appears. Payment, backend execution and delivery happen in different systems, so a useful design must preserve the state of each one.

#From request to payment requirement

With an HTTP 402 flow, the agent first asks for a paid resource without acceptable proof. The service answers with a machine-readable requirement that names the resource, amount, currency, destination and expiry. The buyer can inspect those terms before authorizing payment.

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "request_id": "req_01JY8M1Q",
  "resource": "company.verify",
  "amount": "0.08",
  "currency": "USDC",
  "network": "base",
  "expires_at": "2026-09-20T14:05:00Z"
}

The requirement is not an invoice for an undefined service. It is a short-lived offer bound to one capability and one request. That binding is what makes later verification and replay checks meaningful.

#Authorization becomes payment proof

The agent or its wallet decides whether the request fits the buyer’s policy. It then creates the proof expected by the selected payment rail and submits it with the same request identity. AP2-style mandates can provide evidence about the authority behind that decision; x402 or MPP can carry the machine payment exchange.

Verification checks that the proof is valid and matches the quoted terms. Settlement is a separate step: it asks the payment system to move or finalize value. A service should record both stages rather than hide them behind a single “paid” flag.

#Protect the request before execution

Once proof is accepted, the service reserves a replay key before calling the merchant backend. A repeated proof can then resolve to the existing transaction instead of opening another purchase.

State-changing backend operations need their own idempotency key. If the API completes a reservation but the network loses its response, the Gateway cannot infer whether the side effect occurred. Reusing the same operation key lets the backend return the first result safely.

#Settlement does not equal delivery

A confirmed payment and a delivered API result are two facts. The backend can reject the request after settlement, or the response can disappear on its way back to the agent. The transaction record must retain that distinction.

#The receipt closes the loop

A receipt joins the request, payment reference, execution outcome and delivery state under one safe identifier. It gives the buyer something stable to present after a retry and gives the merchant a record to inspect without exposing wallet credentials or raw proofs.

{
  "receipt_id": "rcpt_01JY8M4N",
  "request_id": "req_01JY8M1Q",
  "resource": "company.verify",
  "payment": "settled",
  "execution": "completed",
  "delivery": "delivered"
}

#What changes with another payment rail

The challenge format, proof and settlement adapter may change. The merchant capability should not. Pricing, replay state, execution and receipts still belong to the shared commerce path around the API.

This is why a payment protocol is part of an agent-commerce architecture rather than the whole architecture. Money movement opens the right to execute a bounded operation; the transaction ends only when the business can explain what was delivered.

#Frequently asked questions

#Sources and further reading

• x402 Foundationx402.org
• x402 documentationdocs.x402.org
• Stripe, Machine Payments Protocolstripe.com
• Agent Payments Protocolgithub.com
• Agentic Commerce Protocolgithub.com
• Universal Commerce Protocoldevelopers.google.com
• Model Context Protocolmodelcontextprotocol.io