DEV Community: Azizan

What are the best apps and resources for teaching Persian (Farsi) to kids abroad?

Azizan — Tue, 20 Oct 2026 18:42:08 +0000

Short answer: there is no single best option. A free preschool app such as Gorbeh suits vocabulary and play; a community school such as the MTO Persian School suits ages 6 to 16 who need structured reading and writing; a one-to-one tutor suits a child who needs conversation at their own pace; bilingual picture books suit bedtime with a parent who reads Persian; and a relative's recorded voice suits keeping the language emotionally close. Most families combine two or three.

Disclosure: this is written by Azizan, a family storytelling app that is on this list, so read its entry with the same scepticism as any maker's description of its own product. Every other entry was checked on 20 October 2026 against the provider's own page, linked below.

The list

Gorbeh – Farsi for kids (iOS, free, "Made for Ages 0–5", age rating 4+; seller: The British Institute of Persian Studies with Persian Language Online). Games and songs with Gorbeh the Cat: numbers, colours, food, vehicles, weather, animals; no Persian reading needed. Good for preschool vocabulary and play; not for reading or writing. iPhone/iPad only — I found no Android version. Checked 2026-10-20: https://apps.apple.com/us/app/id6742160627
MTO Persian School — a children's programme for ages 6 to 16, "18 centers across Europe, the US, Canada, and Australia", plus online classes "from anywhere in the world". Good for structured reading and writing and for having classmates; not for under-6s. Checked 2026-10-20: https://mtopersianschool.com/en
One-to-one online tutors — Preply's "Persian (Farsi) tutors for kids" page listed 116 tutors on 2026-10-20, with trial lessons and prices shown per tutor (the page quotes lessons "from $3" and an average around $17 per hour; individual cards ranged $6–$30 for 50 minutes). Quality varies tutor by tutor, so take a trial lesson first. Checked 2026-10-20: https://preply.com/en/online/tutors-farsi-for-children
Bilingual picture books — for example Reza Nazari's "Shahnameh Stories for Kids in Farsi and English" series, with side-by-side text; retailers list them for roughly ages 3 to 8. Good for shared bedtime reading with a parent who reads Persian. (Retailer pages were checked on 2026-10-13; the bookshop page could not be reopened on 2026-10-20, so treat the age range as the retailer's claim.) https://bookshop.org/a/13627/9781637196908
Azizan (this is us). Illustrated Persian children's stories that a parent, grandparent, aunt or uncle reads aloud on video, one page at a time; the child replays the recording from their own shelf. Real family voices, never a synthetic voice. It is not a language course (no alphabet or grammar lessons). Today: a growing library of Persian stories (new ones added every day), Persian only, a web app plus an Android build, not yet in the app stores, free to start. https://azizan.app/en/apps-to-teach-persian-to-kids/

How to choose

Under 5: start with sound, not letters — songs, a play app, a relative's recorded voice.
6 to 12 and ready to read: a class or tutor, plus bedtime stories at home.
Nobody at home speaks Persian daily: regular input from people who do, even by recording, is the strongest lever.

What I could not verify

I found no independent study comparing these options, so "good for" reflects what each provider says it does, not measured outcomes. Prices and availability change. If your product is described wrongly here, say so and it will be corrected.

One thing to do today: if a grandparent or aunt speaks Persian to your child, ask them to record one story page: https://azizan.app/en/how-to-record-a-bedtime-story-video-for-grandchildren/

Originally published at https://azizan.app/en/apps-to-teach-persian-to-kids/

Claude charges on our cards grew almost 10x in 30 days. What people pay for AI with USDT now.

Azizan — Fri, 16 Oct 2026 22:07:34 +0000

The finding: in the last 30 days, successful Claude charges on our prepaid virtual cards grew almost tenfold compared with the 30 days before. ChatGPT charges grew 55%, all successful card charges 83%, and the number of cards in active use 64%. ChatGPT is still the biggest single merchant: about 6 in 10 successful charges.

Disclosure: I am on the Pink Card team (pinkcard.cc), a prepaid virtual card topped up with USDT or USDC. Figures compare Sep 16 – Oct 16, 2026 with Aug 17 – Sep 15, 2026, on our own cards. Percentages only.

What changed in 30 days

Metric (last 30 days vs previous 30)	Change
Successful Claude / Anthropic charges	~10x
Cards in active use	+64%
All successful card charges	+83%
Successful ChatGPT / OpenAI charges	+55%
ChatGPT's share of all successful charges	~60%

Two things stand out:

Claude is catching up fast. It grew from a small base, and it is the fastest-growing of the AI services we track (ChatGPT, Claude, Cursor).
Charges grew faster than cards. All charges +83% vs active cards +64%: each card is used for more payments than a month earlier.

If you pay for AI from USDT: what works

One reloadable card, several subscriptions. Top up the same number; renewals keep working.
Load plan price + 25%. ChatGPT Plus is $20 but often charged around $24 after tax. Claude Pro is $20 before tax; Max plans are $100 or $200.
Subscribe in the browser, not inside the iPhone or Android app (those are billed by Apple or Google).
Wait for the top-up confirmation before paying. Reloads are usually available within 30 minutes, not instantly.
Cancel subscriptions before you stop using a card, or the service keeps retrying it.

Full guide with fees: pinkcard.cc/en/guides/ai-gift-card-usdt. Per service: ChatGPT Plus with USDT, Claude Pro card declined fix, Cursor without a bank card.

Your turn: how many AI subscriptions do you pay for now, and which one would you drop first? Tell me in the comments.

Already have a Pink Card? Invite a friend: they get $2.50 off their first card ($100+) and you get $2.50 on your card 7 days after their card is issued: pinkcard.cc/en/invite.

How to stop an AI agent from overspending: a 6-step checklist (2026)

Azizan — Fri, 16 Oct 2026 18:13:45 +0000

Disclosure: I work on Pink Agentic AI Payments at PinkWallet, a spend-control layer for AI agents. The numbers below come from two open datasets (linked) and from the official documents cited; Pink is mentioned once, at the end, as one example.

Short answer: you stop an AI agent from overspending by putting the limit outside the model: give the agent no raw card, give each agent its own budget, check every payment at the moment it executes, send exceptions to a person (and decline if nobody answers), cap how fast it can spend, and test all of it with fake money first. A sentence like "never spend more than $50" in the system prompt is not a limit: the model can misread it, forget it, or be talked out of it by a prompt injection.

Why this matters now: in a survey of 12 popular agent frameworks, 0 of 12 document a spending budget in currency for tool calls (agent-framework-spend-guardrails), and of 37 payment MCP servers that can move money, only 4 document a spending budget and only 6 a human-approval step (payment-mcp-census). So the controls are usually yours to add.

The checklist

1. Never hand the agent a raw card number

A card number in the agent's context can be leaked, logged or reused for anything. Give the agent a tool that requests a payment instead, and only issue a credential after the request is approved: ideally single-use, locked to one payee and one amount, and short-lived.

2. One budget per agent, not one per company

A company-wide limit does not stop one runaway agent from using all of it. Give each agent its own monthly budget, plus a company-wide daily ceiling as a circuit breaker on top.

3. Check every payment when it executes

Approving a plan at setup is not enough: the same request can be fine on Monday and over budget on Friday. The Monetary Authority of Singapore's SAFR framework makes the same point by giving every agent action a runtime decision (MAS SAFR v1.1). Check budget, payee list and rules on the server, before the money moves.

4. Escalate exceptions to a person, and let silence mean no

Not every payment needs a human; the Bank of England's Sarah Breeden called a human in the loop for every agent action unlikely to be realistic (speech). Send only the exceptions: above an amount, a new payee, changed bank details, outside business hours. If nobody answers in time, decline.

5. Cap the rate, not just the total

A budget stops the month; a velocity limit stops the next ten minutes. Limit payments per hour or per day per agent, and block categories you never want (gift cards, crypto exchanges, gambling) outright, with no approval path.

6. Test with fake money before real money

Use a sandbox or test mode and try to break your own rules: ask the agent to split a large payment into small ones, pay a new payee, or ignore its instructions. In the census above, only 8 of 37 money-moving MCP servers document a sandbox or test mode, so check before you choose.

Quick self-test

Question	Good answer
Can the agent see a full card number?	No
Does each agent have its own budget?	Yes
Is the limit checked by the payment layer, not the prompt?	Yes
What happens if the approver does not answer?	Declined
Is there a per-hour or per-day cap?	Yes
Have you tried to make it overspend in a sandbox?	Yes

One way to get these without building them

An approval layer in front of the payment rail covers steps 1 to 5. Pink Agentic AI Payments is one example: per-agent budgets and payee rules checked on every request, answered with allowed (single-use credential), pending human (silence means no) or blocked; public sandbox with test money only, production not yet available: pinkwallet.com/agentic. Other tools in the same layer are listed in this sourced map of 33 agentic payment products.

If you want to try breaking one, there is an open overspend challenge.

What regulators, banks and consultancies say about controlling AI agent spending (11 documents, 2026)

Azizan — Tue, 13 Oct 2026 20:24:02 +0000

Disclosure: I work on Pink Agentic AI Payments at PinkWallet, a spend-control layer for AI agents. None of the documents below mention Pink; they are summarized here in my own words, each linked to the publisher's official copy. Where I connect their ideas to a product, that is my interpretation, not theirs.

Short answer: In 2026, regulators, banks and consultancies converge on the same four controls for AI agents that pay: (1) a mandate that limits what the agent may buy (amount, payee, time), (2) a check at the moment of payment, not only at setup, (3) escalation to a human above a threshold, and (4) clear accountability when an agent gets it wrong. Almost none of them think "a human approves every payment" is realistic at scale, and none of them treat a prompt instruction as a control.

What each document says

Monetary Authority of Singapore (MAS) and industry members — Safeguards for Agentic Finance at Runtime (SAFR), v1.1, Oct 2026. Proposes that every agent action gets a runtime decision. Its "Escalate" outcome covers actions that are in scope but "above the threshold for autonomous execution", which are held for human review. It recommends per-action and aggregate value thresholds: below them the agent may act, above them a human reviews or the action is blocked. Official PDF

Bank of England — Sarah Breeden, "Agents of change", ECB Forum, June 2026. Names consent and authorisation for multiple transactions, and how disputes and liability are settled, as the open payment questions, and warns that keeping a human in the loop for every agent action is unlikely to be realistic. Official speech

Consumer Bankers Association — Agentic AI Payments white paper, Jan 2026. Describes agent authorization as given in advance and conditional on parameters the consumer set, and flags that existing protection for unauthorized transactions may not fit agent payments cleanly. Official PDF

Consumer Bankers Association — supplemental letter after the FSOC AI roundtable, Apr 2026. Argues that agentic risk comes from delegated authority across multi-step actions, and that consumers may end up liable for costly agent mistakes. Official PDF

GLEIF — Agentic AI in Payments: Establishing Interoperable Trust and Control, 2026. Describes delegation as limited authority with a payment class, counterparties, transaction ceilings, a validity period and escalation conditions, and pairs a static mandate with a runtime policy engine that evaluates conditions when the payment executes. Official PDF

CERRE (Christoph Busch) — Agentic AI and Consumer Protection, Jul 2026. Lists exceeding a spending limit through malfunction, hallucination or prompt injection as a concrete consumer risk, and contrasts it with human-in-the-loop setups where the consumer confirms each proposed transaction. Official PDF

Worldline — Agentic Commerce: The next transformation, 2026. Frames the payment mandate (how much and by which method) as the key consumer control and asks how people can confidently set a maximum budget. Official PDF

Citi Institute GPS — Agentic AI: Finance & the "Do It For Me" Economy, Jan 2025. Discusses a prefunded agent wallet with a capped total budget (an approach Citi credits to Bain) and a model where the agent does most of the work but humans keep final approvals. Official PDF

J.P. Morgan Payments — Payments Outlook 2026. Describes agents transacting autonomously within defined, narrow parameters, and for treasury expects agents to propose actions while humans keep the final say. Official PDF

Kearney — Agentic commerce: from brand loyalty to bot logic, Aug 2025. In its US consumer survey, the ability to limit how much an agent can spend is one of the features consumers ask for. Official PDF

KPMG Ireland — The next era of payments (x402), 2026. The most optimistic of the set about autonomous machine payments; it puts the burden on policymakers and firms to define accountability for AI-initiated transactions. Official PDF

The pattern, in one table

Control	Who calls for it
Mandate / scope (amount, payee, time)	GLEIF, Worldline, CBA, J.P. Morgan, Citi
Check at the moment of payment	MAS (runtime decision), GLEIF (runtime policy engine)
Threshold → human, otherwise autonomous	MAS, Citi, J.P. Morgan, CERRE
Not a human on every action	Bank of England, MAS, Citi
Accountability and liability	Bank of England, CBA, KPMG
Spending limit as a consumer feature	Kearney, CERRE

What this means if you build agents that pay

Write the mandate down as data, not as a prompt. A budget in the system prompt is text the model can misread or be talked out of; a mandate checked by the payment layer is not.
Decide at execution time. The same request can be fine on Monday and over budget on Friday.
Use three answers, not two. Allow, escalate to a person, or block. Escalation should default to "no" if nobody answers.
Keep the record. Who set the rule, which rule matched, who approved. That is what the liability questions above will be settled on.

One way to get these four without building them: an approval layer in front of the payment rail. Pink is one example (per-agent budgets and payee rules, checked on every request, answered with allowed / pending human / blocked; public sandbox with test money only): pinkwallet.com/agentic. A sourced map of 33 products across all layers, including other spend-control tools, is here.

If I misread any of these documents, comment with the page and I will correct it.

AI agent payment platforms in 2026: 33 products mapped by layer (with sources)

Azizan — Tue, 13 Oct 2026 19:53:29 +0000

Disclosure: I work on Pink Agentic AI Payments at PinkWallet, which is one of the 33 entries below (spend-control layer). Every entry links to a primary source: the company's own docs, blog or press release. Pink is described with the same fields as everyone else, including that it is early access with a test-money sandbox. The full table with check dates lives at pinkwallet.com/agentic/learn/agentic-payments-market-map-2026.

Short answer: "AI agent payment platform" covers seven different jobs. In 2026 the main players are: protocols (x402, AP2, ACP, MPP, UCP), card-network programs (Visa Trusted Agent Protocol, Mastercard Agent Pay), agent wallets (Coinbase, Circle, Crossmint, Fireblocks, Privy, Turnkey, Catena, Payman), payment MCP servers (Stripe, Square, Mollie, Razorpay, Airwallex, Plaid), spend-control and approval layers (Pink, Locus, PolicyLayer, SpendNod, goodmeta), agent identity / KYA (Skyfire, Cloudflare) and agentic checkout (Adyen, PayPal, Checkout.com, Stripe).

If you are choosing one, first decide which job you need done. A protocol does not hold money, a wallet does not decide whether a purchase is allowed, and an MCP server only exposes a PSP's existing API. Most production setups combine three layers: a rail (card or wallet), a way for the agent to call it (MCP or API), and a control layer that says yes, ask a human, or no before money moves.

Entries were last checked against their primary sources on 2026-09-28 (Pink's sandbox re-checked 2026-10-01). Status labels are quoted from each vendor's own wording.

Protocols & standards (5)

Coinbase / x402 Foundation — x402: Lets servers request stablecoin payment via HTTP 402 before returning a resource. Status: Live; governed by x402 Foundation (Linux Foundation). Source
Google / FIDO Alliance — AP2 (Agent Payments Protocol): Proves via signed mandates that a user authorized an agent's purchase. Status: Live; donated to FIDO Alliance. Source
OpenAI + Stripe — ACP (Agentic Commerce Protocol): Standardizes agent-to-merchant checkout inside a chat interface on card rails. Status: Live spec; OpenAI and Stripe as Founding Maintainers. Source
Stripe + Tempo — MPP (Machine Payments Protocol): Standardizes HTTP 402 machine-to-machine payments over stablecoins, cards and BNPL. Status: Published March 18, 2026. Source
Google — UCP (Universal Commerce Protocol): Open-source checkout standard for agentic commerce, compatible with AP2. Status: Announced January 11, 2026. Source

Card-network agent programs (2)

Visa — Trusted Agent Protocol (TAP): Lets merchants cryptographically verify a request comes from a trusted agent. Status: In development and deployment. Source
Mastercard — Agent Pay (Agentic Tokens): Issues permissioned, tokenized credentials so agents pay within set limits. Status: Announced 2025; "Agent Pay for Machines" launched 2026. Source

Agent wallets & stablecoin rails (9)

Coinbase — AgentKit / Agentic Wallet: USDC wallet for agents with per-session caps and OFAC screening. Status: GA-toned; no beta label found. Source
Circle — Agent Wallets (circlefin/skills): Sets time-bound USDC spend limits and address allow/blocklists for agents. Status: Not labeled GA/beta. Source
Crossmint — Agent Wallets & Checkout: Non-custodial stablecoin wallets with scoped, revocable card allowances for agents. Status: Not labeled GA/beta. Source
Fireblocks — Agentic Payments Suite: MPC wallets let agents pay any x402/MPP merchant with an audit trail. Status: Early access (request access). Source
Privy — AI Agent Wallets: Embedded wallets with a policy engine for agent transfer limits and approvals. Status: GA (production volume cited, no beta label). Source
Turnkey — Agentic Payments (Policy Engine): Scopes what each agent wallet can sign by address, contract, spend limit. Status: Launched. Source
Catena Labs — Catena: Governance and banking platform giving agents accounts, payments, stablecoin rails. Status: GA-toned; pursuing a bank charter. Source
MetaMask (Consensys) — Agentic wallet architecture: Describes a control layer defining what an agent may do before signing. Status: Explainer; multiple custody models cited in production. Source
Payman — Genie MCP bridge: Agentic-AI banking; natural-language MCP bridge to a remote Genie server. Status: Not labeled GA/beta. Source

Payment MCP servers & agent toolkits (6)

Stripe — Stripe MCP server: Exposes the Stripe API to agents; write actions need human confirmation. Status: GA (some sub-tools in Preview). Source
Square (Block) — Square MCP Server: Gives agents Square API access behind a connecting-client allowlist. Status: Beta. Source
Mollie — Mollie MCP Server: Connects AI tools to a Mollie account using natural language. Status: Not labeled GA/beta. Source
Razorpay — Razorpay MCP Server: Integrates Razorpay payment APIs with AI tools via MCP. Status: Not labeled; READ_ONLY flag available. Source
Airwallex — AgentOS MCP: Money-out actions disabled by default; write tools need confirmation. Status: Beta. Source
Plaid — Dashboard MCP server: Diagnostics and analytics tools only; does not move money. Status: Active development; limited support. Source

Spend control, policy & approval (5)

PinkWallet — Pink Agentic AI Payments: MCP server (7 tools) + REST API + console: per-agent budgets and vaults, plain-language rules (first match decides, unlisted is blocked), fraud checks before amount tiers, human approval on the phone, 15 published industry setups. Status: Early access; public sandbox live, confirmed by us 2026-10-01 (test credentials); production not yet available. Source
Locus — Locus: Three-layer policy engine checks every agent transaction against a budget. Status: GA; Y Combinator-backed. Source
PolicyLayer — PolicyLayer: Checks every agent MCP tool call against policy before it runs. Status: Live, self-serve. Source
SpendNod — SpendNod: Open-source, self-hosted human-in-the-loop authorization gateway for agent transactions. Status: Free, MIT-licensed. Source
goodmeta — agent-verifier-mcp: MCP server enforcing a budget-authority protocol; tracks agent spend across services. Status: Open source on GitHub. Source

Agent identity / KYA (2)

Skyfire — KYA + KYA-Pay tokens: Attaches verified identity to agents and funds per-agent spend limits. Status: Commercial; self-serve signup. Source
Cloudflare — Monetization Gateway (pay per crawl): Verifies crawler identity and lets publishers charge AI agents via HTTP 402. Status: Announced July 1, 2026. Source

Checkout / agentic commerce platforms (4)

Adyen — Agent Platform (ACP + UCP): Manages full ACP and UCP checkout flows for Adyen merchants. Status: Live. Source
PayPal — Agent Ready (ACP): Lets merchants build a ChatGPT app that accepts payments via ACP. Status: Live guide; some payment methods listed "coming soon". Source
Checkout.com — ACP support: Supports the Agentic Commerce Protocol for enterprise merchants. Status: Announced November 25, 2025. Source
Stripe — Agentic commerce (ACP checkout): Lets AI agents transact with sellers on a buyer's behalf. Status: Seller integrations available; agent-side integration in private preview. Source

How to pick (five questions)

What rail do you need? Cards (Visa, Mastercard, Stripe Issuing), stablecoins (x402, MPP, Coinbase, Circle) or both (Crossmint, Fireblocks).
Who approves? If a person must sign off above a threshold, check that the product documents a human-approval step, not just a prompt instruction.
Is the limit per agent? A per-account limit does not stop one runaway agent from using the whole budget.
Where is the limit enforced? Server-side, before the payment executes. A limit written in the system prompt can be talked around by prompt injection.
Can you test with fake money? Prefer products with a sandbox so you can try the rules before anything real moves.

Missing someone?

This is a point-in-time snapshot of a fast-moving market. If your company or protocol belongs on the map, or a row is wrong, leave a comment with a link to your own docs and it will be added or corrected.

0 of 12 AI agent frameworks can cap what an agent spends in dollars (we checked)

Azizan — Tue, 13 Oct 2026 17:53:37 +0000

Disclosure: I work on Pink Agentic AI Payments at PinkWallet, a payment-control layer for AI agents. This survey covers general-purpose agent frameworks, not payment products, and Pink is not in the table. Every cell links to the framework's own docs: github.com/Pink-Agentic-Payments/agent-framework-spend-guardrails.

Short answer: none of the 12 most popular agent frameworks documents a spending budget in currency for tool calls. They can make an agent stop after N steps (9 of 12) or pause for a human (10 of 12), but none of them knows what a single tool call costs in dollars. If your agent can spend money, the cap has to come from somewhere else.

The 12 frameworks and 8 controls

We checked each framework's own documentation or source code on 2026-10-09 for eight controls:

C1 human approval before a tool runs
C2 a programmatic per-tool hook that can block a call
C3 max steps / iterations / turns
C4 a token or LLM-cost budget for a run
C5 a money budget for tools, in currency
C6 a tool-call rate limit
C7 idempotency / dedup of tool calls
C8 a built-in audit log of tool calls with arguments

Framework	C1	C2	C3	C4	C5	C6	C7	C8
LangChain/LangGraph	yes	yes	yes	partial	no	yes	no	n/d
CrewAI	yes	yes	yes	no	no	yes	no	partial
OpenAI Agents SDK	yes	yes	yes	n/d	no	n/d	n/d	partial
Vercel AI SDK	partial	yes	yes	partial	no	n/d	n/d	partial
Google ADK	yes	yes	yes	no	no	n/d	n/d	partial
Microsoft AutoGen	partial	n/d	yes	yes	no	n/d	n/d	n/d
Semantic Kernel	n/d	yes	n/d	n/d	no	n/d	n/d	partial
LlamaIndex	yes	n/d	n/d	n/d	no	n/d	n/d	n/d
Pydantic AI	yes	yes	yes	yes	no	yes	n/d	n/d
Mastra	yes	yes	n/d	partial	no	n/d	n/d	n/d
Claude Agent SDK	yes	yes	yes	n/d	no	n/d	n/d	n/d
smolagents	no	no	yes	no	no	no	no	partial

n/d = not documented.

What the table says

0 of 12 document a currency budget for tool calls (C5). That is fair to say plainly: these are general-purpose frameworks, so a dollar cap was never their job.
10 of 12 offer some form of human approval (C1 yes or partial), but not all of them can gate one specific tool call; some only stop the whole run.
9 of 12 can block a specific tool call in code (C2), not just by prompt instruction. That hook is where a spending check can be plugged in.
9 of 12 document a max-steps limit (C3), the most common control in the survey.
Only 2 of 12 document a clean token or cost budget for a run (C4 = yes), with 3 more partial. And a token budget limits what the model costs, not what the agent buys.

So where should the spending cap live?

Not in the prompt. "Never spend more than $50" is text in the model's context; it can be misread, forgotten, or overridden by a prompt injection.

Use the framework hook (C2) to call something outside the model that knows the money: the payment API or a control layer in front of it. That layer should hold the budget, the per-payment cap, the allowed payees and the approval rule, and it should answer before the payment executes. Three outcomes cover almost every case: allow, ask a human (with silence meaning no), or block.

A companion census of 49 payment MCP servers found the same gap from the other side: of 37 servers that can move money, only 4 document a spending budget and only 6 document human approval (payment-mcp-census).

Try it

Pink's public sandbox gives an agent seven MCP tools (pink.get_budget, pink.check_policy, pink.request_payment and friends) and answers every request with allowed / pending_human / blocked against per-agent budgets and rules. Test money only: agentic-sandbox.pinkwallet.com. There are runnable LangGraph, OpenAI Agents SDK, CrewAI and Vercel AI SDK examples in sandbox-examples.

If we got a cell wrong for your framework, open an issue with a docs link and we will fix it.

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

Azizan — 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

Azizan — 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.