Agent Payments in 2026: x402 vs AP2 vs ACP vs MPP and How to Wire Them Up

Agents can reason and act. The moment one needs to buy something, the real question appears: how do you prove the agent was authorized to spend? Four protocols now cover different layers. x402 settles per-request payments at the HTTP layer, AP2 turns user intent into verifiable mandates, ACP standardizes agent-to-merchant checkout, and MPP adds pre-authorized spending sessions. This guide sorts them by layer and shows the code.

Four protocols, four layers

1. Four Protocols, Four Layers

It helps to sort by layer. x402, from Coinbase and launched in May 2025, lives at the HTTP request layer and pays per call, originally in stablecoins, with no account setup. AP2, announced by Google in September 2025, lives at the authorization layer and encodes a user's intent as a mandate the agent can draw against. ACP, co-developed with OpenAI and announced in late 2025, lives at the merchant checkout layer. MPP, from Stripe and Tempo and launched March 18, 2026, adds a session layer with streaming micropayments. A single autonomous purchase can use all four: discover the seller, authorize the spend, check out, then settle. The mistake is treating them as alternatives and waiting for one winner.

// x402: a request without payment gets an HTTP 402 with the price.
async function callPaidTool(url, wallet, body) {
  const first = await fetch(url, { method: "POST", body });
  if (first.status !== 402) return first.json();

  const price = await first.json();   // {network, token, amount, payTo}
  const proof = await wallet.signPayment(price);
  return fetch(url, {
    method: "POST",
    body,
    headers: { "X-PAYMENT": proof },   // settled by a facilitator
  }).then((r) => r.json());
}

2. x402: Pay-Per-Request on the Wire

x402 is the simplest primitive: a request without payment gets an HTTP 402 response describing the price, network, token, amount, and recipient, and the client retries with a payment header. Settlement is delegated to a facilitator, and the header format is chain-agnostic by design. It has the most production traction of the four: version 2 shipped in December 2025, Stripe integrated x402 on Base in February 2026, Cloudflare supports it, and reporting puts it at roughly 154 million transactions since launch. Code sample 1 shows the 402 handshake. For agent builders, x402 answers the case where a tool call should cost money per invocation and you do not want accounts, sessions, or invoices: it turns a paid API into a metered one.

def authorize(purchase: dict, mandate: dict) -> bool:
    """A cart mandate must trace back to a signed intent mandate."""
    if purchase["currency"] != mandate["currency"]:
        return False
    if purchase["amount"] > mandate["max_amount"]:
        return False
    if purchase["merchant"] not in mandate["allowed_merchants"]:
        return False
    return purchase["intent_id"] == mandate["intent_id"]

3. AP2: Mandates and Cryptographic Authorization

AP2 addresses authorization, which is the part regulators and finance teams actually care about. A user signs an intent mandate upfront, describing what the agent may buy and within which limits; when the agent finds a matching purchase, it generates a cart mandate referencing the original intent. The result is an auditable chain from human intent to a completed transaction, with verifiable checkout and payment mandates and receipts. Google released AP2 v0.2 and contributed the protocol to the FIDO Alliance in April 2026, and it is backed by more than sixty organizations including payment networks such as Amex, PayPal, and Mastercard. It is payment-agnostic, supporting cards, bank transfers, real-time payments, and stablecoins through the A2A x402 extension co-developed with Coinbase and MetaMask. Code sample 2 checks a purchase against a mandate before execution.

// ACP: agent-to-merchant checkout over existing payment rails.
const session = await acp.checkout.create({
  merchant: "store.example",
  items: [{ sku: "SKU-1", qty: 1 }],
  agent: { id: "agent-42", mandate: mandateId },
});
// the merchant returns a total; the agent confirms within mandate limits
const order = await acp.checkout.confirm(session.id, { idempotencyKey });

4. ACP and MPP: Checkout and Sessions

ACP is the merchant-side standard, co-developed with OpenAI and defining how an agent communicates with a merchant, handles checkout, and initiates payment through existing Stripe infrastructure. Its first major deployment was Instant Checkout in ChatGPT, live with US Etsy sellers in February 2026; OpenAI then scaled back in-chat purchasing in early March 2026 toward an app-based model. The protocol survived that pivot and continues to be supported by PayPal, Salesforce, and Shopify, because its value is agent-to-merchant communication rather than one platform. MPP, from Stripe and Tempo, takes a different tack with a sessions model: an agent pre-authorizes a spending limit and streams micropayments in stablecoins or fiat, a natural fit for long-running agents that consume many small services. Code sample 3 shows an ACP checkout session and code sample 4 an MPP session.

# MPP: pre-authorize a limit, then stream micropayments.
session = mpp.open(agent="agent-42", currency="USD", limit=25.00)
try:
    for chunk in long_task():
        session.charge(amount=chunk.cost, memo=chunk.id)
finally:
    session.close()          # unspent balance returns to the agent

5. Choosing and Combining Them

Pick by layer and by risk. If you want metered access to a paid API, reach for x402. If a human must delegate spending authority with an audit trail, AP2 is the right abstraction. If your agent buys from merchants over existing rails, ACP describes the conversation. If an agent needs a budget across a long task, MPP's sessions model is the fit. These are not exclusive. A realistic flow uses A2A to discover a service, AP2 to authorize the transaction, and x402 to settle it, while MPP bounds a long-running agent's total spend. Code sample 5 shows the guardrails that matter regardless of protocol: a hard budget, idempotency keys, and receipts. The protocols handle settlement and authorization; they do not handle your blast radius, and that part is still yours to bound.

// Guardrails that matter regardless of protocol.
const budget = { perTask: 10.0, perDay: 100.0, spentToday: 0 };
const seen = new Set();

function beforePay(amount, key) {
  if (amount + budget.spentToday > budget.perDay) throw new Error("daily cap");
  if (seen.has(key)) return "idempotent-skip";   // retries cannot double-charge
  seen.add(key);
  budget.spentToday += amount;
  audit.append({ amount, key, ts: Date.now() }); // receipt next to the trace
}

6. Guardrails Before Autonomy

Four rules survive contact with production. Cap spend per task and per day, and make the cap enforceable at the protocol layer rather than only in application code. Use idempotency keys so a retried payment cannot double-charge. Keep receipts for every transaction and log them against the trace that caused it, so an agent's spend is auditable next to its reasoning. And separate the credential that authorizes a purchase from the credential that authorizes a refund or a withdrawal. Agent payments are the clearest case of a general principle: autonomy without a budget is not autonomy, it is an incident waiting for a timestamp. The protocols are here, and they are good. The discipline is still on you.