An AI agent can now buy you a t-shirt in ChatGPT, pay for an API call in USDC, or carry a signed spending mandate across a chain of other agents. There are at least four open protocols for this: ACP, AP2, MPP and x402. Payments people are rightly worried about fragmentation.

I think the bigger problem is simpler. When the agent gets it wrong, who handles the dispute? On some of these rails, the honest answer is nobody, because the money is already gone.

I build risk tooling for agent payments, so this is the question I spend my days on. Here's the map, the gap, and what I think fills it.

Four protocols, four different jobs

The four protocols mostly aren't competing for the same job. Each one standardizes a different step of an agent transaction.

ACP (Agentic Commerce Protocol)

• Job: checkout. An agent completes a purchase from a merchant without leaving the chat.
• Spec by: OpenAI and Stripe, Sept 2025. It powers Instant Checkout in ChatGPT.
• Money moves on: cards.

AP2 (Agent Payments Protocol)

• Job: authorization. Signed mandates prove what the user allowed the agent to buy.
• Spec by: Google, Sept 2025, with 60+ partners.
• Money moves on: cards, bank transfers, and stablecoins via an x402 extension.

MPP (Machine Payments Protocol)

• Job: machine payments. Agents pay services programmatically, session by session.
• Spec by: Stripe and Tempo, Mar 2026. Visa extended it to cards, and Lightspark to Bitcoin Lightning.
• Money moves on: stablecoins and cards.

x402

• Job: pay per HTTP request. A 402 response tells the agent how to pay, and it pays inline.
• Spec by: Coinbase, 2025. It's now stewarded by the x402 Foundation, co-founded with Cloudflare.
• Money moves on: stablecoins, mainly USDC.

Read top to bottom, that's a stack. ACP handles what gets bought, AP2 proves that the user allowed it, and MPP and x402 move the money between machines. The layers also connect: AP2 ships an x402 extension built with Coinbase, MetaMask and the Ethereum Foundation, so an AP2 mandate can settle over x402.

The chart everyone shared blurs creators and partners

A protocol-by-company grid has been making the rounds on LinkedIn (Sam Boboev's version, adapted from The Big Whale). It's a useful picture of how many big names are involved. But it marks several partners as creators, and that changes the story.

• MPP was co-authored by Stripe and Tempo. Visa is a design partner that extended MPP to card payments; it didn't write the protocol. Tempo, the actual co-author, isn't on the grid at all.
• AP2 is Google's protocol. Mastercard, PayPal and Coinbase are among its 60+ partners. Coinbase did co-build the x402 extension that plugs into AP2.
• Missing players. Tempo and Lightspark (MPP), MetaMask and the Ethereum Foundation (the AP2 x402 extension), and Google's own checkout-layer protocol, UCP, don't appear.

Why it matters: "creator" implies control over where a standard goes. In reality, a few companies write the specs and many more plug in. Stripe sits in the middle of three of the four, which says more about where the leverage is than any coverage bar.

The gap: card rails can undo a payment, stablecoin rails can't

On card rails, a mistake has a way back. The cardholder files a dispute, the issuer and acquirer argue it out under network rules, and money can flow back weeks later. Agent protocols that settle on cards inherit that system, even if the rules for "the agent did it" are still unwritten.

On stablecoin rails, a confirmed USDC transfer is final. There's no issuer to call and no chargeback window. That's a feature for machine-to-machine payments, since sellers get paid instantly and can't be clawed back. But it moves all of the risk to the moment before the agent signs.

That makes three questions urgent, and none of the four specs fully answers them:

1. Was it authorized? AP2 mandates help here, but only if every hop in the chain carries and checks them.
2. Is it sane? Right amount, known payee, a signature that doesn't stay valid for days, no unlimited token approval hiding inside the transaction.
3. If it goes wrong anyway, who decides? With no chargeback, refunds and disputes have to be agreed in advance and judged by someone, or something.

What a pre-signing risk layer looks like

If you can't undo a payment, you check it before it happens. I split the check into two parts: hard rules that never need a model, and a model only for the gray areas.

Part 1: deterministic rules. These are cheap, explainable, and should run on every payment. Here's a minimal sketch for an x402 / EIP-3009 payment:

import time

MAX_UINT256 = 2**256 - 1
KNOWN_PAYEES = {"0xApiProviderA...", "0xApiProviderB..."}

# 5 USDC (USDC has 6 decimals)
PER_PAYMENT_CAP = 5_000_000

# A signature shouldn't stay valid for days
MAX_VALIDITY_SECONDS = 300


def check_payment(p: dict) -> list[str]:
    issues = []
    now = int(time.time())

    if p.get("method") == "approve":
        if int(p["amount"]) == MAX_UINT256:
            issues.append("HOLD: unlimited token approval")

    if p.get("to") not in KNOWN_PAYEES:
        issues.append("REVIEW: new payee")

    if int(p.get("value", 0)) > PER_PAYMENT_CAP:
        issues.append("HOLD: over per-payment cap")

    valid_for = int(p.get("validBefore", 0)) - now
    if valid_for > MAX_VALIDITY_SECONDS:
        issues.append("HOLD: signature valid too long")

    return issues

Part 2: a model for the gray areas. Rules can't tell whether a refund claim is reasonable or whether a new payee fits what the user asked for. For that I fine-tuned SRA-RiskGate-4B, a small open model built on Qwen3-4B. It scores payment risk, checks compliance flags and returns a structured dispute outcome, including when to escalate to a human. It's small enough to run locally (GGUF and Ollama builds), so the check doesn't add another third party to the payment path.

The order matters: rules first, the model only on what the rules flag as uncertain, and a human for anything the model escalates.

Interoperability should start at the risk layer

The fragmentation debate is mostly about checkout and settlement: which protocol should a merchant or acquirer support? That will sort itself out, and most will end up supporting more than one.

The risk layer shouldn't fragment with them. An agent that pays over x402 today and checks out through ACP tomorrow needs the same rules: same spending limits, same payee list, same record of what the user authorized. If every protocol ships its own risk logic, the agent's owner gets four partial views and no full picture.

That's a real opening for acquirers. They already own acceptance, risk and disputes for merchants. Three moves would carry that into agent commerce:

1. Put a protocol-agnostic risk check in front of every agent payment, whichever rail it lands on.
2. Write dispute rules for stablecoin flows in advance: refund windows, escrow for larger payments, and who adjudicates, agreed before the payment rather than argued after.
3. Treat the AP2 mandate as evidence. A signed record of what the user allowed is exactly what a dispute needs, so keep it with the transaction.

The protocol war is the easy part

ACP, AP2, MPP and x402 will settle into a stack, much like HTTP, TLS and payment APIs did. The harder question is the one the specs leave open: when software spends someone's money and gets it wrong, who checks it first and who decides after?

On card rails we have decades of answers. On stablecoin rails we have to build them now, before the payment instead of after. That's the layer I'm working on, and I'd like to hear how others are approaching it.

Try it:

• SRA-RiskGate-4B on Hugging Face
• Benchmark dataset
• Python package

Sources

• Stripe: Agentic Commerce Protocol and Instant Checkout in ChatGPT
• agenticcommerce.dev: ACP overview
• Zinc: What is AP2
• Decrypt: Google reveals AP2 with Coinbase and the Ethereum Foundation
• The Block: Tempo mainnet and the Machine Payments Protocol
• PYMNTS: Visa supports MPP with card payments
• The Defiant: Stripe, Visa and Lightspark extend MPP
• Cloudflare: Launching the x402 Foundation with Coinbase