We checked 49 payment MCP servers. 37 can move money. Only 4 document a spending budget.

Aidakh — Mon, 12 Oct 2026 18:00:17 +0000

Disclosure: I work on Pink Agentic AI Payments at PinkWallet, which is one of the 49 servers in this census. Pink was scored from its public docs by the same criteria as every other row, and it currently runs as a public sandbox with test money only. The full dataset is open so you can check every number: github.com/Pink-Agentic-Payments/payment-mcp-census.

Short answer: most payment MCP servers can move real money, but very few tell you how to stop an agent from spending too much. Of 37 servers that can create a payment, transfer, payout, charge or card, only 4 (11%) document a configurable spending budget, only 6 (16%) document a human-approval step, and only 1 (3%) documents a velocity limit.

If you are about to give an AI agent a payment tool over MCP, that gap is the thing to check first.

What we counted

We catalogued 49 payment-adjacent MCP servers (24 official vendor servers, 25 community ones) between 2026-10-08 and 2026-10-09, and read each one's own docs or README. For every server we recorded whether it can move money and whether it documents six spending controls:

a per-agent or aggregate budget
a per-payment limit
a payee / merchant allowlist or block
a human approval step
a rate / velocity limit
a sandbox / test mode

"Documents" means the control is described in the server's public docs. A server may have a control it does not document; for an agent builder, an undocumented control is hard to rely on.

The numbers

Finding	Count
Servers that can move money	37 of 49 (76%)
…that document a spending budget	4 of 37 (11%)
…that document a per-payment limit	5 of 37 (14%)
…that document a payee allowlist / block	3 of 37 (8%)
…that document human approval	6 of 37 (16%)
…that document a velocity / rate limit	1 of 37 (3%)
…that document a sandbox / test mode	8 of 37 (22%)
Listed servers whose GitHub repo returned 404	5 of 49 (10%)

Community servers move money slightly more often than official ones: 20 of 25 community rows versus 17 of 24 official rows.

Who documents what

These are the money-moving servers that document at least one spending control (from the census table, generated straight from census.csv):

Budget: Marqeta ("spending caps"), Gatewards ("per-agent spend caps"), MCPay ("a hard budget"), Pink (per-agent monthly budget).
Per-payment limit: Coinbase AgentKit / CDP (value-based policy rules), Crossmint Checkout (maxCost), MCPay, x402search-mcp, Pink.
Payee allowlist: Coinbase AgentKit / CDP, Marqeta, Pink.
Human approval: Stripe (confirmation for refunds and outbound payments), Crossmint (awaiting_input), Ramp ("managing approvals"), GoCardless ("with user confirmation"), SpendNod, Pink (pending_human).
Velocity limit: Marqeta only.

No single control is common. The most-documented one, human approval, still appears in fewer than 1 in 6 money-moving servers.

Why this matters if you build agents

Prompts are not a spending limit. An instruction like "never spend more than $50" lives in the model's context, and the model can misread it, forget it, or be talked out of it by a prompt injection in a web page or an email. A control that actually holds has to sit outside the model, in the system that holds the money, and has to be checked before the payment executes.

A companion survey of 12 popular agent frameworks (LangChain/LangGraph, CrewAI, OpenAI Agents SDK, Vercel AI SDK, Google ADK, AutoGen, Semantic Kernel, LlamaIndex, Pydantic AI, Mastra, Claude Agent SDK, smolagents) found that 0 of 12 document a spending budget in currency for tool calls, while 10 of 12 offer some form of human approval and 9 of 12 a max-steps limit (agent-framework-spend-guardrails). The frameworks can pause an agent; they do not know what a tool call costs.

So in practice the spending controls have to come from the payment layer. When you evaluate a payment MCP server, ask five questions:

Can I set a budget per agent, not just per account?
Is there a per-payment cap, enforced server-side?
Can I restrict who the agent may pay?
Can a payment above a threshold go to a human and wait, with a default of "no" if nobody answers?
Is there a sandbox so I can test the rules with fake money first?

How Pink approaches it (one data point, not the only answer)

Pink's MCP server gives the agent a pink.request_payment tool instead of a card. Every request is checked on the server against circuit breakers (agent registered and active, monthly budget, company daily ceiling) and then against the company's rules, top to bottom. The answer is one of three: allowed (the agent gets a single-use credential locked to one payee and one amount, expiring in about 15 minutes), pending_human (a person approves or rejects; silence means no), or blocked. Unmatched requests default to blocked. The public sandbox at agentic-sandbox.pinkwallet.com uses test credentials only; production is not yet available.

If you want to try to break it, there is an open challenge: can you make an AI agent overspend?

Get the data

Dataset, method and every source URL: payment-mcp-census (CC BY 4.0)
Framework survey: agent-framework-spend-guardrails
A longer comparison with notes per server: Payment MCP servers compared

If your server is in the census and we got a row wrong, open an issue on the repo with a link to your docs and we will correct it.

Paying for the OpenAI and Anthropic APIs with USDT: card vs. gateway, and the tax trap that declines most cards

Aidakh — Wed, 07 Oct 2026 23:56:12 +0000

Disclosure: I'm on the Pink Card team. The tax-buffer advice below applies to any prepaid card, not just ours.

OpenAI and Anthropic bill API usage by card only. If your local card gets declined by overseas merchants, or your money sits in USDT/USDC, you have two realistic options.

Option 1: an API gateway / reseller

Gateways accept crypto and hand you their own API key that proxies to OpenAI or Anthropic.

Fast to start
Your prompts and traffic pass through a third party
Usually a markup, and no organization of your own: no usage dashboard, no official invoices

Option 2: a prepaid card on your own organization

Fund a prepaid virtual card with stablecoins and add it under Billing in your own account.

Your keys, your rate limits, your dashboards and invoices
Requests go straight to the provider
You have to handle the tax buffer (next section)

The tax trap

Providers add VAT / sales tax for your billing region, so the real charge is typically 5-25% above the sticker price. A $20 plan is often billed at $24. A card loaded with exactly $20 gets declined by a few dollars, and the decline is usually blamed on "crypto cards" when it's just the tax.

Rule of thumb: load about 20% more than the credits you plan to buy.

Step by step (with Pink Card)

Buy a card at pinkcard.cc with USDT or USDC. No account needed. Presets $110 / $220 / $500 / $1000, or a custom amount from $100.
The card number, expiry and CVV arrive by email in about 5-10 minutes.
OpenAI: platform.openai.com > Settings > Billing > add the card. Anthropic: console.anthropic.com > Billing > add the card.
Buy credits. Only turn on auto-recharge if the card balance covers it; repeated failed auto-charges make the provider's risk engine more likely to block future cards.
Reload the same card later. The number stays the same.

Costs

Item	Cost
Issuance	$10 once + 3% service fee
Per transaction	$1 from the balance
Monthly	$2.50 from the balance
Top-up	$5 + 5%

Why a card gets declined (checklist)

Balance doesn't cover credits + tax + the provider's pre-authorization
Past failed charges or chargebacks on the same account
Billing address is incomplete or inconsistent with the account
Too many retries in a row: wait a bit between attempts

Before you buy

Check each provider's supported countries and usage policies. A prepaid card is a payment method, not a way around a provider's terms.

Questions about a specific decline? Drop the error message in the comments and I'll try to help.

DEV Community: Aidakh