DEV Community: Quinn

x402 vs AP2 vs ACP: Which Agent Payment Protocol Should You Build On? (2026)

Quinn — Tue, 29 Sep 2026 11:42:31 +0000

Disclosure: I work on distribution for PinkWallet, which is building an agentic payments product (mentioned once near the end, honestly, as one option in early access). Every claim about a protocol below links to that protocol's own docs, spec repo, or announcement, checked today.

Short answer: Don't pick one protocol as "the" agent payment standard — pick based on what your agent is actually doing. If it's paying another service per API call or per piece of data, look at x402 (or MPP, a newer entrant covering the same layer). If it needs to prove what a human actually authorized before money moves, look at AP2. If it's checking out with a merchant inside a chat interface, look at ACP (or UCP on Google's surfaces). Most real systems end up combining more than one, because they answer different questions: how does the payment settle, who authorized it, and how does checkout happen.

This is a companion to our longer side-by-side comparison, written as a decision guide: find your situation below, then follow the link to the actual spec.

Find your situation

1. My agent pays another service per API call, per dataset, or per piece of content

This is the HTTP-402 layer. Two protocols standardize it:

x402: "an open‑source protocol that turns the dormant HTTP 402 Payment Required status code into a fully‑featured, onchain payment layer for APIs, websites, and autonomous agents" (x402 docs). Settlement is on-chain today — "any ERC-20 token" on Base (mainnet and Sepolia testnet) or "any SPL token or Token-2022 token" on Solana (mainnet and testnet), fee-free (x402 docs). The spec's own README describes it as "network, token, and currency agnostic" and open to future networks, "both crypto and fiat" (x402-foundation/x402). You do not need a Coinbase account — it's an open protocol under Apache-2.0 (x402 docs).
- First step: quickstart for buyers if your agent is the one paying, or quickstart for sellers if your API is the one charging. SDKs exist for TypeScript, Python and Go.
MPP (Machine Payments Protocol), announced by Stripe on March 18, 2026 as an open standard "co-authored by Tempo and Stripe" (Stripe), describes itself as "the open standard for machine-to-machine payments via HTTP 402" (mpp.dev) — the same layer as x402, but with more rails out of the box: Stripe says it lets businesses "accept payments directly from agents, in stablecoins as well as fiat with cards and buy now, pay later payment methods via Shared Payment Tokens (SPTs)" (Stripe). mpp.dev also lists Bitcoin (Lightning), Solana, XRP Ledger, Stellar, Monad and NEAR among supported rails.
- First step: MPP quickstart — "Get started with MPP in minutes." SDKs in TypeScript, Python, Rust, Go and Ruby.
- Pick x402 if you're already stablecoin-native and want the protocol with the longer track record and Linux Foundation governance. Pick MPP if you need card or fiat fallback in the same integration without bolting on a second protocol.

2. My agent shops for a person, inside a chat interface

This is checkout, not raw payment settlement.

ACP (Agentic Commerce Protocol) is "a new open standard codeveloped by Stripe and OpenAI that enables programmatic commerce flows between buyers, AI agents, and businesses" (Stripe). The buyer approves in the chat; the business stays "merchant of record, retaining control over which products can be sold, how they're presented, how transactions are processed, and how orders are fulfilled" (same source). ACP "can connect with any commerce backend and payments infrastructure" — it's not Stripe-exclusive.
- First step: the spec lives at agenticcommerce.dev and on GitHub (OpenAPI + JSON Schema under spec/). For the agent side, see OpenAI's commerce docs; for the payment side, Stripe's agentic commerce docs.
If you're building specifically for Google's AI surfaces (AI Mode, Gemini), the equivalent is UCP — see situation 3.

Underneath either, you may still want AP2 for the authorization record — see situation 4.

3. I'm a merchant and I want AI agents to be able to buy from me

Two paths, depending on where your customers' agents run:

ACP, as above — get listed as purchasable inside ChatGPT (or another ACP-compatible agent surface) via Stripe. First step: docs.stripe.com/agentic-commerce.
UCP (Universal Commerce Protocol), announced January 11, 2026, is "an open-source standard designed to power the next generation of agentic commerce," developed by Google "in collaboration with industry leaders including Shopify, Etsy, Wayfair, Target, and Walmart" (Google Developers Blog). It's "compatible with Agent Payments Protocol (AP2)" (same source) — so a UCP integration can carry AP2 mandates for authorization. As a merchant you need an active Merchant Center account and to follow "the Google integration guide to setup your Merchant Center account and complete a merchant interest form" (same source).
- First step: Google's merchant integration guide; spec and Python samples at github.com/universal-commerce-protocol/ucp.

If you sell through both ChatGPT and Google's AI surfaces, expect to implement both — they're not interchangeable, even though both sit at the "merchant checkout" layer.

4. I need a signed record of exactly what the user authorized, for enterprise audit or compliance

This is what AP2 is for, and none of the others do it.

AP2 uses "Mandates — tamper-proof, cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions," signed by verifiable credentials (Google Cloud). Concretely: an initial instruction ("find me new white running shoes") is captured in an Intent Mandate, which "provides the auditable context for the entire interaction." When the agent presents a cart and the user approves it, that approval signs a Cart Mandate, which "creates a secure, unchangeable record of the exact items and price" (same source). That's your audit trail — not a general ledger, but a signed record of what was asked for and what was approved, independent of which rail actually moves the money.

First step: github.com/google-agentic-commerce/AP2 (Apache-2.0). Install with uv pip install git+https://github.com/google-agentic-commerce/AP2.git@main, or clone the repo and run a sample scenario directly, e.g. bash code/samples/python/scenarios/a2a/human-present/cards/run.sh. Reference implementations exist in Python, Go and Android.

AP2 itself doesn't move money — it hands off to a rail. Google's own extension wires it to x402 for stablecoin payments (see "How they combine," below), and it also covers cards and real-time bank transfers.

5. My agent has to pay with cards or fiat, not crypto

x402's published SDKs settle on-chain only today — every current package is chain-specific (EVM, Solana, Aptos, Stellar, and others). Its own README says the protocol "aims to support all networks (both crypto & fiat)" (x402-foundation/x402), but that's a stated direction, not a shipped fiat rail. Three options if you need cards or fiat now:

AP2: rail-agnostic by design — "it also supports different payment types – from credit and debit cards to stablecoins and real-time bank transfers" and "establishes a payment-agnostic framework for users, merchants, and payments providers to transact with confidence across all types of payment methods" (Google Cloud). Use this if you also need the mandate/audit trail from situation 4.
ACP: card rails through existing processors, merchant stays merchant of record (situation 2/3).
MPP: explicitly supports "fiat with cards and buy now, pay later payment methods" alongside stablecoins in a single integration (Stripe) — closest thing to "x402's HTTP-402 model, but with a card option built in."

Side-by-side

	x402	AP2	ACP
Backed by	x402 Foundation under the Linux Foundation; originally built by Coinbase	Google; donated to the FIDO Alliance	OpenAI and Stripe
What it standardizes	Requesting and settling a payment for an HTTP resource (HTTP 402)	Cryptographically-signed proof of what the user authorized (Intent + Cart Mandates)	Agent-to-merchant checkout inside a chat/agent surface
Rails	On-chain: any ERC-20 token on EVM chains, any SPL/Token-2022 token on Solana; spec describes itself as network/token/currency agnostic	"Credit and debit cards to stablecoins and real-time bank transfers" — rail-agnostic	Card rails via existing payment processors; "any compatible payment provider"
Status per own docs (checked 2026-09-29)	Operational under Linux Foundation governance since July 14, 2026 — "40 organizations have joined as members," including Premier members Adyen, AWS, American Express, Circle, Coinbase, Google, Mastercard, Shopify, Stripe and Visa among others (Linux Foundation)	Donated to FIDO Alliance April 28, 2026, to "remain platform-agnostic and community-led" (Google)	"Open source, Apache 2.0 licensed, and community-designed" (Stripe); repo badge marks it "currently in `beta`" (GitHub)
License	Apache-2.0	Apache-2.0	Apache-2.0
Spec / code	github.com/x402-foundation/x402, docs.x402.org	github.com/google-agentic-commerce/AP2	agenticcommerce.dev, GitHub

Note: the original coinbase/x402 GitHub repo is now a fork; the maintained repo has moved to x402-foundation/x402 under the new foundation's governance, confirmed by checking the repo directly today.

How they combine

AP2 + x402. Google built the A2A x402 extension "in collaboration with Coinbase, Ethereum Foundation, MetaMask and other leading organizations," extending AP2's core constructs to x402 for stablecoin settlement — "a production-ready solution for agent-based crypto payments" (Google Cloud), at github.com/google-a2a/a2a-x402. AP2 answers "was this authorized"; x402 moves the money.
UCP + AP2. Google states UCP is "compatible with Agent Payments Protocol (AP2)" for the authorization layer (Google Developers Blog).
One provider, multiple protocols. Stripe ships integrations for both ACP and MPP, and is a Premier member of the x402 Foundation — a payments provider isn't limited to backing one of these.

What none of them solve for you: spending limits

x402 settles a payment. AP2 proves a human authorized a purchase. ACP and UCP run a checkout. None of the three gives you a budget at the protocol level. Nothing in these specs by itself stops an agent from making 500 individually-valid x402 payments in an hour, or from having an AP2 Intent Mandate that's scoped too broadly, or from checking out via ACP for more than your finance team is comfortable with. Per-agent spending caps, merchant allowlists, and approval thresholds are a layer you (or your wallet/platform provider) still have to build on top. MPP's docs say this directly: "By building spending controls on top of MPP, agents can pay in the background while staying within the budget, time window, and tools you intended" — and point to rail-level tools such as Tempo access keys, which set token spending limits and recipient restrictions (mpp.dev). See our deeper writeup on AI agent spending controls if you haven't built that layer yet.

Pink Agentic AI Payment (early access, from PinkWallet) is being built to enforce per-agent spending caps at the MCP layer, before a payment executes. It's in early access (waitlist), not something you can sign up for and use today.

FAQ

Can I use more than one of these protocols in the same system?
Yes, and the interop section above describes real examples of it — AP2 for authorization plus x402 for settlement is the combination Google explicitly built and documented.

Do I need blockchain experience to integrate x402?
You need a wallet that can sign a payment and, on the server side, a facilitator to verify and settle it — x402's own FAQ states you don't need any Coinbase-specific product to use the protocol, since it's open under Apache-2.0.

Is MCP one of these payment protocols?
No. The Model Context Protocol is how an agent discovers and calls tools — including a payment tool — not a payment protocol itself. It sits one layer up from all three protocols covered here.

Which protocol should I default to if I'm not sure yet?
Match it to what your code actually does this week, using the five situations above, rather than betting on which protocol "wins" — multiple of these are governed by different organizations (Linux Foundation, FIDO Alliance, OpenAI/Stripe) and are still evolving quickly enough that a wrong bet is cheap to unwind if you keep the payment logic behind your own interface.

x402 vs AP2 vs ACP: the full comparison, with adoption data
What is the Agentic Commerce Protocol (ACP)?
Agentic Payments Readiness Report 2026 — which of 13 payment providers self-describe support for each protocol, in their own docs

How to Give an AI Agent a Spending Limit (and Actually Enforce It Before It Pays)

Quinn — Mon, 28 Sep 2026 23:08:36 +0000

Disclosure: I work on distribution for PinkWallet, which is building an agentic payments product (mentioned once near the end, honestly, as one option in early access). Every third-party claim below links to that vendor's own docs, checked on the date noted.

Short answer: A spending limit only counts if it's enforced somewhere the agent can't talk its way around — which in practice means a policy check that runs in code, outside the model's context, before a payment tool call is allowed to execute. Telling the agent its budget in the system prompt is not a spending limit; it's a suggestion the model can forget, get talked out of, or have overridden by a prompt injection. Below: where a limit can actually live, the specific controls you need, a runnable policy-check wrapper you can paste and run, and how today's payment providers handle (or don't handle) this.

Where a limit can actually be enforced

There are five places a "don't spend more than X" rule can live. Only some of them are enforcement; the rest are advice.

Layer	What it can enforce	Bypassable by the model?	Example
The system prompt	Nothing, technically — it's a request	Yes, trivially (bad instruction-following, prompt injection, or the model just being wrong)	"You may spend up to $50" in a system message
Agent framework / tool wrapper	A code-level check before the tool function runs	No, if the agent has no other path to the underlying payment call	A custom `pay()` wrapper like the one below; LangChain/LlamaIndex tool middleware you write yourself
MCP server / tool layer	Whatever the server's own tool implementation checks before calling the payment API	No, if the server is the only credentialed path — yes, if the agent also has direct API access	Stripe's MCP server requires human confirmation before certain `stripe_api_write` actions such as refunds and outbound payments (Stripe MCP docs)
Payment provider	Caps, allowlists, or scopes tied to the credential itself, independent of any code you write	No — this is the hard floor even if your own code has a bug	Circle Agent Wallets expose per-transaction/daily/weekly/monthly spending limits and address allow/blocklists (Circle, GitHub); Coinbase's Agentic Wallet documents configurable per-session and per-transaction caps (Coinbase docs)
Card network / bank rail	Whatever the issuing bank or network allows on that specific card or account	No	A virtual card with a hard limit set by the issuer

The practical rule: the system prompt is not a control, it's documentation. Real enforcement starts at the tool-wrapper layer and gets stronger the closer it sits to the actual money movement. The MCP landscape is uneven here — most payment-capable MCP servers we checked ship write tools (refunds, payouts, order creation) that execute immediately once a credential is configured, with the spend limit left entirely to whatever scope you put on that credential, not to a purpose-built budget feature inside the MCP server itself. Stripe and Airwallex were the two exceptions we found with a built-in confirmation gate: Airwallex's agent tools "do not initiate money-out actions (transfers, FX conversions, or payouts)" by default and prompt for confirmation on write actions (Airwallex AgentOS docs).

That's why you generally want at least two of these layers active at once: a code-level check you control (fast to change, but only as strong as your code), plus a provider- or network-level cap (slower to change, but holds even if your code has a bug).

The policy primitives

These are the individual controls a real policy is made of. Mix and match based on what the agent actually needs to do — a research agent buying API credits and a procurement agent paying SaaS invoices don't need the same numbers.

Per-transaction cap — the hard ceiling on any single payment. Set it to the price of the largest legitimate item the agent buys, not a round number.
Rolling budget — a daily/weekly/monthly total, separate from the per-transaction cap, so an agent can't stay under the per-transaction limit while still spending unbounded amounts over time.
Merchant/endpoint allowlist — constrains who gets paid, not just how much. A cap alone doesn't stop the right amount going to the wrong party.
Category blocks — a second-layer blocklist for things that should never be payable regardless of amount (payroll, gift cards, crypto exchanges), because an allowlist alone can't anticipate every bad actor you'd want to exclude by category.
Human-approval thresholds — not a hard block: it routes the transaction to a human for a yes/no before it executes. Lower than the per-transaction cap, so mid-size or novel purchases still get a look.
Velocity limits — caps the rate of spending (transactions per hour/day), independent of size. A per-transaction cap doesn't stop 200 small, individually-legitimate-looking payments in an hour.
Kill switch — an immediate way to stop an agent from transacting at all, separate from normal credential rotation.
Audit log — a record, per transaction, of which agent acted, under what policy, for how much, to whom, and with what approval — the thing you need after something goes wrong.

Velocity limits and dedicated kill-switch workflows are the two controls we found least documented among payment providers as of this writing — most leave both to you to build at the policy layer. (Full source list in the spending policy template.)

A runnable example

This is a minimal, provider-agnostic policy check in plain Node.js — no SDK, no network calls. The pattern is what matters: the agent's "pay" tool is never the raw payment call, it's a wrapper that checks policy first and only calls the real function if the check passes.

policy.js — the check itself:

export function checkPolicy(policy, req, ledger) {
  if (req.amountUsd <= 0) {
    return { decision: "deny", reason: "non-positive amount" };
  }

  // A retried request with the same key must not be treated as a new charge.
  if (ledger.alreadyProcessed(req.agentId, req.idempotencyKey)) {
    return { decision: "deny", reason: "duplicate idempotency key — already processed today" };
  }

  const merchant = req.merchant.toLowerCase();
  if (!policy.merchantAllowlist.includes(merchant)) {
    return { decision: "deny", reason: `merchant "${merchant}" is not on the allowlist` };
  }

  if (req.amountUsd > policy.perTransactionCapUsd) {
    return {
      decision: "deny",
      reason: `amount $${req.amountUsd} exceeds per-transaction cap $${policy.perTransactionCapUsd}`,
    };
  }

  const projectedTotal = ledger.spentTodayUsd(req.agentId) + req.amountUsd;
  if (projectedTotal > policy.dailyCapUsd) {
    return {
      decision: "deny",
      reason: `would bring today's total to $${projectedTotal}, over daily cap $${policy.dailyCapUsd}`,
    };
  }

  if (req.amountUsd >= policy.approvalThresholdUsd) {
    return {
      decision: "require_approval",
      reason: `amount $${req.amountUsd} is >= approval threshold $${policy.approvalThresholdUsd}`,
    };
  }

  return { decision: "allow", reason: "within cap, allowlisted, below approval threshold" };
}

pay-tool.js — the wrapper the agent actually calls. Note there's no code path from the agent to executePaymentUnsafe that skips checkPolicy:

export async function pay(policy, req, ledger, onApprovalNeeded) {
  const result = checkPolicy(policy, req, ledger);

  if (result.decision === "deny") {
    return { status: "denied", reason: result.reason, request: req };
  }
  if (result.decision === "require_approval") {
    await onApprovalNeeded(req);
    return { status: "pending_approval", reason: result.reason, request: req };
  }

  const executed = await executePaymentUnsafe(req);
  ledger.record(req.agentId, req.idempotencyKey, req.amountUsd);
  return { status: "allowed", reason: result.reason, result: executed };
}

Running eight scenarios against one agent (per-transaction cap $50, daily cap $90, allowlist of three vendors, approval threshold $40) against this wrapper, on Node v22.21.0:

1. Normal purchase, allowlisted, under threshold: allowed — within cap, allowlisted, below approval threshold
2. Same amount again but new key (should still be allowed, under daily cap): allowed — within cap, allowlisted, below approval threshold
3. Retry with the SAME idempotency key as #1 (simulates a network-retry double-charge attempt): denied — duplicate idempotency key — already processed today
4. Amount above per-transaction cap: denied — amount $75 exceeds per-transaction cap $50
  -> [approval channel] would notify a human about: $45 to aws.amazon.com
5. Amount at/above approval threshold but under per-transaction cap: pending_approval — amount $45 is >= approval threshold $40
6. Merchant not on the allowlist (simulates a prompt-injected redirect): denied — merchant "totally-not-a-scam.example" is not on the allowlist
7. Another normal purchase (brings today's total to $75 of the $90 daily cap): allowed — within cap, allowlisted, below approval threshold
8. Legitimate small purchase that would push the daily total over the cap: denied — would bring today's total to $105, over daily cap $90

Total spent today for research-agent-01: $75

That's the real output from running node demo.js locally. The full source (policy.js, pay-tool.js, demo.js) and a README are in agent-spending-limit-example (MIT). The SpendLedger here is an in-memory Map, which is fine for a demo and not fine for production — see the race-condition note below.

Common failure modes

Prompt injection → spend. A tool result, a scraped webpage, or a document the agent reads can contain text instructing it to make a purchase. The system prompt telling the agent "only buy from the allowlist" doesn't stop this — the allowlist check has to live in code the injected text can't reach, which is exactly why the wrapper pattern above puts the check outside the model's context entirely.
Retries → double charges. Network timeouts and agent retry loops are common; if your "did this succeed?" check happens after a timeout, the agent (or your own retry logic) may call pay again for the same intent. An idempotency key checked before execution (scenario 3 above) is the fix — first-class API-level idempotency keys are a common feature (see Stripe's idempotent requests), but you need your policy layer to honor them too, not just the payment API.
Currency confusion. A cap defined as "50" without a currency is a bug waiting to happen the first time an agent operates against a non-USD price or a stablecoin quoted in a different denomination. Every cap and log entry needs an explicit currency field.
Budget race conditions. If two payment requests for the same agent are checked concurrently, both can read the same "spent so far" total, both pass the daily-cap check, and both execute — busting the cap. The in-memory Map in the demo above is illustrative only; a real ledger needs an atomic increment-and-check (a database transaction, a single-writer queue, or a provider that enforces the cap itself as a second line of defense).

What today's providers actually let you enforce

Verified against each vendor's own docs (checked 2026-09-27/28; not re-verified since):

Circle Agent Wallets document per-transaction/daily/weekly/monthly spending limits and address allow/blocklists, and gate limit changes behind an OTP the agent never sees directly ("the agent hands the user a verbatim command to run in their own terminal so the OTP never passes through agent storage") — github.com/circlefin/skills.
Coinbase's Agentic Wallet documents configurable caps per session and per transaction — Coinbase docs.
Stripe's MCP server requires human confirmation before certain write actions like refunds and outbound payments, via a link that expires after 24 hours if unconfirmed; starting October 31, 2026, it also stops accepting full-access secret keys or restricted keys without an Agent tag (Stripe MCP docs).
Crossmint describes agent credentials as "scoped, explicit, and revocable," using one-time or encrypted credentials rather than a raw card number — Crossmint docs.
Skyfire lets you set spending limits per agent at the wallet/dashboard level — Skyfire product page.
x402 (the pay-per-request HTTP protocol) settles one payment per request and doesn't itself carry a budget concept — any per-agent cap has to be enforced by whatever signs the payment on the agent's behalf, one layer above the protocol (x402 FAQ).
Most traditional processors we checked — Adyen, PayPal, Square, Checkout.com, Razorpay — inherit spend control from the merchant's existing API-key or dashboard-role permissions, which were designed for human developers, not for bounding one autonomous agent's spend. None of the pages we checked for those five described a per-agent budget feature.

Where this leaves you: provider-level caps (Circle, Coinbase) are the hard floor that holds even if your own code breaks, but they're not universal across vendors yet, and velocity limits and dedicated kill switches are thin on the ground industry-wide. That's the gap a code-level policy wrapper like the one above is for.

PinkWallet is building Pink Agentic AI Payment, an MCP server plus a console for defining exactly this kind of rule — per-agent caps, allowlists, and approval thresholds enforced at the MCP layer before a payment executes. It's in early access — not live yet, no claims otherwise — alongside the other options named above.

FAQ

Is putting the limit in the system prompt good enough for a low-stakes agent?
No, for the same reason input validation belongs in code, not in a comment telling users to behave. Even a "low-stakes" agent can be redirected by a prompt injection it reads from a tool result; a system-prompt limit has no mechanism to stop that.

Do I need both a provider-level cap and my own policy code?
Where you can get both, yes. The provider-level cap (Circle's or Coinbase's, for example) is the floor that holds even if your policy code has a bug; your own policy layer is what lets you apply consistent rules — allowlists, approval routing, velocity limits — across multiple providers and agents, which no single provider's cap will do for you.

What's the difference between a cap and an approval threshold?
A cap is a hard limit the agent cannot exceed. A threshold is lower and doesn't block anything — it routes the transaction to a human for a decision before it executes. Most real policies need both, at different amounts.

Can velocity limits be enforced by the payment provider instead of my own code?
Not reliably today — velocity limits were the least-documented control among the payment providers checked for this article. Plan to implement rate limiting for agent spend at your own policy/orchestration layer rather than assuming a provider handles it.

Does an MCP server automatically give me spending controls?
No. Most payment-capable MCP servers we checked ship write tools that execute immediately once a credential is configured; the spend limit comes from how narrowly you scope that credential and whether you've added your own policy check in front of the tool call, not from the MCP protocol itself.

Payment MCP Servers Compared (2026): Which Providers Let AI Agents Move Money

Quinn — Mon, 28 Sep 2026 22:32:25 +0000

Disclosure: I'm the founder of PinkWallet, which is building Pink Agentic AI Payment — an MCP server plus a policy engine for AI agent payments — so I'm not a neutral party in this space. Every claim below is tied to a verbatim quote from each vendor's own docs or official GitHub org (sources linked inline); the full dataset is open under CC BY 4.0 if you want to check or dispute a row.

Of 16 major payment companies checked, 13 publish an official MCP server or agent SDK on their own domain or GitHub org that can be opened and read directly; two others (Visa, Mastercard) publish documentation-style MCP servers plus separate agent-commerce programs (Trusted Agent Protocol, Agent Pay) that are not themselves money-moving MCP servers. The dominant pattern among the 13: most ship money-moving tools (refunds, payouts, orders, payment links) live by default, with control inherited from ordinary API-key or OAuth scopes rather than a purpose-built per-agent spending limit. At the MCP-server layer itself, only two vendors in this set, Stripe and Airwallex, document an explicit agent-specific control (a human-confirmation gate and a default-deny-on-money-out design, respectively). Per-agent budgets do exist elsewhere, mainly in crypto-native agent wallets (Circle, Coinbase, Skyfire), but they sit outside the MCP server.

Comparison table

Company	Official MCP?	Hosted/local	Auth	Can move money by default	Built-in spending controls	Status	Source
Stripe	Yes	Both (hosted + local config)	OAuth or Agent API key	Yes, via `stripe_api_write`	Human-confirmation gate on sensitive writes; agent-tagged keys required from Oct 31, 2026	GA (some sub-tools Preview)	docs.stripe.com/mcp
PayPal	Yes	Both	Access token (sandbox/production)	Yes (`create_order`, `create_refund` live)	None found in official docs opened	Not labeled	PayPal GitBook
Adyen	Yes	Local only	API key	Yes (example prompt: execute a refund)	None found	Alpha	docs.adyen.com
Square (Block)	Yes	Both	OAuth (remote) / access token (local)	Not explicitly named as a default tool in the page opened	Client allowlist (which apps may connect — not a spend control)	Beta	developer.squareup.com/docs/mcp
Coinbase (CDP)	Not a documented hosted MCP; CLI/SDK (Agentic Wallet, AgentKit, x402)	CLI/SDK	CDP API keys	Yes (USDC wallet)	Per-session/per-transaction caps; OFAC sanctions screening	Not labeled	docs.cdp.coinbase.com
Circle	MCP is docs/codegen only; money controls live in separate Agent Wallets	MCP: remote; Agent Wallets: CLI/SDK	Not fully specified	Agent Wallets: yes, within policy	Time-bound spending limits; wallet/contract allow-blocklists; sanctions screening	Not labeled	developers.circle.com/agent-stack
Skyfire	Token protocol in front of sellers' own MCP/API, not one hosted MCP	Protocol	Signed JWT (`kya`/`pay`/`kya-pay`)	Yes, via pay/kya-pay tokens	User-funded wallet; no explicit per-transaction cap language found	Not labeled	docs.skyfire.xyz
Payman	Partially — official GitHub org has a narrower Genie MCP bridge; primary docs site inaccessible	Genie: remote server + local stdio bridge	OAuth 2.0 + PKCE	Not verified (README describes `ask_genie` and account-management tools, not itemized payment tools)	None found in the official `genie-mcp-stdio` README	Not labeled	github.com/PaymanAI/genie-mcp-stdio
Crossmint	Yes	Remote	API key	Yes, real purchases once `ENV=prod`	None found in README/docs	Not labeled	docs.crossmint.com/agents/overview
Airwallex	Yes	Remote (+ CLI)	OAuth	No, not by default	Explicit default-deny on money-out, write-tool confirmation prompts, OAuth scoping	Not labeled	airwallex.com/docs .../agentos
Visa	Documentation MCP server only (VIC/VDP integration guides + tool definitions, github.com/visa/mcp); Trusted Agent Protocol is a separate merchant-side signature/trust standard	Remote (docs MCP)	JWE token (docs MCP)	Not confirmed for the MCP; TAP itself does not move money	Not applicable (identity/trust, not spend limits)	TAP announced Oct 14, 2025	github.com/visa/mcp, Visa newsroom
Mastercard	Public MCP is a docs-search assistant; Agent Pay (the money-moving program) is separate and not itself an MCP server	N/A	Not applicable to the MCP	Agent Pay requires explicit consumer authorization; no default automatic movement	Registration/verification of agents, tokenization, consumer purchase controls, dispute resolution; no numeric limit published	Announced Apr 29, 2025	Mastercard Newsroom
Checkout.com	Yes	Remote/hosted	Dashboard account credentials	Yes for payment-adjacent actions (voids, payment links)	Permissions tied to the Dashboard user's existing role	"Production-ready"	checkout.com/docs
Mollie	Yes	Remote (proxy for public API)	OAuth 2.0 via browser redirect	Likely, given Payments/Settlements/Mandates tool coverage; no tool explicitly labeled as default-on	None found on the official docs page	Not labeled	docs.mollie.com
Razorpay	Yes	Both (hosted recommended; self-hosted via Docker)	API key (OAuth also mentioned)	Yes by default	`READ_ONLY` flag; 3 write tools disabled on the hosted/remote server specifically	Not labeled	razorpay.com/docs
Plaid	Yes, but not a payment-execution tool	Both (Dashboard MCP remote; coding-toolkit MCP local)	OAuth 2.0, `client_credentials` grant	No — Plaid doesn't move money	Not applicable (diagnostics/dev-tooling only)	Active development, limited support	plaid.com/docs/resources/mcp

What we found

Money-out-by-default is the norm, not the exception. Adyen, PayPal, Razorpay, and Crossmint all ship refund/order/payment-link write tools that execute immediately once an API key or access token is configured, with no purpose-built spend cap, allowlist, or approval step documented in the pages we opened. Stripe and Airwallex are the two exceptions, and both use a confirmation-based mechanism rather than a numeric limit.
"Allowlist" means different things to different vendors. Square's allowlist governs which MCP client applications may connect to its remote server — it does not limit what a connected agent can spend. Circle's and Coinbase's allow/blocklists instead govern wallet or contract addresses an agent can pay. We found no vendor combining a client allowlist with a spend-target allowlist in the same product.
Per-agent budgets are concentrated in the crypto-native and "banking for agents" corner of the market, not among traditional card/payments processors. Circle (time-bound spending limits), Coinbase (per-session/per-transaction caps), and Skyfire (per-agent funded wallet) all describe agent-specific budget constructs. Among the traditional processors we verified (Adyen, PayPal, Square, Checkout.com, Razorpay, Mollie), none described a per-agent spend cap; control is inherited from the merchant's existing API-key or Dashboard-role permission system, which was built for human developers rather than for bounding an autonomous agent.
Airwallex is the only vendor in this set with money-out disabled by default at the MCP layer, paired with an explicit written warning about the operational risk of adding a write-capable agent to a shared/multi-user channel. That default-deny-plus-warning combination was not found stated as explicitly by any other vendor checked.
Several "MCP servers" in this space are not payment-execution tools at all. Mastercard's public MCP and half of Circle's MCP offering are documentation/codegen assistants; Plaid's two MCPs are diagnostics and developer tooling; Visa's public MCP is a documentation server for its Intelligent Commerce and Developer Platform APIs, and its Trusted Agent Protocol is a merchant-side trust/signature standard, not an MCP or a money-mover. Anyone counting "payment MCP servers" should filter these out, or the count of servers that can actually move money will be overstated.
A dated compliance change is coming to the most widely used server in this set. Stripe's own documentation states: "Beginning October 31, 2026, Stripe MCP no longer accepts full-access secret keys or restricted API keys without the Agent tag" (docs.stripe.com/mcp, read 2026-09-28). Any integration still using a plain restricted key will need an Agent-tagged key before that date.
We could not verify Payman's spending-control features on a first-party documentation page. Its documentation site, docs.paymanai.com, returned an HTTP 526 error on every attempt across two research sessions, so its row is marked "not verified" rather than "absent". The official GitHub org (github.com/PaymanAI) does host a narrower product — a "Genie" MCP bridge — whose README describes a single natural-language tool (ask_genie) plus account-management tools, with no spending-limit language present. Descriptions of per-transaction caps and recipient allowlists appear in third-party MCP directories; we will update this row once Payman's documentation is reachable or Payman sends a correction.

How to choose a payment MCP server: a safeguards checklist

None of this is an endorsement of one vendor over another — it's a checklist for reading any vendor's own docs before wiring an agent to a payment MCP server.

Use scoped keys, not full-access ones. Several vendors (Stripe, Coinbase, Circle) explicitly support restricted or agent-tagged credentials distinct from a full-access account key. Use the narrowest scope that the tool needs.
Turn on human confirmation for write actions if the vendor offers it. Stripe's confirmation-URL gate and Airwallex's "require manual approval for tool calls" are both documented, vendor-native ways to add a checkpoint before money moves.
Check whether money-out is on or off by default. Airwallex is the one vendor in this set that ships with money-out disabled until explicitly enabled; every other vendor we could verify ships write tools live once credentials are configured.
Don't rely on a "client allowlist" as a spending control. As found above, a client allowlist (Square) restricts which apps can connect — it says nothing about how much a connected agent can spend. Look specifically for a transaction cap, time-bound limit, or wallet/contract allowlist (Circle, Coinbase) if that's the control you need.
Avoid adding a write-capable payment agent to a shared or multi-user channel. Airwallex's own documentation warns that "anyone who can prompt the agent may perform Airwallex actions with your privileges" — a risk that applies to any MCP server with live write tools, not just Airwallex's.
Don't mix an untrusted MCP server into the same session as a payment MCP server. Prompt injection from an unrelated tool's output (a webpage, a document, another MCP server's response) can attempt to trigger a payment tool call; keeping payment tools isolated to a single, trusted MCP session reduces that surface.
Set a budget limit outside the MCP layer if the vendor doesn't offer one inside it. For the majority of vendors here, no purpose-built per-agent budget exists in the MCP tool itself — treat the underlying account's own spend limits, alerts, or approval workflows as the actual backstop.

Methodology

We checked 16 companies against one criterion: does the company publish, on its own domain or official GitHub org, an MCP server or agent toolkit that can touch payments? For each, we opened the vendor's own documentation, developer site, or official GitHub repository directly and recorded the exact tool names, authentication method, and any spending-control language found — with verbatim quotes kept in the accompanying dataset. We did not rely on search-engine summaries or third-party MCP directory listings for any claim that appears in the comparison table above; where a claim comes only from a WebSearch summary or a third-party source, the table says so explicitly (Payman's caps/whitelist claim; Mastercard's separate public-MCP characterization) rather than presenting it as confirmed.

All pages were accessed 2026-09-27, with five previously unverified rows (Payman, Visa, Mastercard, Mollie, Plaid) independently re-fetched and confirmed on official pages on 2026-09-28. Full verbatim quotes, URLs, and per-row notes are in the accompanying dataset (payment-mcp-landscape-v2.csv).

This is a snapshot, not a permanent ranking — MCP servers and agent-payment products in this space are changing quickly (Stripe's own key-format change on Oct 31, 2026 is one example already scheduled). If you work at one of these companies and a row is wrong or out of date, or you know a first-party page that resolves one of the open items (Payman's primary docs site, Circle's MCP tool-level names), corrections are welcome — cite the specific official page and we will re-verify and update.

FAQ

How many payment companies have an official MCP server that can move money?
Of the 16 companies checked, 12 have a verifiable, first-party MCP server or agent SDK that can move money, which we could open and read directly on the vendor's own domain or GitHub org (Stripe, PayPal, Adyen, Square, Coinbase, Circle's Agent Wallets, Skyfire, Crossmint, Airwallex, Checkout.com, Mollie, and Razorpay). Two more (Visa's Trusted Agent Protocol, Mastercard's Agent Pay) are adjacent agent-commerce programs rather than MCP servers themselves. Plaid's official MCPs and Circle's docs/codegen MCP do not move money. Payman's specific spending-control claims remain unverified on a Payman-owned page.

Which payment MCP servers have spending controls built for AI agents specifically?
Circle's Agent Wallets (time-bound spending limits, wallet/contract allow-blocklists, sanctions screening) and Coinbase's Agentic Wallet (per-session/per-transaction caps, OFAC screening) are the clearest examples of purpose-built, per-agent budget features found in official documentation. Stripe (human-confirmation gate) and Airwallex (money-out disabled by default) take a different approach: a checkpoint or default-deny design rather than a numeric limit.

Does Stripe's MCP server let an agent spend money without approval?
By default, stripe_api_write covers refunds and outbound payments, but Stripe's own documentation states that sensitive write actions require human confirmation via a URL, and that an unapproved action "expires" after 24 hours. Separately, from October 31, 2026, Stripe MCP will stop accepting full-access or non-Agent-tagged restricted API keys (docs.stripe.com/mcp, read 2026-09-28).

Is Visa's Trusted Agent Protocol or Mastercard's Agent Pay an MCP server?
No. Visa's Trusted Agent Protocol (announced October 14, 2025) is a cryptographic message-signing standard that lets merchants verify an AI agent's identity at checkout; it does not itself execute payments (Visa separately publishes a documentation MCP server at github.com/visa/mcp). Mastercard's Agent Pay (announced April 29, 2025) is a tokenization-based payments program requiring explicit consumer authorization; Mastercard's separately published public MCP is a documentation-search assistant, not the thing that moves money.

Why doesn't this article confirm Payman's spending-control claims?
Payman's primary documentation site, docs.paymanai.com, returned an HTTP 526 server error on every attempt across two research sessions (2026-09-27 and 2026-09-28), so we could not read the page ourselves. The specific "per-transaction/daily caps and recipient whitelist" claim circulating about Payman appears in third-party MCP directories and in Payman's own marketing copy, not on a Payman-owned documentation page we could open. Payman's official GitHub org does host a different, narrower product (a "Genie" MCP bridge) whose README contains no spending-control language.

Corrections

2026-09-28: The Visa row originally said "Not an MCP." Visa does publish an official documentation MCP server (github.com/visa/mcp: "AI tools, examples, and integrations for the Visa Developer Platform"), so the row, summary and FAQ now say so. Whether any Visa MCP tool moves money is not confirmed.