If you need an autonomous agent to pay for something in 2026, the answer depends almost entirely on two questions: 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. Most comparisons skip this case. 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.

What each one is

Platform	Type	Settles in
x402	Open protocol, Linux Foundation	Any ERC-20, SPL or XRPL asset
MPP	Open protocol, Stripe + Tempo	Stablecoins, cards, Lightning
ACP	Open protocol, OpenAI + Stripe + Meta	Cards only
AP2	Authorization framework, FIDO Alliance	Not a rail
Nevermined	Billing layer, x402 facilitator	Cards, USDC, any ERC-20
Crossmint	Agent wallet platform	Stablecoins and cards
L402	Open protocol, Lightning Labs	Bitcoin over Lightning
Hypawave	Settlement protocol	Bitcoin over Lightning

How each one behaves

Platform	Custody	Human at checkout?
x402	Facilitators hold no principal	No
MPP	Self-custodial on Tempo, intermediated via Stripe	No
ACP	Custodial, card rails	Yes
AP2	Not applicable	Either
Nevermined	No principal held, balances on-chain	No
Crossmint	Custodial, hybrid or non-custodial by config	Either
L402	Non-custodial	No
Hypawave	Non-custodial	No

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. The official documentation is explicit that a facilitator "does not hold funds or act as a custodian," and instead "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." When x402.org says "stablecoin payments are the primary use case," that describes typical usage rather than a protocol restriction.

Networks are identified with CAIP-2, 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. There is no path for physical goods. More subtly, x402 proves payment rather than 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 actually arrived, and only the server can issue one. The extension itself notes that a valid signature "does not prove that the key was authorized to sign on behalf of the service," deferring 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 it 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, announced on 18 March 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." The client signs cumulative off-chain vouchers as usage accrues, and the server batches settlement. Spending caps are a separate mechanism, coming from Tempo access keys that support per-token limits, daily budgets, recipient allowlists and expiry.

One detail matters 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 is the obvious case, where opening a discrete payment per call is the wrong unit.

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

ACP (Agentic Commerce Protocol)

Announced on 29 September 2025 alongside OpenAI's Instant Checkout, and now described in Stripe's docs as "an open standard created by Stripe, OpenAI, and Meta." Those three hold 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." It is also human-present by design, since the architecture docs define the Buyer as "the human who wants to purchase something." Machine-to-machine payment is explicitly out of scope, and 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, with five releases through April 2026 adding carts, product feeds, delegated authentication and native MCP transport. Separately, standalone in-chat checkout was de-emphasized. On 24 March 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." 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, because 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 on 16 September 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. Mandates are encoded as SD-JWTs and exist in Open form, carrying 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 calling it "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. Treat it as a complement to the others rather than a competitor.

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, either 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 simply "custodial." Its docs state that "balances are on-chain," cardholder funds sit with the payment processors, and Nevermined "never stores raw card numbers." It does mint and burn the on-chain credit token and trigger 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. It offers 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 here, because Crossmint is frequently mislabelled. Its custody models documentation defines three. Custodial means "your organization holds all signing keys." Non-custodial means "only the end user holds signing keys" and "Crossmint has no ability to authorize transactions or access the wallet's assets." Hybrid describes a wallet with an org-controlled recovery signer. Which one applies is a function of signer configuration across eight signer types, and 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. 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 on every request.

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

One point deserves care, because being Lightning-native invites the assumption that L402 is atomic. It is not. The preimage is an authentication credential, not a decryption key, so the shape is: pay the invoice, receive a macaroon, and the server then chooses whether to honor it. The token is a receipt rather than a guarantee. Nothing binds payment to delivery, and there is no commitment to what the content was supposed to be.

Worth noting that the atomic construction described in the Hypawave section below is equally available to L402, since it rests on the same Lightning primitive. Neither implements it, and for the same reasons.

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, with no content commitment and no terms binding.

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: how little a human has to do, and what settlement actually guarantees.

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 against the alternatives. ACP merchant onboarding is application-gated and US-only. Nevermined requires registering the agent. Crossmint requires an account. 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 not only about onboarding friction. It is about who is structurally excluded. A seller needs no company, no bank account and no KYC, just a keypair. Stripe requires a legal entity, which an autonomous agent cannot open, and which many developers in countries card processors do not serve cannot obtain either. For those sellers this is not a nicer option but the only one that functions. Hypawave is among the few systems designed for it, and L402 is comparable in spirit, requiring only a Lightning node.

Machine-readable docs back this up: an agent operating manual at /llms.txt plus an OpenAPI document. Those are now table stakes, and 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.

The wallet, too, is agent-provisionable. Hypawave never custodies or issues the wallet. It lives entirely on the agent's side, and no credential is ever sent to us. But that does not mean a human has to create one. An agent can register a custodial Coinos wallet end to end by itself. Signup takes a username and password with no email, no CAPTCHA and no KYC, and it returns a ready-made NWC connection string, so nothing needs constructing. The MCP server's setup_wallet tool does all of this in one step once the operator consents.

The genuinely irreducible human steps are therefore two: consenting, and funding the wallet with sats. Everything else runs unattended, including keypair generation, identity creation, wallet provisioning, signing, payment, settlement confirmation and decryption.

Two caveats worth stating plainly. That self-provisioned wallet is custodial, with Coinos as the custodian, so keep only small working balances there. And principal settlements require a wallet that returns the preimage, which rules out most consumer wallets. Wallet of Satoshi and Phoenix mobile will pay an invoice but never expose the preimage, so they cannot unlock anything.

Settlement is authorization. Verified settlement releases the AES-256-GCM decryption key exactly once, and the buyer decrypts client-side. Hypawave never touches 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 pays against immutable terms it inspected first, then verifies 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.

And it is not fully atomic, so here is the trust it does ask for. Hypawave releases the key when it sees valid settlement proof, which makes it a settlement oracle rather than a cryptographic guarantee. The honest question is not whether trust exists but how small the trusted component is. Ours cannot take the principal, because it never touches it. It cannot fake settlement, because the preimage check is independently verifiable. Its only real failure power is delaying delivery, and the entitlement survives an outage.

A genuinely trustless version does exist, and it is worth knowing about. Set payment_hash = SHA256(K) where K is the file's decryption key, and Lightning's HTLC makes it impossible to pay without receiving the key: payment and delivery become one event with no platform in the middle. Add a zero-knowledge proof that the ciphertext decrypts to data matching a stated predicate, and you get atomic verified delivery. That is strictly stronger than what we do.

Two things keep it off the shelf. Atomicity covers the key, not the content, so paying atomically for a key that decrypts garbage just gets you atomic garbage unless you also carry the expensive ZK proof. And minting custom-preimage invoices requires a hold-invoice-capable node such as LND, which rules out the Lightning-address and LNURL sellers who make up most of the accountless base. Hash commitments are the pragmatic middle, which is the trade we made.

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, and 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, because an accountless seller identified only by a public key cannot be invoiced later. So charging upfront is the only model that keeps principal entirely out of our hands. The tradeoff is real in both directions: worse than a per-transaction cut if you are testing the waters, better if you sell steadily.

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.
• Self-custodial Lightning is genuinely harder than holding USDC. In our own testing, a self-custodial phoenixd wallet could not pay small agent invoices at all. Sats held below the channel-open threshold sit as "fee credit" rather than spendable outbound liquidity, so a wallet with a sufficient balance still fails, because only channel liquidity counts. The custodial NWC path sidesteps this entirely, which is why we recommend it, but that means trusting a custodian with a working balance. Either way there is a real trade here that an EVM address does not ask you to make.
• One implementation, not a standard. x402 sits under the Linux Foundation and AP2 under FIDO, both 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, being 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, meaning 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 were 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 a 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 when making factual claims about competitors. 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