What is a payment MCP server?
The Model Context Protocol is a standard way for an AI application to discover and call tools on a remote server. A payment MCP server is that pattern applied to a payments API: instead of your engineers writing a client for eighty REST endpoints, the provider publishes a server that advertises its capabilities, and the model calls them. In practice a developer types something like create a payment link for 40 dollars for the annual plan, and the tool call goes out. That is genuinely useful, and it is why stripe mcp server and shopify mcp server are now among the most searched developer terms in payments. It is also why the security model deserves more attention than it usually gets, because the thing sitting between your API key and your bank balance is a language model interpreting a sentence.
How we probed them, and why the control path matters
We ran every host in this page through the same pass in September 2026 rather than repeating vendor marketing. For each candidate we requested the conventional hosted address, requested /.well-known/oauth-protected-resource (the discovery document the MCP authorization spec requires a protected server to publish), and sent a real JSON-RPC initialize frame where a GET was refused. We also sent every host a randomly generated nonsense path. That control is not optional. Plenty of marketing sites answer HTTP 200 with HTML for any URL you invent, and without a control request you will publish a catch-all web server as protocol support. We have made that mistake before and corrected it in public. On this run the control returned 404 or 400 on every host that answered, so nothing in the table below is a false positive.
Stripe MCP server has one generic write tool over most of the API
Stripe hosts a remote server at https://mcp.stripe.com. Our unauthenticated GET returned 401 with a JSON body pointing at the docs, and the OAuth discovery document resolved to an authorization server at access.stripe.com/mcp. Clients authenticate with OAuth, or with a restricted API key as a bearer token where the client cannot do OAuth. The design choice worth understanding is the tool surface. Rather than publish one tool per endpoint, Stripe publishes stripe_api_read and stripe_api_write, where write is documented as covering any Stripe API POST, PATCH, PUT and DELETE method. That keeps the context window small, which is a real engineering win, and it means the blast radius of the connection is the intersection of your key permissions and the model's judgment. The supported method list includes creating refunds, Checkout Sessions, payment links, subscriptions, invoices and webhook endpoints. Stripe is candid about this in its own documentation, advising you to enable human confirmation of tools and to exercise caution when using the Stripe MCP alongside other servers because of prompt injection.
Shopify MCP server has no central host and no authentication on the stores we tested
This is the finding that surprised us. mcp.shopify.com returned 404 for everything, including the OAuth discovery document, so there is no central Shopify MCP host to point a client at. The storefront MCP is instead published per merchant at https://<store-domain>/api/mcp, and it is not gated. We sent an unauthenticated tools/list to four live US storefronts. Brooklinen answered with five tools, including search_catalog, get_product_details, get_cart and update_cart. Allbirds answered with exactly one, search_shop_policies_and_faqs. Gymshark and Red Bull returned 404. Same platform, four very different postures, and the merchants exposing a cart-write tool to anyone on the internet may not all have made that choice deliberately. If you run a Shopify store, sending that one request to your own domain is a five second check worth doing today.
PayPal MCP server has the most explicitly money-moving tool list
PayPal hosts https://mcp.paypal.com for production and a sandbox host alongside it. Our GET returned a 302 to the developer site, but the OAuth discovery document resolved cleanly with scopes_supported of openid, email and profile, so the endpoint is live and protected. Where Stripe collapses everything behind one generic write tool, PayPal names each capability, and reading the catalog is instructive: create_order, pay_order which captures payment on an authorized order, create_refund, create_invoice, send_invoice, create_subscription, cancel_subscription, accept_dispute_claim, and on the remote commerce side create_cart and checkout_cart. An agent holding that connection can capture a payment, refund one, bill a customer on a recurring schedule and concede a dispute. Those are all legitimate operations. None of them is bounded by an amount. For the merchant-facing side of PayPal's agent strategy, see our write-up of PayPal agentic commerce.
Square MCP server publishes 49 scopes, and the list is the warning
Square hosts https://mcp.squareup.com, and it is the only provider in the set whose OAuth discovery document publishes its full permission vocabulary without authentication. There are 49 scopes. Twenty-two of them end in _WRITE. The ones that should stop a finance team include PAYMENTS_WRITE, PAYMENTS_WRITE_ADDITIONAL_RECIPIENTS, PAYMENTS_WRITE_SHARED_ONFILE, BANK_ACCOUNTS_WRITE, INVOICES_WRITE, SUBSCRIPTIONS_WRITE, DISPUTES_WRITE, GIFTCARDS_WRITE and MERCHANT_PROFILE_WRITE. Square deserves credit here rather than criticism: granular scopes are the right primitive, and publishing them openly is better practice than hiding them. The point is what a scope can and cannot express. PAYMENTS_WRITE is a yes or no. It cannot say yes up to 500 dollars a day, and no to a counterparty this agent has never paid before.
Checkout.com hosts its server, Adyen leaves it to you
Checkout.com turned out to be the most protocol-correct host in the set. https://mcp.checkout.com refuses GET with a 405, which is exactly what a Streamable HTTP transport should do, and a proper JSON-RPC initialize frame came back with {"code":-32001,"message":"Missing Bearer token"}. Its authorization server is access.mcp.checkout.com/payment-operations and its published scopes include one named mcp_full_access, which tells you the granularity on offer. Adyen went a different way entirely: mcp.adyen.com does not resolve, because Adyen ships a local TypeScript server you run yourself with npx -y @adyen/mcp. It covers Checkout sessions, payment links and modifications including cancels and refunds, plus Management API surface, and it authenticates with an API key from a webservice user whose roles you assign. Adyen explicitly recommends creating a dedicated webservice user and limiting its roles to the tools you actually need, which is the best security guidance any of these vendors gives. Roles are still a capability list, not a budget. Adyen's wider merchant push is covered on our agentic checkout page. Plaid took a third route: its hosted server reads diagnostics only, and money moves through the Transfer API, whose limits we measured on our Plaid MCP server and Transfer API limits page.
Which payment MCP server should you use?
Match it to the job rather than to the brand. If your agent is doing back office work on your own account, reconciling, drafting refunds, answering support questions about a charge, Stripe's server is the most capable and its restricted API key path gives you the cleanest way to hand over a narrow credential. If you are billing customers, PayPal's named tools are easier to reason about than a generic write tool precisely because each capability is visible in the tool list rather than implied. If you run on Square, use the scope list as a checklist and grant the smallest set that works. If you are on Adyen, the local server plus a role-limited webservice user is the tightest configuration available anywhere in this comparison. And if you sell on Shopify, treat the storefront MCP as a public surface, because on the stores we tested it is one. None of these choices answers the question in the next section.
None of them enforces a spending limit
We looked for one on every server here. There is no budget, no per-transaction ceiling, no cumulative cap over a window, no counterparty allowlist, no velocity rule and no approval threshold in any of them. That is the correct decision at their layer, for the same reason it was correct for ACP, AP2 and x402: a payments API that tried to encode your finance policy would be worse at both jobs. It is still a hole at the program level, and MCP widens it in a specific way. A REST integration fails closed when the code has no path to an endpoint. An MCP integration fails open, because the model has a generic write tool and a plausible sentence is all that stands between an instruction and an API call. That is why prompt injection is not a theoretical concern here: the same paragraph that convinces a model to issue a refund is content it might read from a support ticket, a webpage or another MCP server in the same session. Integration platforms repackage these servers without adding a cap: Workato's prebuilt Stripe Billing Operations server exposes refund_payment with no documented maximum, which we cover on our Workato MCP and Workato Genies page. The same is true one layer up: an aggregator such as Zapier MCP exposes Stripe, PayPal and Square payment actions with no amount ceiling either, and bills two tasks per call whatever the amount.
How to give an agent a payment tool without giving it your balance
The design that holds up separates capability from authority. A credential says what an agent can call. A policy says whether this particular call, right now, for this amount, to this counterparty, is allowed. Keep those in different systems and you can hand an agent a genuinely useful payment tool without betting the account on the model's judgment. Concretely: give each agent its own funded wallet rather than a shared corporate credential, so a compromise is contained to one balance. Check every intended payment against policy before a credential exists, covering the per-transaction ceiling, the running total over a window, the merchant allowlist and the velocity rule that catches a retry loop. Pause anything above your threshold for human approval. Issue a merchant-locked virtual card scoped to the single purchase instead of a reusable key. And write every decision to an immutable audit trail naming the agent, its human owner, the intent and the policy that allowed it, because when a refund goes out at 3am the only useful question is which agent, on whose authority.
How AgentsPay fits alongside a payment MCP server
AgentsPay is not a replacement for any server on this page. It is the layer none of them occupies. You keep Stripe, PayPal, Square, Checkout.com or Adyen as the rail, connect the MCP server your team wants, and put the policy decision in front of the money rather than behind it. Because the control plane is rail-neutral, switching providers or adding a second one is a configuration change instead of a rebuild, which matters more than it sounds when the standards question is this unresolved. Our page on MCP payments covers the protocol mechanics in more depth, and AI agent payment platforms compares the vendors in this category head to head. We ran the same probe across the accounting systems, and the QuickBooks, NetSuite and Xero MCP servers reach the same conclusion from the other end of the ledger.