x402 vs MPP: which rail should an AI agent pay on?

x402 and MPP are diverging, not converging. x402 is a family of on-chain payment schemes attached to HTTP 402. MPP — the Machine Payments Protocol from Stripe and Tempo, launched March 2026 — is a payment-method-agnostic HTTP authentication framework that also covers cards and Lightning. You do not have to choose one: both can run on the same endpoint.

The choice that actually matters is neither rail. It is whether anything scores the payment before settlement becomes final.

The numbers, honestly

As of October 11, 2026, x402 had recorded 191,751,598 cumulative transactions across 12 chains (agenteconomy.to, via CVJ's October 11 briefing). MPP reported 46,198 cumulative events. Those units are not comparable — an MPP event is not an x402 transaction, MPP sessions amortize many calls into one funding event, and an estimated 25–30% of x402 activity may be test or leaderboard noise.

XRPL alone passed 13 million x402 agent payments by October 10, 2026 across 168 registered merchants (RippleX's J. Ayo Akinyele). Circle's Facilitator Service settles x402 USDC on Arc, Base, and Polygon PoS.

Strip the vanity metrics and the honest position is: x402 owns today's on-chain agent volume, MPP owns the card-and-compliance on-ramp, and both are settlement plumbing.

Neither rail scores the payment

In x402's default exact scheme, a signed authorization settles immediately — there is no moment at which a bad instruction can be caught. In MPP, a session pre-funds future calls — the decision happens once, at funding time, not per purchase.

The decision-gate pattern fills that gap: confidence ≥0.80 auto-pays, 0.50–0.79 holds for a human, below 0.50 escalates and blocks.

The one structural window: auth-capture

x402 has a second EVM scheme the comparison pages barely mention: auth-capture. The buyer's single signature (ERC-3009 or Permit2) goes to an AuthCaptureEscrow contract, where funds are held under a capture authorizer instead of transferred to the merchant. From the hold, the payment can be captured, voided, or refunded — card-style authorize/capture semantics, on-chain.

That hold is exactly where a decision gate belongs: authorize first, score the instruction, then capture or void on the score.

On October 13, 2026, ScriptMasterLabs deployed an AuthCaptureEscrow instance on Arc mainnet — contract 0x06b4e6ba16b1ee0fac2d5f4ea69b93ce311fa7b4, deploy transaction 0x5bb75341d617f0161b6b08ca819ae3b1571a62498924062028436c9fdd0e9aae — and Sourcify-verified it with an exact match on creation and runtime code. Honest scope: it is an independent deployment for the arc-authcapture build, not the canonical commerce-payments escrow singleton registered for Arc in public SDK documentation, and no payment has flowed through it yet. Deployment is claimed; volume is not.

Do it yourself

1. Run both protocols on one endpoint (Tempo's mppx speaks both) and choose per route.
2. Use auth-capture wherever a payment might need to be undone — anything non-trivial, asynchronous, or chosen on inferred intent.
3. Score inside the capture window, then wire the bands to the escrow calls: ≥0.80 capture, 0.50–0.79 hold for a human, <0.50 void and log.
4. Persist the instruction, score, band, and capture/void transaction together. A payment record alone cannot reconstruct why money moved.

Full analysis with claim receipts: https://scriptmasterlabs.com/x402-vs-mpp

Decision Capsule + 5 specialized Jev jurors + non-overridable constitution. Jev chooses. Code decides. Built for agents that manage real capital.