Agentic payments for developers: x402, AP2 and ACP explained

What you need to know

For thirty years, the HTTP status code 402 has sat in the specification marked "Payment Required" and reserved for future use. That future has arrived, and it arrived because of AI agents. When software starts acting on a user's behalf — booking, buying, subscribing, calling paid APIs without a person at the keyboard for each step — the entire assumption behind online payment breaks. Card checkout expects a human to read a form, tick a box and confirm. An agent needs something machine-native: a way to be quoted a price, attach proof that it may pay, and settle the money, all in code.

As of 2026, four protocols compete to be that machine-native layer. x402, from Coinbase, revives the 402 status code to settle stablecoin payments over plain HTTP. AP2, the Agent Payments Protocol from Google Cloud and Coinbase, is an authorisation framework that lets an agent prove the user actually mandated a purchase. ACP, the Agentic Commerce Protocol from OpenAI and Stripe, handles the checkout and cart negotiation with a merchant. And MPP, Stripe's machine payments effort, is the payment-network incumbent's own answer to the same problem. They are not four ways to do one thing; they are four pieces that increasingly slot together. This guide explains each one, shows how they compose in a single purchase, and works through the security discipline that has to wrap all of them — because the defining risk of agent payments is an agent tricked into paying.

Two running examples anchor the discussion. Picture a Bengaluru API startup that wants to monetise an agent-facing endpoint: not a human developer signing up for a plan, but another agent paying per call, in real time, with no account. And picture a London merchant whose customers increasingly arrive as shopping agents rather than browsers, negotiating a basket and settling on the customer's behalf. Both are dealing with the same shift, from opposite ends of the transaction.

Why card checkout does not survive contact with agents

The friction is not incidental; it is architectural. A modern card payment carries a bundle of assumptions: that a human is present, that the human can pass a challenge such as 3-D Secure, that consent is expressed by clicking, and that disputes resolve against a named cardholder. Strip the human out of the loop and every one of those assumptions needs a replacement. Who consented, and how do we prove it after the fact? What stops the agent paying ten times when it was meant to pay once? How does a merchant know it is dealing with an authorised agent rather than a hijacked one?

There is also a granularity problem. Agents want to pay small amounts, often, to many counterparties — a fraction of a penny to read one document, a few pence to run one API call, a pound to reserve one slot. Card rails were not built for that shape of traffic; the fixed per-transaction overhead swamps the value being moved. This is exactly why the Bengaluru startup cannot simply put its endpoint behind a normal subscription paywall and call it done. It wants an agent to discover the price at the moment of the call and pay it inline, with no onboarding. That is the gap the new protocols are built to close, and they close it at different layers of the stack.

The four protocols, side by side

The single most useful mental model is layer. x402 is about moving money. AP2 is about proving permission. ACP is about agreeing what is being bought. MPP is Stripe's bundled take that reaches across those concerns from the card-network side. Read the table with that in mind, and the apparent overlap resolves into a division of labour.

Notice what the table does not say: it does not crown a winner. As of 2026 this is a genuinely unsettled space, and betting the whole product on one protocol would be premature. What is clear is the shape of the layering, and the fact that the ecosystem is consolidating around interoperability rather than a single monolith. If you want the broader context on how agent standards are being made to interoperate at all, our news piece on the AGNTCY open agent interoperability standard covers the wider push.

x402 up close: HTTP 402 as a working standard

x402 is the most immediately graspable of the four because it is barely a new idea at all — it is an old idea finally implemented. The mechanic is the classic HTTP challenge-response, applied to money. An agent requests a paid resource. The server, instead of serving it, answers 402 Payment Required and includes the price and the payment details in the response. The agent constructs a payment — a stablecoin transfer — and retries the same request with a payment header attached. The server verifies the payment and, this time, serves the resource. No account, no onboarding, no card form. As of 2026, x402 is moving towards independent stewardship under the x402 Foundation, hosted within the Linux Foundation; check the foundation's own pages for the current governance status.

Here is the flow written out as a concrete HTTP exchange. This is the shape our Bengaluru startup would implement to monetise its agent endpoint — the server names its price, the agent pays inline, the server serves.

# 1. Agent requests the paid resource with no payment attached
GET /v1/enrich?q=acme-ltd HTTP/1.1
Host: api.bengaluru-startup.example

# 2. Server refuses and quotes a price (HTTP 402)
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
  "x402": {
    "price": { "amount": "0.02", "currency": "USDC" },
    "pay_to": "0xA11c3...merchant",
    "network": "base",
    "nonce": "b3f9-2a1c",              # single-use, prevents replay
    "expires": "2026-07-23T08:31:00Z"  # short-lived quote
  }
}

# 3. Agent settles the stablecoin transfer, then retries with proof
GET /v1/enrich?q=acme-ltd HTTP/1.1
Host: api.bengaluru-startup.example
X-Payment: base64(signed_payment_payload_referencing_nonce)

# 4. Server verifies the on-chain payment and serves the resource
HTTP/1.1 200 OK
Content-Type: application/json
{ "company": "ACME Ltd", "reg": "01234567", "status": "active" }

The two details that make this safe rather than naive are the nonce and the expires field. The nonce is single-use, so a captured payment header cannot be replayed against the endpoint a second time. The expiry keeps a quote from being paid long after the price has changed. Get those wrong and you have built a replay vulnerability with a payment attached — which is a far worse bug than a normal replay.

AP2 up close: proving the human said yes

If x402 answers "how does the money move", AP2 answers the harder question: "how do we know this agent was allowed to spend it?" AP2 — the Agent Payments Protocol, introduced by Google Cloud with Coinbase in September 2025 — is an open authorisation framework built around mandates. A mandate is a cryptographically signed grant from the user that says, in effect, this agent may spend up to this much, on this kind of thing, within these limits. When the agent goes to pay, it presents the mandate, and the counterparty can verify that a real human authorisation stands behind the transaction. Crucially, AP2 is rail-agnostic: it supports traditional payment rails and, through its x402 extension, crypto and stablecoins. That is the seam where AP2 and x402 clip together.

The value of a mandate is not only that it authorises — it is that it constrains and it audits. A well-scoped mandate is the difference between "my agent can pay" and "my agent can pay up to twenty pounds a day for cloud compute and nothing else". Here is the idea in short pseudocode: an agent presenting an AP2 mandate to authorise a purchase before any settlement happens.

# Agent presents an AP2 mandate to authorise a purchase
# (illustrative pseudocode — not a specific SDK)

mandate = user.sign_mandate(
    agent_id   = "shopping-agent-7",
    scope      = "merchant:london-merchant.example",
    max_amount = Money("50.00", "GBP"),
    per_window = "1 per day",
    expires    = now() + hours(2),          # short-lived
)

def authorise_purchase(cart, mandate):
    assert mandate.is_valid()                # signature + not expired
    assert cart.total <= mandate.max_amount  # within the granted limit
    assert cart.merchant in mandate.scope    # only the merchant allowed
    if cart.total > HUMAN_CONFIRM_THRESHOLD:  # e.g. anything over GBP 20
        require_human_confirmation(cart)     # step the human back in
    # Mandate proves the human said yes; hand off to settlement (e.g. x402)
    return present_authorisation(mandate, cart)

The point of writing it this way is to make the guardrails visible in the code rather than assumed in prose. The mandate carries a maximum amount, a scope naming exactly which merchant it applies to, a rate limit, and a short expiry. Anything above a human-confirmation threshold steps the person back into the loop. This is not gold-plating; it is the minimum shape of a payment authorisation you would be willing to defend after an incident.

ACP and MPP: the commerce and card-network view

ACP, the Agentic Commerce Protocol from OpenAI and Stripe, works the merchant side of the transaction. Where x402 settles and AP2 authorises, ACP is about the conversation between an agent and a shop: presenting a cart, negotiating what is in it, running the checkout. For our London merchant, ACP is the protocol that lets an incoming shopping agent assemble a basket, agree the total and complete the purchase through the merchant's existing payment processing — without a human ever loading the checkout page. It leans on Stripe's processing underneath, which is why it pairs naturally with the merchant infrastructure many businesses already run.

MPP, Stripe's machine payments protocol, is the same company's broader effort to make its rails first-class for agent-initiated payments. The honest summary as of 2026 is that the payment incumbents are not standing still while crypto-native settlement and cloud-vendor authorisation frameworks stake out the space — they are extending their own rails to meet agents where they are. For a builder, the practical read is that you will likely encounter more than one of these in a real integration, and the ones you meet will depend on whose ecosystem your counterparties already live in.

How they compose in one purchase

The most important thing to understand about these four protocols is that the interesting scenario is not choosing one — it is running several at once. A single agent purchase can layer them, each doing the job it is best at. Follow one transaction all the way through and the division of labour becomes concrete: our London merchant is selling, a customer's shopping agent is buying, and three protocols cooperate to make it happen.

Read top to bottom, the stack tells a clean story: authorise, agree, authorise-check, settle, reconcile. AP2 bookends the flow because authorisation is the part you must be able to prove twice — once when you grant it and once when you spend against it. x402 does the money movement because that is the job it was designed for, and it slots in as an AP2 extension precisely so the settlement inherits the mandate's proof. Build your own integration around these five jobs rather than around a single protocol's SDK, and you get an abstraction that survives the market consolidating.

Security: an agent tricked into paying is the whole threat model

Everything above is plumbing. The reason to care about the plumbing is that agent payments concentrate an unusually nasty risk: an autonomous system, driven by natural-language instructions, holding the authority to move money. The headline threat is over-authorisation via prompt injection — an attacker slipping instructions into a document, a web page or a tool response that persuade the agent to pay for something the user never wanted. If your agent can be talked into anything, and your agent can spend money, then your agent can be talked into spending money. That sentence should keep you honest.

The defensive pattern that has emerged by 2026 is scoped, auditable authorisation, and it rests on a few principles that show up directly in the mandate code earlier. Every payment must trace back to a human mandate — no orphan spends. Credentials should be short-lived and narrowly scoped, so a leaked or hijacked authorisation expires fast and can do little. High-value transactions should require explicit human confirmation, putting a person back in the loop exactly where the stakes justify the friction. And practical guardrails — spend limits, allow lists and deny lists — should be enforced by your own code, not left to the model's judgement. The model proposes; your authorisation layer disposes.

This is where agent payments meet the wider discipline of agent security. The guardrails above only hold if the agent around them is hardened against manipulation in the first place, which is a subject in its own right — our guide on defending AI agents against prompt injection with defence in depth covers the layers that sit upstream of the payment. And because a mandate is only as good as the tool interface that carries it, how you design the agent's tools matters too; designing tools for AI agents with clear schemas, errors and retries walks through making those boundaries robust. If you are still choosing the framework the whole thing runs on, LangGraph vs CrewAI vs the OpenAI Agents SDK compares where each one leaves you on control and observability.

The regulatory backdrop in India and the UK

A protocol can move money; it cannot on its own make that movement compliant. This is the part of agent payments that is easiest to hand-wave and most dangerous to get wrong, so treat what follows as orientation rather than legal advice. In India, account-to-account money movement runs through UPI and the framework the Reserve Bank of India maintains around it; an agent commerce flow that ultimately settles in rupees touches that infrastructure and whatever consent and mandate rules apply to it. In the UK, the FCA's regulatory perimeter and the Open Banking framework define how account access and authorised payments work, including how consent is captured and how authorised push payments are handled.

The point for a builder is not to master either regime from a single article — it is to recognise that the agent protocols sit above the regulated rails, not instead of them. As of 2026 x402, AP2, ACP and MPP do not replace UPI, the RBI framework, FCA rules or Open Banking; a production system has to reconcile an agent-initiated payment with whichever regulated rail and consent model actually moves the money in each market. Our Bengaluru startup settling in stablecoins and our London merchant taking agent-driven card payments are standing in two different regulatory worlds, and the honest engineering answer is to design the authorisation and audit trail so it can satisfy both, then get proper advice for each market before you go live.

What to actually build first

If you are starting from nothing, resist the urge to integrate all four protocols on day one. Begin with the job that maps to your side of the transaction. If you are the Bengaluru startup monetising an endpoint, implement the x402 402-challenge flow first — it is the smallest, most self-contained piece and it gets you paid per call with nonce and expiry protection built in from the start. If you are the London merchant, the ACP checkout path is where incoming agents will meet you. Either way, put a real authorisation boundary in place before you ever hold spend authority: a separate service that enforces scoped mandates, spend limits and a human-confirmation threshold, so that when you do add AP2 you are hardening a boundary that already exists rather than retrofitting one under pressure. Build the abstraction around authorise, agree and settle, keep the payment authority out of the model's reasoning loop, and you will be positioned for whichever of these protocols wins the ground your counterparties stand on.