What Are Payments Over MCP?
Payments over MCP means an AI agent creates invoices, charges a card, issues a refund, or performs another payment action by calling a tool exposed through the Model Context Protocol (MCP), an open standard for connecting AI applications to external systems, rather than through a custom API integration built for that one agent.
Key facts
- MCP itself is not a payments protocol. Per its own documentation, MCP "is an open-source standard for connecting AI applications to external systems," described as "a standardized way to connect AI applications to external systems" — analogous to "a USB-C port for AI applications" — covering data sources, tools, and workflows generally, per modelcontextprotocol.io. Payment capability is added by whichever server a company builds and exposes over MCP.
- PayPal publishes an official MCP server. The paypal/paypal-mcp-server GitHub repository, under PayPal's own GitHub organization, exposes tools for invoicing (create, list, retrieve, send, cancel, generate QR codes), payments and orders, refunds, disputes, shipment tracking, product catalog management, subscriptions, and transaction analytics, and is licensed Apache-2.0. PayPal's own developer blog describes the rollout as beginning April 2, 2025, with an initial feature letting merchants generate an invoice from a natural-language prompt, per developer.paypal.com.
- Stripe publishes an official MCP server as part of its "stripe/ai" toolkit. The stripe/agent-toolkit repository, under Stripe's own GitHub organization, is described as Stripe's "one-stop shop for building AI-powered products and businesses" on top of Stripe, and includes a remote MCP server hosted at
mcp.stripe.comusing OAuth-based client access, alongside SDKs for integrating Stripe billing into agent frameworks. It is licensed MIT. - MCP's own security documentation identifies risks specifically relevant to money-moving tools. The MCP security best practices page documents the "confused deputy problem" (an MCP proxy server can be tricked into granting an attacker access to a third-party API without the user's consent), "token passthrough" (a server forwarding a token it never validated was actually issued to it, explicitly forbidden: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server"), server-side request forgery during OAuth discovery, and "scope minimization" failures where a token is granted broad, omnibus scopes (e.g.
admin:*) instead of the minimum needed for one operation. - Local MCP servers carry a distinct, non-network risk. The same documentation warns that a locally run MCP server is "a binary that is downloaded and executed on the same machine as the MCP client," and that without sandboxing, a malicious startup command or compromised package can exfiltrate files or escalate privileges with the same permissions as the client — a risk that applies as much to a payment-capable server as any other.
- Prompt injection is a named risk across the ecosystem, not specific to any one server. MCP's security documentation frames the underlying problem as the model being unable to reliably separate instructions from data it processes, which is why a document, webpage, or tool result an agent reads can attempt to redirect the agent's next action — including invoking a payment tool — without the human operator's intent.
How it works
- A company (e.g., PayPal or Stripe) builds and hosts an MCP server that wraps its existing payment APIs as MCP "tools" — discrete callable actions like
create_invoiceorcreate_refund. - A developer connects an MCP-compatible AI client (such as Claude, ChatGPT, or an IDE assistant) to that server, either running it locally or authenticating to a remote, OAuth-protected instance.
- When a user asks the agent to do something involving payment (e.g., "invoice this client for $450"), the agent's model decides to call the relevant MCP tool, and the MCP client sends that tool call to the server.
- The server executes the actual payment-provider API call using its own credentials/tokens, and returns the result (success, an invoice link, an error) back to the agent.
- Because MCP is stateless at the protocol level, servers that need to track things across calls (like a shopping cart or a pending invoice) mint their own handle, which is passed back and forth as an ordinary argument, per the MCP security documentation — a detail relevant to preventing a payment tool call from being hijacked mid-flow.
- Any spending limits, approval thresholds, or merchant restrictions are enforced by the payment provider's own systems behind the MCP tool, not by the MCP protocol itself, since MCP defines how the call is made, not what business rules govern it.
Comparison of MCP payment integrations
| PayPal MCP server | Stripe MCP server (via agent-toolkit) | MCP protocol itself | |
|---|---|---|---|
| Official status | Official, published under github.com/paypal |
Official, published under github.com/stripe |
N/A — protocol spec, not a payment product |
| First public rollout | April 2, 2025, per developer.paypal.com | Not specified in primary sources reviewed | N/A |
| Deployment options | Local server or remote server with cloud-based auth | Remote server at mcp.stripe.com with OAuth |
N/A |
| Tools exposed | Invoicing, payments/orders, refunds, disputes, shipments, catalog, subscriptions, analytics | Billing/agent-commerce tools via agent-toolkit; documentation search |
N/A — tool sets are defined per server, not by MCP |
| License | Apache-2.0 | MIT | N/A |
FAQ
Is MCP itself a payment protocol like AP2 or x402? No. MCP is a general-purpose standard for connecting AI applications to external tools and data; payment capability comes from a specific server (like PayPal's or Stripe's) built on top of MCP, not from the MCP specification itself.
Which companies publish an official payment MCP server? PayPal and Stripe both publish official MCP servers under their own GitHub organizations — paypal/paypal-mcp-server and Stripe's stripe/agent-toolkit — verified directly on those repositories.
What's the biggest risk specific to payment-capable MCP servers? MCP's own security documentation highlights token passthrough (a server forwarding tokens never validated as issued to it) and the confused deputy problem as risks with direct financial consequences, since both can let an attacker act with another user's authorization on a payment-capable API.
Can a prompt injection attack cause an MCP agent to make an unwanted payment? The risk is structural: MCP's security documentation and general LLM security guidance describe models as unable to reliably distinguish instructions from data, meaning malicious content the agent reads (a webpage, a document, a tool result) could attempt to trigger a tool call the user never asked for. Whether that succeeds depends on what safeguards the specific MCP client and server implement.
What safeguards do the primary sources describe? MCP's security documentation prescribes scope minimization (granting only the narrow permissions a token needs), strict validation that a token was actually issued to the server accepting it, sandboxing for locally run servers, and consent screens that clearly show what a client is being authorized to do before granting access.
Do PayPal's and Stripe's MCP servers enforce their own spending limits? Not specified in the primary sources reviewed for this article. Both repositories describe the tools available (invoicing, refunds, subscriptions, etc.) but do not document a built-in, MCP-level spending cap; any such control would come from the underlying account or business rules of PayPal or Stripe itself.
