Payment MCP servers compared (2026)

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 adjacent agent-commerce programs that are not themselves 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 Not an MCP — Trusted Agent Protocol is a merchant-side signature/trust standard N/A Cryptographic request signing Not applicable Not applicable (identity/trust, not spend limits) Announced Oct 14, 2025 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

  1. 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.

  2. "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.

  3. 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.

  4. 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.

  5. 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 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.

  6. 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.

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