If you need an autonomous agent to pay for something in 2026, the answer depends almost entirely on who is selling and whether a human is present at checkout:

• A human approves a retail purchase in a chat interface — use ACP, where OpenAI, Stripe and Meta have converged.
• An agent buys API calls or data priced in dollars — use x402, optionally with Nevermined on top for subscriptions, credits and metering.
• An agent streams many small payments inside one session — look at MPP.
• The seller cannot get a merchant account at all — this is the case most comparisons skip, and where Bitcoin-native options like Hypawave and L402 are among the few that work.
• You need to prove an agent was authorized to spend — that is AP2, an authorization framework rather than a way to move money.

Everything below is sourced to official documentation. See methodology and sources for how these claims were verified and what remains uncertain.

Comparison at a glance

Platform	Type	Settlement asset	Custody	Human present?	Best for
x402	Open protocol (Linux Foundation)	Any ERC-20, SPL or XRPL asset; stablecoins in practice	Facilitators do not custody principal	No	Agents paying for APIs and data over HTTP
MPP	Open protocol (Stripe + Tempo)	Stablecoins, cards, Lightning, multi-rail	Self-custodial on Tempo; intermediated via Stripe	No	Streamed or metered spend within a session
ACP	Open protocol (OpenAI + Stripe + Meta)	Cards only today	Custodial — card rails	Yes	Retail checkout via a chat assistant
AP2	Authorization framework (FIDO Alliance)	Payment-method agnostic	Not a rail	Either	Proving an agent had permission to spend
Nevermined	Billing layer + x402 facilitator	Cards via PSPs; USDC, EURC, any ERC-20	No principal custody; on-chain credit balances	No	Subscriptions, credits, usage metering
Crossmint	Agent wallet platform	Stablecoins and cards	Custodial, hybrid or non-custodial by signer config	Either	One vendor for wallets, ramps and compliance
L402	Open protocol (Lightning Labs)	Bitcoin over Lightning	Non-custodial	No	Bitcoin-native HTTP paywalls
Hypawave	Settlement protocol	Bitcoin over Lightning	Non-custodial	No	Accountless sellers; verified delivery

x402

x402 revives the dormant HTTP 402 status code. A server answers an unpaid request with 402 plus machine-readable payment requirements; the agent pays, retries with an X-PAYMENT header, and receives the content. Settlement runs through facilitators, and the official documentation is explicit that a facilitator "does not hold funds or act as a custodian — it performs verification and execution of onchain transactions based on signed payloads provided by clients."

It is not stablecoin-only, a point worth correcting because it is widely misreported. Per the network and token support docs, EVM chains accept "any ERC-20 token" through EIP-3009 or Permit2, Solana accepts any SPL or Token-2022 token, and XRPL accepts XRP or any issued currency. USDC's privileged position is narrow: dollar-string pricing like "$0.01" resolves to a chain's configured default stablecoin, while TokenAmount pricing "works on any chain with no configuration needed." x402.org's own framing that "stablecoin payments are the primary use case" describes typical usage, not a protocol restriction.

Networks are identified with CAIP-2 (namespace:reference), and scheme specs exist for fifteen chain families. Notably there is no Bitcoin support: a repository-wide search for bip122 across the canonical upstream returns zero hits, despite bip122 being a valid CAIP-2 namespace.

Use it when your agent buys metered digital goods and dollar-denominated pricing matters.

Where it falls short. No path for physical goods. More subtly, x402 proves payment, not delivery. Its offer-and-receipt extension does claim receipts "prove successful service delivery" — but the receipt payload contains only version, network, resourceUrl, payer, issuedAt and an optional transaction. There is no digest of the delivered bytes, so nothing cryptographically binds the receipt to what arrived, and only the server can issue one. The extension itself notes a valid signature "does not prove that the key was authorized to sign on behalf of the service," and defers trust entirely to external identity systems.

One housekeeping note for developers: the canonical repository is now x402-foundation/x402 under the Linux Foundation. The older coinbase/x402 is a fork that has fallen months behind and understates both the extension set and the supported chains.

x402 has more momentum than any alternative. Absent a specific reason to choose otherwise, it is the sensible default.

MPP (Machine Payments Protocol)

Co-authored by Stripe and Tempo and announced March 18 2026, the same day Tempo mainnet went live. Like x402 it is an HTTP 402 challenge-and-credential protocol, but it adds three intent types — charge, session and subscription. The session intent "establishes reusable payment state so clients can pay for many requests, streamed chunks, or metered units without settling a separate payment for each one," with the client signing cumulative off-chain vouchers and the server batching settlement. Spending caps are separate, coming from Tempo access keys that support per-token limits, daily budgets, recipient allowlists and expiry.

Critically for anyone assuming this is a single-chain play: MPP describes itself as "network agnostic and multi-rail", and its documented methods include Tempo, generic EVM, Stripe cards, Solana, Stellar, NEAR — and Lightning.

Use it when your spend is continuous rather than transactional — a long-running agent consuming metered compute where a discrete payment per call is the wrong unit.

Where it falls short. Its production track record is short. Custody depends on the method: self-custodial on Tempo, where funds stay in the payer's wallet and unused deposits are refundable on channel close, but Stripe's implementation uses Stripe-managed deposit addresses and Shared Payment Tokens restricted to US legal entities with a $0.50 minimum on fiat.

ACP (Agentic Commerce Protocol)

Announced September 29 2025 alongside OpenAI's Instant Checkout, and now described in Stripe's docs as "an open standard created by Stripe, OpenAI, and Meta," with those three holding the Technical Steering Committee seats. ACP standardizes how an agent reads a merchant catalog and completes checkout.

It is card-only today — the delegated payment spec states the payment method type "must be card" — and human-present by design: the architecture docs define the Buyer as "the human who wants to purchase something." Machine-to-machine payment is explicitly out of scope; Stripe routes that to MPP and x402 instead.

Two things are true at once here, and conflating them produces bad analysis. The protocol keeps expanding — five releases through April 2026 adding carts, product feeds, delegated authentication and native MCP transport. But standalone in-chat checkout was de-emphasized: on March 24 2026 OpenAI said the initial Instant Checkout "did not offer the level of flexibility that we aspire to provide, so we're allowing merchants to use their own checkout experiences while we focus our efforts on product discovery," and its merchant FAQ now states it is "moving away from a standalone Instant Checkout experience in ChatGPT."

Use it when a person is buying real products and you want to reach existing merchants.

Where it falls short. Spec status is beta. Implementing it does not get you listed — cross-platform merchant discovery mechanisms do not yet exist. OpenAI's shopping surface is US-only and feed onboarding is application-gated.

AP2 (Agent Payments Protocol)

Announced September 16 2025 by Google with more than sixty partners. Its core primitive is the Mandate: a cryptographically signed verifiable digital credential proving what a user authorized, encoded as SD-JWTs and existing in Open form (constraints bound to an agent) and Closed form (bound to a specific transaction). The specification is explicit that AP2 "operates as a security feature within a Commerce Protocol" — settlement is performed by the Credential Provider, Merchant Payment Processor and Network roles it defines, not by AP2 itself.

Two updates that most write-ups miss. Google donated AP2 to the FIDO Alliance in April 2026, so "Google's protocol" is historically accurate but no longer describes its governance. And the mandate vocabulary changed: v0.1's Intent, Cart and Payment mandates became Checkout and Payment mandates in v0.2. Anything describing the older triple is documenting a superseded version.

Use it when the hard problem is accountability rather than transport.

Where it falls short. It defines how agents get permission to pay, not how money moves, so you still need a rail beneath it. It complements the others rather than competing.

Nevermined

A billing and entitlement layer that is also an x402 facilitator in its own right, defining a custom nvm:card-delegation scheme. It turns raw transfers into plans — prepaid balances or pay-as-you-go — meters usage per request, and interoperates with x402, AP2, A2A and MCP. Settlement spans real cards via Stripe, Braintree and Visa alongside USDC, EURC or any ERC-20.

On custody, it is more nuanced than "custodial": its docs state "balances are on-chain," cardholder funds sit with the PSPs, and Nevermined "never stores raw card numbers." It does mint and burn the on-chain credit token and trigger PSP charges, which makes it a trusted enforcement point without holding principal.

Use it when you are commercially monetizing an agent or MCP tool and need pricing models, metering and audit trails.

Where it falls short. You add a vendor in the authorization path above whatever rail you use.

Crossmint

The most complete single-vendor option: agent cards secured by Visa VIC and Mastercard Agent Pay, agent wallets for stablecoin micropayments over x402 and MPP, and stablecoin on-ramps across 160+ countries.

Custody deserves care, because Crossmint is frequently mislabelled. Its custody models documentation defines three: custodial, where "your organization holds all signing keys"; non-custodial, where "only the end user holds signing keys" and "Crossmint has no ability to authorize transactions or access the wallet's assets"; and hybrid, where an org-controlled recovery signer exists. Which one applies is a function of signer configuration across eight signer types. Its agent wallet is described in its own docs as non-custodial.

Use it when you want one vendor for wallets, compliance and fiat access.

Where it falls short. It is a hosted platform, so even in non-custodial configurations you take a vendor dependency, and hybrid is a common practical default because recovery signers can themselves sign.

L402

The Lightning-native HTTP 402 scheme from Lightning Labs, introduced in March 2020 as LSAT and later renamed L402. A server returns 402 with a macaroon and a BOLT11 invoice; the client pays, obtains the preimage, and retries with Authorization: L402 <macaroon>:<preimage>, which the server verifies against the payment hash committed inside the macaroon. Macaroon caveats allow attenuation, so a proxy can validate without hitting a Lightning node per request.

It is not dormant — Lightning Labs published L402 for agents in March 2026 calling the protocol production-ready and shipping Lightning Agent Tools.

Where it falls short. Its ecosystem is a fraction of x402's, its bLIP-0026 standardization is still an open pull request rather than ratified, and it stops at access control — nothing in it addresses delivery guarantees.

Hypawave

Hypawave settles in Bitcoin over Lightning and is non-custodial: buyers pay creators directly and Hypawave never holds principal. Two things distinguish it, both narrow on purpose.

Settlement is authorization. Verified settlement releases the AES-256-GCM decryption key exactly once, and the buyer decrypts client-side — no intermediary ever holds the plaintext or the funds.

What makes this more than a receipt is that the commitment happens before the buyer pays. An offer's terms_hash is a SHA-256 canonicalization of its amount, currency, pricing type, description, payment destination and declared price, snapshotted when the offer is activated; the content hash is bound when the first invoice is minted. If a seller changes any of it afterwards, the pay endpoint refuses the request with 409 terms_changed rather than quietly selling something else. So the buyer is not trusting a promise and checking afterwards — it is paying against immutable terms it inspected first, then verifying the delivered bytes against a hash committed in advance.

That eliminates two frauds the other platforms leave open: taking payment and delivering nothing, and substituting different content after the buyer has committed. Note precisely what it does not do — it cannot tell you the content is any good. A seller who commits to the hash of a worthless file delivers exactly that worthless file, provably. Quality requires reputation, not cryptography, and on that front x402's transferable receipts are arguably better positioned because they are designed to feed third-party reputation systems.

No account, no API key, no KYC. A seller is a secp256k1 keypair. The identity is created on first authenticated request, so there is no signup, no application, no onboarding step and nothing for a human to approve. Compare that honestly against the alternatives: ACP merchant onboarding is application-gated and US-only, Nevermined requires registering the agent, Crossmint requires an account, and even Hypawave's own managed path issues API keys through a dashboard only. The accountless path is the one with no human in the loop.

This is backed by an agent operating manual at /llms.txt and an OpenAPI document, machine-readable docs that are now table stakes — x402, Crossmint and L402 all publish equivalents. The part that is not table stakes is a deterministic signing test vector: a fixed key, body, timestamp and nonce with expected intermediate hashes, so an agent iterates locally until it reproduces them before ever calling the API. That is what "integrates unattended" means concretely, rather than as a slogan.

One honest boundary: Hypawave does not provision wallets. An agent needs operator-supplied Lightning credentials able to pay a BOLT11 invoice and return the preimage, and not every wallet handles automated confirmation cleanly. Everything else automates; funding the wallet does not.

Why the seller fee is charged upfront. Sellers pay a Hypawave-issued activation fee before an offer goes live, covering a time-bounded window that /renew extends. This is a direct consequence of non-custody rather than a pricing preference. A platform can only take a percentage of each settled payment if it sits in the payment path — that is what custody means. Because buyers pay the seller's Lightning address directly and Hypawave never receives principal, there is no moment at which a cut could be deducted. The postpaid alternative was tried and removed: an accountless seller identified only by a public key cannot be invoiced later. Charging upfront is the only model that keeps principal entirely out of our hands, and the tradeoff is real in both directions — worse than a per-transaction cut if you are testing the waters, better if you sell steadily.

Selling without an account. A seller identified only by a secp256k1 public key can list an offer and get paid, with no company, no bank account and no KYC. Stripe requires a legal entity; an autonomous agent cannot open one, and neither can many developers in countries card processors do not serve. Hypawave is one of the few systems designed specifically for accountless sellers — L402 is comparable in spirit, requiring only a Lightning node.

Where it falls short, honestly:

• Sats, not dollars. Price something at 300 sats and its dollar value moves with Bitcoin. If you need $0.02 to stay $0.02, a stablecoin platform is the better answer.
• Lightning wallets are harder than an EVM address. In our own testing a self-custodial phoenixd wallet failed on fee-credit handling for very small agent payments, and we fell back to a custodial Coinos wallet. Holding USDC on Base is easier. That is a real cost, not a quibble.
• One implementation, not a standard. x402 sits under the Linux Foundation and AP2 under FIDO, with independent implementations. Hypawave is a single protocol operator, so vendor risk is fair to weigh.
• No cards, no stablecoins, no physical goods.
• A small ecosystem. Far fewer agents speak this than speak x402.

How to choose

Work down this list and stop at the first line that matches.

1. The seller cannot get a merchant account — an autonomous agent, or a developer outside card-processor coverage. Hypawave or L402.
2. Delivery fraud is your actual risk and the goods are digital files or keys. Hypawave.
3. A human approves a retail purchase. ACP.
4. Continuous streamed or metered spend inside a session. MPP.
5. You need pricing models, credits or audit trails. Nevermined.
6. You want one vendor for wallets, ramps and compliance. Crossmint.
7. Anything else — an agent buying APIs or data priced in dollars. x402.

Layer AP2 underneath whichever you choose if you need to prove authorization after the fact.

Methodology and sources

Criteria. Platforms were assessed on settlement asset, custody model, whether a human must be present at checkout, what the protocol guarantees beyond payment, and whether a seller needs a legal entity. Recommendations are organised by use case; there is no single winner, and no ranking here is sponsored, paid for, or affiliate-linked.

Research date. All claims verified against primary sources on 29 July 2026. This category moves quickly — ACP shipped five spec revisions in seven months, AP2 changed stewardship, and MPP is four months old at the time of writing. Treat any claim older than a quarter as needing recheck.

Sources. Every factual claim above is drawn from official documentation, specifications or first-party announcements, linked inline at the point of use. We deliberately excluded competitor marketing pages and news aggregators for factual claims about competitors, because in preparing this piece we found several widely-repeated errors traceable to secondary sources — including an incorrect ACP launch date, x402 described as stablecoin-only, and Crossmint described as purely custodial. Where official documentation was ambiguous or self-inconsistent we say so rather than resolving it silently.

Known uncertainties. MPP's Tempo settlement token is named inconsistently across Stripe's docs, mpp.dev and tempo.xyz, so we make no claim about a specific token contract. x402's v2 specification lists only EIP-3009 assets under supported assets while its documentation describes broader Permit2 support — we follow the documentation and flag the drift. Whether Instant Checkout remains functionally completable in ChatGPT today is unclear from documentation alone.

Disclosure. We build Hypawave. We have tried to be harder on ourselves than on anyone else here, which is why the limitations section above is the longest one in the article. If you find an error, tell us and we will correct it and note the change.

Further reading

• How Hypawave works — the settlement-triggered execution model in detail
• Documentation — accountless seller and buyer flows end to end
• Live offers — things agents can buy right now