❓ Before you trade

x402, MPP, AP2 or escrow: which payment protocol does your agent need?

They answer different questions. The protocols answer how an agent sends money and proves it was authorised. Escrow answers who holds it until the other side delivers. Most real purchases need both.

The agent payment space has several protocols and a lot of confusion about what each one does. The useful way to sort them is by the question each one answers. "How does the agent send money, and how does the server know it was paid?" is one question. "How does the merchant know a human authorised this?" is another. "Who holds the money until the other side delivers?" is a third, and it is the one that decides whether a loss is recoverable.

Sorted by the question they answer

Pay-then-serve (x402 and similar)
The agent pays per request, on-chain, and the server responds. Answers "how to pay for an API call". No one holds anything; delivery failure is unrecoverable by design, which is acceptable because the amounts are tiny. Right for metered services, wrong for purchases.
Mandate / authorisation protocols (AP2 and similar)
The user signs a mandate that proves to a merchant that a human authorised the agent to spend, within limits. Answers "was this spend authorised". Does not hold money and does not help if the merchant does not deliver.
Merchant payment protocols (MPP and similar)
A way for agents to pay merchants through existing card and wallet rails, with the merchant’s usual protections. Answers "how does an agent check out". Disputes go through the card network, if the rail has one.
Escrow (iEscrow)
The money is held by a neutral party under a written trade and released on a condition or a human decision. Answers "who holds it until delivery is checked". Works for P2P crypto, goods, services and milestones; the agent prepares, the human commits.

How to choose

  • Cents per call, thousands of calls, failure costs nothing: pay-then-serve.
  • A one-off purchase from a merchant with its own protections: a merchant protocol, with a mandate so the spend is provably authorised.
  • Buying crypto from a person, paying a freelancer, settling a deal between two companies, anything where the other side can simply not deliver: escrow, with the human approving the money step.
  • Monetising your own MCP server: that is a metering problem, not an escrow problem. Do not use escrow for it.
They stack. An agent can hold a mandate that proves it was allowed to open a trade, open it on iEscrow, and let the human approve the funding. The protocols handle permission and payment; escrow handles custody until delivery.
Was this article helpful?

Related articles

I paid and the seller won't release my crypto. What now?
What you can do when you already sent the money and the other side went quiet, is asking you to cancel, or says the payment never arrived.
The buyer sent a screenshot but the money isn't in my account. Do I release?
No. The only payment that counts is money you can see in your own account, for the exact amount, from the person you are trading with.
Which payment methods can be reversed after you sell crypto (and why PayPal and Venmo aren't on iEscrow)
Crypto leaves and does not come back. The danger for a seller is a fiat payment that can be pulled back weeks later. Here is which rails can do that.
Buying USDT from someone on Telegram or WhatsApp without getting scammed
The problem is not the chat app. The problem is paying a stranger first. Here is how to take that same deal somewhere the crypto is locked before you pay.
Still have questions?
The support team is here to help.
Contact support