MCP servers that can create a payment
5 verified servers expose a tool that can create a payment or charge
Money is the highest-stakes write an agent can make, and the payment MCP servers expose it plainly: create a payment link, raise an invoice, open a charge. The action is short. The care around it is not.
These verified servers let an agent create a payment or charge, across the major processors.
Stripe
Stripe
Stripe's official MCP server lets agents create customers, payment links, invoices, and read balances.
create_payment_linkcreate_invoicecreate_invoice_item
create_payment_link mints a shareable link, create_invoice bills a customer directly, and create_invoice_item adds the line items, the widest create surface of any processor here.
Razorpay
Razorpay
Razorpay's official MCP server lets agents create orders and payment links, capture and refund payments, and read settlements and payouts.
create_payment_linkcreate_payment_link_upi
Razorpay covers the same shareable-link flow and adds a UPI-specific variant, which matters for collecting payment in the Indian market.
Adyen
Adyen
Adyen's official MCP server lets agents create payment sessions and links, refund and cancel payments, and manage merchant accounts, terminals, and webhooks.
create_payment_sessioncreate_payment_links
Adyen's create_payment_session opens a hosted checkout, the enterprise path with more flows and methods to configure than a single link.
PayPal
PayPal
PayPal's official remote MCP server brings invoicing, orders, and payments into agentic commerce.
create_invoice
PayPal's create_invoice raises an invoice the customer pays, the simplest collect path here; its server also exposes create_order and pay_order when you need a full checkout.
Paddle
Paddle
Paddle's official MCP server lets agents manage the product catalog, billing, subscriptions, and reports through the Paddle Billing API.
create_subscription_charge
Paddle is built for SaaS billing, so create_subscription_charge raises a charge against a subscription that already exists.
What to know
Treat this capability differently from every other one on the directory. A retried charge that is not idempotent bills a customer twice. A hallucinated amount bills them wrong. So the guardrails are not optional: an idempotency key on every create, a hard confirmation before anything moves money, and amounts the agent reads from a record rather than composes from text. Most of these servers favor payment links and invoices over raw charges, which is the safer shape, since a human still clicks to pay.
The memory angle here is literal reconciliation. An agent that issues an invoice, then forgets, cannot answer whether it already billed this customer. Knowing what was charged, to whom, and when is exactly the context you do not want reconstructed from guesswork.
Questions
- Is it safe to let an agent create payments?
- Only with hard guardrails. Use an idempotency key so a retry can't double-charge, require a confirmation step before anything bills, and have the agent read amounts from a record rather than generate them. Most of these servers lean on payment links and invoices, where a human still clicks to pay, which keeps the agent one step back from moving money on its own.
- What is the difference between a payment link and a charge?
- A payment link or invoice asks the customer to pay, so a person confirms before money moves. A direct charge bills a stored payment method immediately. Links and invoices are the safer default for an agent; reserve direct charges for flows where you have already done the validation a human normally would.