Payment MCP Servers Compared: PayPal, Stripe, Coinbase

If you are looking for an MCP server that lets an AI agent touch payments, three vendors ship something official and usable today: Stripe, PayPal, and Square. Each exposes a different amount of your account, authenticates differently, and treats sandbox testing differently. Coinbase also ships an official MCP server, but it points the opposite way: it is built for an agent that spends, not for a merchant that collects. Confusing those two is the most common mistake we see in this space.

The gap that nobody advertises: no major crypto payment gateway ships an official MCP server. We checked every provider in our crypto payment gateway comparison — BitPay, CoinGate, NOWPayments, Coinbase Commerce — on September 7, 2026, and found no first-party MCP server for any of them. Coinbase Commerce has only a community-built server that creates payment links.

Aurpay does not have an MCP server either. We are a crypto payment gateway, we do not publish one, and there is nothing on our roadmap we are willing to promise you here. If you want an agent to create and reconcile crypto payments through Aurpay, you wrap our REST API in your own MCP server. That is a real and fairly small job, and the last section of this article is the specification for it: which tools to expose, where to put the spending ceiling, and what to use as an idempotency key. Being told this up front is more useful than being sold a roadmap.

What each official payment MCP server actually exposes

Every row below was read off the vendor’s own documentation, not an aggregator listing. Aggregators lag badly in this category — several still describe PayPal’s server as local-only, when PayPal now runs hosted endpoints for both production and sandbox.

Server	Actions exposed to the agent	Auth	Sandbox	Official or community	Source (checked 2026-09-07)
Stripe MCP mcp.stripe.com (remote) or @stripe/mcp (local)	Two generic tools, stripe_api_read and stripe_api_write, that reach roughly 140 allowlisted API methods: customers, charges, refunds, PaymentIntents, Checkout Sessions, invoices and invoice items, subscriptions and schedules, coupons, products and prices, payment links, disputes, webhook endpoints, payouts, balance and balance transactions, tax, Issuing. Plus documentation search, an implementation planner, account info, and preview analytics and Treasury tools	OAuth (recommended), or a restricted API key as a bearer token. Sessions are listed and revocable per user in the Dashboard	Yes — MCP access is configured separately for live mode and sandbox	Official	docs.stripe.com/mcp
PayPal MCP mcp.paypal.com and mcp.sandbox.paypal.com (remote), or the local server	Named per-action tools, not a generic passthrough: invoices (create_invoice, list_invoices, get_invoice, send_invoice, send_invoice_reminder, cancel_sent_invoice, generate_invoice_qr_code); payments (create_order, get_order, pay_order, create_refund, get_refund); disputes (list_disputes, get_dispute, accept_dispute_claim); shipment tracking; catalog products; eight subscription tools; and list_transactions	OAuth2 access token from client ID and secret. Sandbox tokens last 3–8 hours, production tokens 8 hours	Yes — a dedicated sandbox endpoint	Official	developer.paypal.com, paypal/paypal-mcp-server
Square MCP (beta) mcp.squareup.com/sse (remote) or local	Only three tools: get_service_info, get_type_info, and make_api_request, which together reach the full Square API surface. The agent discovers the API at runtime rather than choosing from a fixed tool list	OAuth with granular scopes on the remote server; token-based locally. Square keeps an allowlist of approved MCP clients	Yes — a local instance with the sandbox flag set	Official, beta	developer.squareup.com/docs/mcp
Coinbase Agentic Wallet / Payments MCP npx @coinbase/payments-mcp	Wallet balance and address, an onramp flow for USDC, service discovery and automatic payment over x402. This is spending, not collecting. There is no merchant checkout or settlement surface	No API key. Email and one-time code create an embedded wallet; the user sets max-per-call and max-per-session spending limits	Not documented	Official	docs.cdp.coinbase.com
Shopify Storefront MCP	Buyer-side commerce: browse a store’s catalog, read policies, create carts, add and remove items, complete checkout. Nothing on the merchant’s settlement or refund side	Storefront-level access	Not applicable	Official	shopify.dev
Coinbase Commerce MCP	Create a payment charge, retrieve an existing charge, return a shareable payment link. That is the whole surface	Coinbase Commerce API key	Not documented	Community (zhangzhongnan928)	GitHub
BitPay, CoinGate, NOWPayments, Aurpay	No first-party MCP server found	—	—	None published	Vendor developer docs, checked 2026-09-07

Two things in that table are easy to skim past and expensive to get wrong.

First, Stripe and Square do not hand the agent a curated list of payment verbs. They hand it a generic API caller. Stripe’s stripe_api_write will issue POST, PATCH, PUT and DELETE against any allowlisted method, and Square’s make_api_request is exactly what its name says. The tool list you see when the client connects tells you almost nothing about what the agent can do to your account. Your actual permission boundary is the OAuth scope or the restricted key, not the tool schema.

Second, PayPal is the opposite design. Each action is its own named tool with its own parameters, which makes the blast radius legible: if create_refund is not in the tool list, refunds cannot happen. That is easier to reason about and harder to extend.

Merchant-side, agent-side, buyer-side: pick the right one

Most of the confusion in this category comes from treating “payment MCP” as one category when it is three. The direction money moves determines which server you want.

Direction	What the agent is doing	Servers built for it
Merchant-side (collecting)	Creating invoices and orders, checking whether a payment settled, issuing refunds, pulling transactions for reconciliation	Stripe, PayPal, Square
Agent-side (spending)	Holding a funded wallet and paying for APIs or services autonomously, typically over x402	Coinbase Payments MCP
Buyer-side (shopping)	Searching a merchant’s catalog, building a cart, completing a checkout on behalf of a shopper	Shopify Storefront MCP

If you are a merchant who wants an agent to answer “did order 4471 settle, and if not why,” Coinbase’s Payments MCP does nothing for you no matter how good it is at what it does. If you are building an agent that pays for metered APIs, the x402 route is the right one and Stripe’s server is irrelevant. We cover that machine-to-machine payment path separately in our write-up of the x402 protocol for agent-to-API payments, and the underlying protocol itself in what MCP actually is for payment APIs.

When MCP beats calling the REST API directly — and when it is a liability

MCP is not a better API. It is a way to let a model discover and call an API without you writing the glue. That trade is worth making in some situations and actively harmful in others.

MCP earns its place when the work is investigative and read-heavy. Support triage and reconciliation questions like “show me every refund over $200 last week and which ones share a customer email” cannot be enumerated in advance, which is exactly what a discovery-based interface is for. A read-only scope makes this close to risk-free, and it beats building a reporting endpoint for every question your finance team invents.

It is the wrong tool for anything on the checkout path. Your checkout runs the same three calls on every order, thousands of times a day. Handing that to a model adds latency, cost, and non-determinism to a code path whose entire virtue is that it is deterministic. Write the API integration.

Between those poles, three specific risks decide it.

Permission boundaries are coarser than they look. With a generic API-caller tool, everything the credential can do, the agent can do. If you issue a restricted key with write access to refunds because the agent occasionally needs to refund, that key can refund every charge in the account, in any amount, for as long as it exists. Scope down to the narrowest key that does the job, and issue a separate key per agent so revoking one does not break the others.

Idempotency also stops being optional. A deterministic client retries on a known failure. A model retries because it decided the first result looked wrong, or because the conversation was resumed, or because a tool call timed out on the client side while the server committed. Any write tool you expose needs an idempotency key derived from business identity, such as the order ID or invoice number, not one generated fresh per call, because a freshly generated key makes every retry a new payment.

Prompt injection is the third risk, and the vendors say so themselves. Stripe’s own MCP documentation carries the instruction to “enable human confirmation of tools and exercise caution when using the Stripe MCP with other servers to avoid prompt injection attacks” (checked 2026-09-07). That warning is doing real work. An agent with a refund tool and access to a customer-facing inbox can be instructed by a customer to issue a refund, and every step of that will look like normal authorized behavior. The permission model will not save you, because nothing exceeded its permissions.

Use this as the decision rule: expose it over MCP if the action is read-only, or if it is reversible and bounded and a human confirms it. Everything else goes through code you wrote.

No official MCP server? Here is how to wrap one

Since Aurpay does not publish an MCP server, this is the practical route for crypto payments. The same shape works for any gateway on the bottom row of the table.

Aurpay’s REST API covers payin and payouts, orders, and invoices, and there is a developer environment on testnet alongside production, with separate API keys generated per environment in the dashboard. Authentication is API-key by default, with optional signature authentication using an API token and secret. Payment status arrives at your configured callback URL, which must answer with a 200; callbacks can be verified with a simple token parameter or with signature authentication configured in the dashboard. Those are the pieces you are wrapping. Our walkthrough of building a crypto payment MCP server covers the code; what follows is the design brief that should come before it.

Expose four tools, not fourteen. The temptation with a generic wrapper is to mirror the whole API. Resist it. Every extra tool is permission surface. For a merchant agent, this set covers the real work:

• create_payment_order takes amount, currency, and your own order reference, and returns the hosted payment URL. Write, bounded.
• get_payment_status takes your order reference and returns state plus on-chain confirmation detail. Read.
• list_recent_orders takes a date range and an optional status filter. Read, and this is where most of the agent’s value actually shows up.
• create_invoice covers the send-a-link workflow. Write, bounded.

Keep payouts out entirely. Payout is the one endpoint that moves money out of your control, and it is the one an injected instruction will target. There is no version of an agent-triggered payout that is worth the exposure. Leave it in code with its own approval flow.

Put the ceiling in the server, not the prompt. A maximum amount written into your system prompt is a suggestion. A maximum amount enforced in the tool handler, which rejects anything above it before the API call is built, is a control. Set a per-call cap and a rolling per-session total, and return a clear refusal the model can relay rather than silently clamping the value, because a clamped amount produces an order for the wrong sum, which is worse than an error.

Derive the idempotency key from your order reference. Use your own order ID as the key on every write, so a repeated create_payment_order for the same order returns the existing order instead of creating a second one. Then have the tool handler check for an existing open order with that reference before it calls the API at all. This one decision prevents the most common failure mode of agent-driven payments: duplicate orders created by a retry the model thought was a first attempt.

Confirm writes with a human, and make the confirmation specific. “Approve this action?” trains people to click yes. “Create a 250 USDC order for invoice 4471, payable on Ethereum?” gives them something to actually check. Both PayPal’s remote server and Stripe’s remote server rely on the client to provide this; Coinbase enforces spending limits at the wallet layer instead, which is the stronger pattern and the one worth copying in your handler.

Build against testnet first, then swap the key. Aurpay’s developer environment uses separate API keys from production, so the switch is a credential change rather than a code change. Run the full loop on testnet (create an order, pay it, receive the callback, read the status back) before a production key ever reaches the agent. Getting callback handling right at this stage matters more than it looks, because reconciliation is where crypto payments diverge most from card payments; we go through that in detail in our guide to payment API webhooks and merchant reconciliation.

Choosing, in one paragraph

If you are already on Stripe or PayPal and want an agent for back-office work, use the official server, scope it read-only, and add write tools one at a time as you find a case that justifies each one. If you are on Square, expect a beta and expect to request client allowlisting. If you are building an agent that spends rather than collects, Coinbase’s Payments MCP on x402 is the only official option and it is a reasonable one. If you take crypto payments as a merchant, no gateway ships one today, so you write a four-tool wrapper over the gateway’s REST API. Given the permission and idempotency issues above, that is arguably what you should be doing regardless of what any vendor ships.

One disclosure, since we are a payment gateway writing about payment gateways: we have an obvious interest in that last case. The comparison above is the one we would give you in private, and our answer about our own MCP support is the same in both settings.

Aurpay is a non-custodial crypto payment gateway at 0.8% per transaction, settling directly to your wallet on Ethereum, Tron, Bitcoin mainnet, and Bitcoin Lightning, with no contracts or banking details required. If you are wrapping our API rather than a competitor’s, the payin, payout, order and invoice endpoints and the testnet developer environment are documented at aurpay.net/documentation. Compare API depth before you commit to a gateway, because that is the part you cannot change later.