Every week a developer asks me which one of these to pick. The framing of the question is the problem. They are not three options. They are three layers, and a serious agent payment stack in 2026 will probably touch at least two of them. The point of this post is to map the layers honestly so the decision stops being "pick one" and becomes "wire them in the right order."
I run MnemoPay. I have skin in this game. I will try to be fair about the other two anyway, because the alternative — talking trash about adjacent infrastructure — does not actually help anyone pick what to build on.
Coinbase Payments MCP, what it is.
The Coinbase Payments MCP server (the public version lives under github.com/coinbase as part of the AgentKit family) is a Model Context Protocol server that exposes onchain wallet operations as tools an agent can call. The headline operations: create a wallet, hold custody, send a transaction onchain, check balances, sign messages.
The native rail is the chain itself. Base is the default network. Other EVM chains are supported. The transactions are real blockchain transactions with real gas. The wallet is a Coinbase Developer Platform managed wallet, which means the custody model is delegated to Coinbase's infrastructure rather than the agent holding its own private key.
What it does very well: gives a Model Context Protocol-native agent a clean tool surface for onchain operations. If your agent needs to move value over a chain Coinbase supports, this is the most direct path from "agent decides to send" to "transaction confirmed on the chain."
What it deliberately does not do: identity outside the wallet, memory of past behavior, audit trail in any compliance-ready format, support for non-onchain rails. The product is intentionally focused. It is a wallet primitive, with a clean MCP surface. That is the lane.
x402, what it is.
x402 revives HTTP status code 402 ("Payment Required") and turns it into an actionable wire protocol. The mechanics: a server returns 402 with a payment requirement embedded in the response (asset, amount, destination, settlement details). The client, with a wallet capable of fulfilling the requirement, submits the payment, and retries the request with proof of payment in a header.
The protocol is now under the Linux Foundation as the x402 Foundation. The founding members include AWS, Google, Stripe, Visa, Mastercard, Amex, Coinbase, Cloudflare, Solana, and Stellar. The intent is to make x402 the neutral HTTP-level payment standard the way TLS is the neutral HTTP-level encryption standard.
What x402 does very well: defines the wire. A server can charge for an API call. A client can pay. The protocol is asset-agnostic, rail-agnostic, and amount-agnostic. Sub-cent works. Sub-tenth-of-a-cent works. The settlement layer underneath is a separate concern.
What x402 deliberately does not do: identity, reputation, memory, audit, dispute resolution. It is a HTTP-level handshake. It does not have an opinion on who you are, what you have done before, or how to settle a dispute if the call comes back wrong. Those concerns live above the protocol.
MnemoPay, what it is.
MnemoPay is the layer that lives above the rails. It defines an agent's identity (a DID with an Ed25519 key the agent controls), an agent's memory (a Merkle-chained recall layer), an agent's reputation (the Agent FICO score, a 300-850 number derived from receipts), and an agent's audit trail (Article 12-shaped bundles exportable on demand).
The payment rails MnemoPay supports today are Stripe (cards), Lightning (sub-cent), Paystack (Africa), and x402-pricing for HTTP 402 callers. Every rail flows through the same agent.charge(amount, reason, { rail }) interface. The agent's reputation aggregates across rails. The audit trail captures every call regardless of rail.
What MnemoPay does very well: portability. One identity, one credit score, one audit chain, across every rail the agent ever transacts on. If the agent moves from Stripe to Lightning to x402 over the course of a year, none of the reputation gets lost.
What MnemoPay deliberately does not do: define a new wire protocol, ship a new chain, hold custody of onchain funds. The rails belong to the rails. MnemoPay sits above them. If x402 wins as the HTTP standard, MnemoPay routes through it. If Stripe Machine Payments wins for card-style commerce, MnemoPay routes through that too.
The honest layer diagram.
Picture the stack from the bottom up.
| Layer | What it does | Examples |
|---|---|---|
| Settlement rail | Moves value | Base, Lightning, Stripe, Paystack, Solana |
| Wire protocol | Negotiates payment over HTTP | x402 |
| Wallet primitive | Holds keys, signs transactions | Coinbase Payments MCP, Lightning wallets, Stripe customers |
| Trust layer | Identity, reputation, memory, audit | MnemoPay |
| Agent runtime | Decides when to pay, what for | Your agent |
Read top to bottom: your agent decides to call a tool. The tool's server returns x402. Your agent's wallet (which may be a Coinbase Payments MCP server) fulfills the payment. The settlement happens on the underlying rail. MnemoPay signs and chains the receipt, updates the agent's reputation, and writes the audit record.
Nothing in that flow has two layers fighting for the same job. Each layer does one thing.
The feature matrix.
| Capability | Coinbase MCP | x402 | MnemoPay |
|---|---|---|---|
| Onchain custody | Yes (CDP wallets) | No | Through Lightning / Base via integration |
| HTTP 402 negotiation | No | Yes (defines it) | Routes through x402 |
| Multi-rail abstraction | No (onchain only) | Asset-agnostic but single-rail per call | Yes (Stripe, Lightning, Paystack, x402) |
| Agent identity (DID) | No | No | Yes (Ed25519 + DID) |
| Agent reputation | No | No | Yes (Agent FICO 300-850) |
| Memory layer | No | No | Yes (Merkle-chained) |
| Audit bundle (EU AI Act Article 12) | No | No | Yes (buildArticle12Bundle()) |
| License | Open source | Open standard (Linux Foundation) | SDK is Apache 2.0 |
The matrix is not a beauty contest. Each tool's empty cells are not failures. They are scope decisions. Coinbase Payments MCP is not trying to be an audit layer. x402 is not trying to be a wallet. MnemoPay is not trying to be a chain.
The mistake is picking one for a job the others were designed for. The fit is in how they stack, not in which one wins.
Where each one fits, concretely.
Pick Coinbase Payments MCP when:
Your agent needs to hold or send value onchain, you want a managed custody model, and you do not want to write key management code. The MCP surface is clean. The wallet primitive is battle-tested. If the only payment your agent will ever make is onchain, this is sufficient by itself.
Pick x402 when:
You are building an API that wants to charge per call, you want the wire protocol to be neutral (not lock the caller to a single rail), and you can accept that your callers might be paying in any of half a dozen settlement assets. The protocol is the right abstraction for HTTP-native commerce. The settlement is somebody else's problem (which is the right design).
Pick MnemoPay when:
Your agent transacts across more than one rail, you need the agent's reputation to follow it across platforms, you have an EU AI Act audit obligation, or you want a Merkle-chained memory layer the agent cannot rewrite. The trust layer is the part that does not exist as a primitive in either of the other two products.
Use all three when:
You are building anything serious in 2026. The agent's wallet is Coinbase Payments MCP (or a Lightning equivalent, or a Stripe customer). The wire protocol is x402 when calling x402-priced APIs. The trust layer is MnemoPay, sitting above the rails, aggregating the agent's behavior into one portable identity.
Competitive context, fair version.
I want to be careful here. The temptation, when writing a comparison post, is to find the worst aspect of each competitor and lean on it. I have been on the receiving end of those posts and I do not respect the people who write them.
So the honest version: Coinbase is a much larger company than MnemoPay. Their wallet primitive has years of production scale behind it. Their MCP integration is recent but built on a stable foundation. If your agent's needs are onchain-only and Coinbase-rail-aligned, betting on them is a defensible call. They will be around in five years. The cost is the layer they do not ship: identity portable across non-Coinbase rails, reputation observable from outside the wallet, audit trail that satisfies a Notified Body.
x402 is a standard. It is not a competitor to a trust layer the way one product is a competitor to another product. It is closer to TLS than to a SaaS. If you are building anything HTTP-native in 2026, you should know how x402 works. The trade-off with x402 is that, like all neutral standards, it does not have an opinion on what comes back when the call completes. The trust gets added by a layer above it. MnemoPay is one of those layers. AGT.finance is another. Methux is another.
The market is not yet at the point where one trust layer has won. It will get there. The candidates will probably be the ones that ship the most receipts, audit the cleanest, and stay neutral on rail selection. That is the lane we are trying to occupy. It might be the lane somebody else occupies. The reader's job is to evaluate the work, not the marketing.
The one-sentence answer to "which one do I pick."
Pick the layer that matches the job. If the job is "hold and send onchain value from an agent," pick Coinbase Payments MCP. If the job is "charge per HTTP call," wire x402. If the job is "give my agent one identity and one reputation across every rail it will ever touch, plus an audit bundle I can hand a regulator," wire MnemoPay.
If the job is all three, wire all three. The integration cost is small. The flexibility is the whole point.
That is the honest answer. The portable trust layer essay has more on why we built MnemoPay the way we did. The Agent FICO writeup has more on the reputation math. The SDK is Apache 2.0. If you want to argue with the implementation, the code is the place to do it.