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; charset=utf-8
Cache-Control: no-store
PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6Miwi...
{
"status": "payment-required",
"code": "PAYMENT_REQUIRED",
"requestId": "req_5f0c...",
"resourceId": "company.verify",
"payment": {
"provider": "x402",
"amount": "0.08",
"currency": "USDC",
"network": "eip155:8453",
"expiresAt": "2026-09-20T14:05:00.000Z",
"accepts": [{ "scheme": "exact", "amount": "80000", "payTo": "0xMerchantDestination", ... }]
}
}The requirement is a short-lived offer for one capability under specific terms. The buyer's authorization can pay for it once, allowing the service to verify payment and reject replays.
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 retries the request with that proof attached. AP2-style mandates can provide evidence about the authority behind that decision; x402 or MPP can carry the machine payment exchange.
- 01RequestAgent → GatewayCapability + input
- 02RequirementGateway → AgentPrice + payment challenge
- 03ProofAgent → GatewayBound payment authorization
- 04ExecuteGateway → BackendValidated business request
- 05ResultBackend → GatewayBusiness response
- 06ReceiptGateway → AgentPayment + delivery outcome
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 is then refused instead of opening another purchase: PAYMENT_REPLAYED (409) while the first attempt is unfinished, and PAYMENT_INVALID (402, with a fresh challenge) once it has settled.
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.
If the settlement request times out, do not immediately treat it as rejected. Reconcile the first attempt before creating another one; the provider may already have processed it.
The receipt closes the loop
A receipt links the request, transaction, payment reference and backend status. The buyer receives the settlement reference with the result. The merchant keeps the full receipt in its operator ledger, without wallet credentials or raw proofs.
{
"id": "receipt_7c1e...",
"requestId": "req_5f0c...",
"transactionId": "txn_b4e0...",
"resourceId": "company.verify",
"payment": {
"status": "settled",
"provider": "x402",
"amount": "0.08",
"currency": "USDC",
"network": "eip155:8453",
"externalReference": "0x57ec..."
},
"deliveredAt": "2026-09-20T14:01:12.000Z",
"backendStatus": 200,
"protocol": "http"
}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.
Payment is one part of agent commerce. A verified authorization permits a bounded operation; the transaction also needs a record of what the business delivered.
Frequently asked questions
How can an AI agent pay for an API?
A service can return machine-readable payment requirements. The agent authorizes payment then retries or continues the request. Protocols such as x402 and MPP are designed for this kind of flow.
What does HTTP 402 mean?
HTTP 402 is the Payment Required status code. x402 defines a practical protocol that uses it to communicate payment requirements between clients and servers.
Does successful payment mean the API request succeeded?
No. Payment and merchant execution are separate events. A service can receive payment then fail to deliver the operation.
What happens if payment status is unknown?
Keep the transaction in an uncertain state and reconcile it. Avoid an automatic second payment until the first attempt has a definite result.
How do you stop an AI agent from paying twice?
Use stable transaction IDs and replay protection. Bind payment to the exact request. Do not retry an uncertain settlement as if it definitely failed.
How do you stop a backend action from running twice?
Use merchant-side idempotency for state-changing operations. Pass a stable operation key so retries return the original result.
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