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 or search interface. Use UCP to reach Google Search and Gemini, or ACP for ChatGPT. Both run on cards, where Visa and Mastercard now have their own agent programs.
• 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 today. x402 added a Lightning spec in September 2026, but nothing implements it yet.
• 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; Lightning spec only
MPP	Open protocol, Stripe + Tempo	Stablecoins, cards, Lightning and more
ACP	Open protocol, OpenAI + Stripe, with Meta	Cards only
UCP	Open protocol, Google + Shopify + Stripe	The merchant's own payment processor
AP2	Authorization framework, FIDO Alliance	Not a rail
Visa and Mastercard	Card-network agent programs	Cards; Mastercard's machine program adds accounts and stablecoins
Nevermined	Billing layer, x402 facilitator	Cards, USDC, any ERC-20, MPP
Crossmint	Agent wallet, card and checkout 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, Stripe balance via Stripe	No
ACP	Merchant's processor, card rails	Yes
UCP	Merchant's processor; merchant stays merchant of record	Yes
AP2	Not applicable	Either
Visa and Mastercard	Issuer and processor, as with any card payment	Either
Nevermined	Depends on product; its Router pays from a custodial wallet	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 a payment header (PAYMENT-SIGNATURE in the v2 transport, X-PAYMENT in v1), 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 exact scheme specs now cover seventeen chain families. The newest, merged on 23 September 2026, is Bitcoin Lightning under its own lnbtc namespace: the server issues a BOLT11 invoice, the client returns the preimage, and the facilitator checks that SHA-256(preimage) == payment_hash. It changes less than it sounds, for now. It is a specification only, with no implementation in x402's TypeScript, Go or Python SDKs. It requires explicit millisatoshi amounts, so dollar strings like $1 "MUST be rejected" unless an app adds its own conversion. And it "provides no refund path."

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, and that is as true of the Lightning scheme as of the onchain ones. 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 x402-foundation/x402, run by the x402 Foundation under the Linux Foundation, which now counts more than fifty member organizations and appointed its first executive director on 1 October 2026. The older coinbase/x402 is a fork last updated in April 2026, and it understates both the extension set and the supported chains.

x402 has more momentum than any alternative, and the ecosystem keeps building on it: Cloudflare has announced a Monetization Gateway and Wallets on top of it, both still early access. 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 token spending limits, recipient restrictions, limits on specific contracts or functions, and expiry dates.

One detail matters for anyone assuming this is a single-chain play. MPP describes itself as "payment-method agnostic", and its documented methods now include Tempo, Stripe, generic EVM, encrypted card network tokens, Lightning, Solana, XRPL, Stellar, Monad, NEAR Intents and RedotPay. Since launch it has also added relays, which hand off payment validation and settlement, and identity support in its SDK.

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 still 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 settles into your Stripe balance. Its Shared Payment Tokens, US-only at launch, are now available in the US, Canada and select European countries, with a $0.50 minimum on card payments.

ACP (Agentic Commerce Protocol)

Announced on 29 September 2025 alongside OpenAI's Instant Checkout, and described in Stripe's docs as "an open standard created by Stripe, OpenAI, and Meta." Its governance document is more precise: OpenAI and Stripe are the founding maintainers, and Meta took the third Technical Steering Committee seat in April 2026. 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 out of scope, and Stripe's agentic commerce docs route that to MPP and x402 instead.

Two things are true at once here, and conflating them produces bad analysis. The protocol expanded quickly, with five releases through April 2026 adding carts, product feeds, delegated authentication and native MCP transport, though there has been no release since. 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 states it is "moving away from a standalone Instant Checkout experience in ChatGPT."

Use it when a person is buying real products through ChatGPT 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 is still in progress. OpenAI's product feeds target the US, with Canada and Mexico available once OpenAI confirms an integration, and onboarding is limited to approved partners. And in human-present retail it now has a larger rival in UCP.

UCP (Universal Commerce Protocol)

Google's open standard for agent checkout, first released in January 2026 and now on its fourth stable release, dated 25 August 2026. Google and Shopify are permanent members of its Governing Council, and Stripe joined in April 2026. A Payments Technical Council formed in September, and new councils for food ordering and lodging extend it beyond retail.

Like ACP it is human-present retail, and it is explicit that businesses "remain the Merchant of Record." Each business publishes a profile at /.well-known/ucp declaring its capabilities and payment handlers, transport runs over REST or JSON-RPC with MCP and A2A support, and AP2 provides the signed payment mandates. Its consumer face is Universal Cart, introduced at Google I/O 2026 and rolling out across Search and the Gemini app in the US.

Use it when you sell physical or retail goods and want to reach shoppers in Google Search and Gemini. If you sell through Stripe, it supports both UCP and ACP.

Where it falls short. It is not built for machine-to-machine payment. Money moves through the merchant's processor, so card rails, merchant accounts and KYC all still apply. And its large consumer reach today is Google's US surfaces.

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 particular action.

The specification is explicit that AP2 "operates as a security feature within a Commerce Protocol," and it is designed to be compatible with UCP. Payment processing belongs to the Merchant Payment Processor role it defines, with the Credential Provider and Network verifying. AP2 itself moves no money.

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. v0.2 remains the current version, and 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.

Visa and Mastercard agent programs

The card networks now run their own agent layers, and the card-based platforms above increasingly sit on them. At its June 2026 Payments Forum, Visa added Agent Score, which lets merchants check whether agents can navigate their sites, an Agentic Directory of agents and merchants it has verified, and a partnership with OpenAI for agents to initiate Visa payments within user-defined permissions.

Mastercard went further toward machines. Agent Pay for Machines, launched on 10 June 2026, targets high-frequency, low-value payments between agents, down to fractions of a cent, with agent credentialing, programmatic spending limits and settlement across cards, accounts and stablecoins. Its more than thirty launch partners include Stripe, Tempo, Coinbase, Adyen and Cloudflare.

Use it when you want agent payments to look like ordinary card payments to merchants, with limits enforced at the network rather than in your code.

Where it falls short. These are network programs you reach through an issuer, processor or platform such as Crossmint, not protocols you implement yourself, and they inherit card rails' requirements for merchant accounts. Neither network has published availability dates or volumes for its newest agent products. Mastercard's machine program is the one to watch, because it aims at the same micropayment ground as x402, MPP, L402 and Hypawave.

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, and since August 2026 MPP as a second rail.

Its newest product points the other way. The Router, launched in September 2026, "lets your agents pay any x402 or MPP service from one budget — without those services integrating Nevermined," and its catalog is now reachable from Claude and ChatGPT. Buyers no longer need to register anything; sellers still register their endpoints.

On custody it is more nuanced than either label. Card data is tokenized by the processor, and its docs state Nevermined "never stores raw card numbers." It mints and burns the on-chain credit token and triggers charges, which makes it a trusted enforcement point. But the Router signs payments from a custodial wallet, so what Nevermined holds depends on which product you use.

Use it when you are commercially monetizing an agent or MCP tool and need pricing models, metering and audit trails, or want one budget across x402 and MPP services.

Where it falls short. You add a vendor in the authorization path, above whatever rail you use, and with the Router a custodian as well.

Crossmint

The most complete single-vendor option. It offers agent cards where "Visa Intelligent Commerce and Mastercard Agent Pay hold the limit," agent wallets for stablecoin micropayments over x402 and MPP, stablecoin on-ramps across 160+ countries, and since September 2026 Agent Checkouts, a single API for agents to buy from any online store.

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 means "neither your organization nor the user can act unilaterally," and the same page warns that a user-controlled signer with an organization-controlled recovery method is hybrid, not non-custodial. Which one applies is a function of signer configuration across seven signer types. Its agent wallet is described in its own docs as non-custodial, though the custody page classes agent wallets hosted by a platform as custodial.

Use it when you want one vendor for wallets, cards, checkout, 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, and now to x402's Lightning scheme, since it rests on the same Lightning primitive. None of the three implements it, for the same reasons.

Where it falls short. Its ecosystem is a fraction of x402's. Its bLIP-0026 standardization pull request remains open, and Lightning Labs has said it will continue development in its own L402 repository instead. 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 limited to approved partners, and UCP and the card programs assume a merchant account. Nevermined requires sellers to register. 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.

Buyers can ask before they pay. Hypawave also carries private agent-to-agent messaging and free encrypted file handoffs, called Agent Waves. A buyer's agent can put a question to the seller's agent before any money moves, which matters for anything more involved than a fixed-price API call. We cover why in How do AI agents buy things?

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 activation fee is minted. The content is committed when that fee settles: the files are hashed, checked against the hashes the seller declared, and sealed to storage the seller can no longer write to.

If a seller changes any of the terms 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. Accountless 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 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.

Sellers with a Hypawave account can instead keep a prepaid balance that a fee is drawn from after each sale. An accountless seller identified only by a public key has no balance to draw on and cannot be invoiced later, so that postpaid model was tried for them and removed. 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.
• Bitcoin alone is no longer a differentiator. x402 now specifies Lightning payments, and MPP lists Lightning as a payment method. If implementations ship, agents can pay Lightning sellers through the dominant protocols. Our case rests on accountless selling, terms and content committed before payment, and the conversation before it, not on the rail.
• 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 today, and x402 once its Lightning scheme is implemented.
2. Delivery fraud is your actual risk and the goods are digital files or keys. Hypawave.
3. A human approves a retail purchase. UCP for Google Search and Gemini, ACP for ChatGPT.
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, cards, checkout 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 first verified against primary sources on 29 July 2026 and rechecked on 1 October 2026. The recheck added UCP and the Visa and Mastercard agent programs, and changed several entries: x402 gained a Lightning spec, Stripe's MPP tokens expanded beyond the US, Meta's role in ACP was clarified, Nevermined launched its Router, and Crossmint added Agent Checkouts. This category moves quickly. 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 still named differently by source: mpp.dev defaults to OUSD with USDC.e as a fallback, while Stripe settles via USDC.e, so we make no claim about a specific token contract. x402's v2 specification lists only EIP-3009 assets under supported assets while elsewhere in the same document, and in its documentation, it describes Permit2; we follow the documentation and flag the drift. x402's Lightning scheme exists only as a specification. Whether Instant Checkout remains functionally completable in ChatGPT is unclear from documentation alone. Neither Visa nor Mastercard has published availability dates or volumes for its newest agent products.

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
• How do AI agents buy things?, why the conversation has to come before the payment
• Documentation, accountless seller and buyer flows end to end
• Live offers, things agents can buy right now