DEV Community: junter1989k-ai

A stranger on Reddit suggested a guardrail for my payment MCP servers. It shipped to 30 countries in one day.

junter1989k-ai — Wed, 08 Jul 2026 22:04:56 +0000

Last week I posted about a family of MCP servers that let AI agents accept payments — Pix in Brazil, UPI in India, GCash in the Philippines, PromptPay in Thailand, one stateless server per country.

The first substantive reply came from someone who works on agent guardrails. Their point, paraphrased:

Trust boundaries around money custody are solved by your design (the server never holds funds). But there's a second boundary you haven't addressed: a well-formed request can still be a request the agent should never have made. Amount limits, allow-lists, human-approval thresholds — checked deterministically before anything is signed.

They were right, and the interesting part was figuring out how to do this statelessly — these servers have no database, no accounts, no config storage. Credentials ride on HTTP headers per request. Where does policy live?

The answer: policy rides the same channel as credentials

The MCP client config (where a human pastes API keys) is something the agent cannot touch. Model output never edits claude_desktop_config.json or a .mcp.json. So policy set there has a property no in-band instruction has: the model cannot relax its own limits.

Two headers, checked before any signature is computed:

x-agentpay-max-amount: 1000
x-agentpay-approval-above: 100

x-agentpay-max-amount — hard cap in the local currency's major unit. Anything above is refused with a readable POLICY_BLOCKED error that tells the agent to ask the human, not to retry.
x-agentpay-approval-above — softer: amounts above return an unsigned draft (all payment parameters, payment_url: null, approval_required: true) for the human to review. There is deliberately no bypass parameter — the only way to proceed is for the owner to change the header in their client config.

A weak local model can't be prompt-injected past this, because the check isn't in the prompt. It's a deterministic if before the crypto.

// before any PSP call or signature:
const gate = policy.enforce(headers, amountMajor);
if (gate.needsApproval) return policy.draftResult(field, amountMajor, description, gate.threshold);

From suggestion to 30 countries

The same ~40-line policy.js dropped into every server, because they all share one shape: validate → policy gate → sign/call → return hosted checkout URL. The rollout:

Day 0: shipped to the 20 live countries (Asia + Latin America + US/UK/NL/SG/NG), behavior tests + full e2e regression.
Day 1: baked into the country generator, so the next wave was born with it — Turkey (iyzico), Saudi Arabia & UAE (Tap / mada), Kenya (Flutterwave / M-Pesa), Ghana & South Africa (Paystack), Poland (Stripe / BLIK), Germany & Belgium (Mollie / Klarna / Bancontact), France. That's 30 countries, every one policy-gated from its first request.

Each server's e2e suite now asserts both branches with a fake key against the real gateway:

PASS policy cap -> POLICY_BLOCKED
PASS policy approval -> unsigned draft

And the daily fingerprint canary (a watchdog that hits every gateway with fake keys and asserts the error fingerprint hasn't changed) grew to 30 endpoints / 36 canaries.

Takeaways

Policy for AI agents belongs outside the model. Headers set by a human in client config are a surprisingly good policy channel: zero storage, per-merchant, and structurally out of the agent's reach.
Draft mode beats refusal for the human-in-the-loop case. Returning the parameters (but no live link) gives the human something to approve instead of a dead end.
Community feedback compounds when your architecture is uniform. One suggestion became a family-wide feature in a day because all 30 servers share one skeleton.

The family hub with all 30 endpoints: mcp.wishpool.app — each country page's llms.txt documents the two policy headers. All open source (MIT), all on the official MCP Registry under app.wishpool/*.

If you're building agent guardrails and see a boundary I've missed — that's exactly the kind of comment that turned into this feature. 🙏

AI agents can now accept payments in 10 countries — Pix, UPI, GCash, PromptPay, konbini, KakaoPay (one MCP server each)

junter1989k-ai — Wed, 08 Jul 2026 17:32:28 +0000

Last week I built an MCP server so AI agents could accept payments in Taiwan. This week the same pattern grew into ten countries — one MCP server per country, each wrapping the payment rails that country actually uses:

Country	MCP endpoint	Local rails
🇹🇼 Taiwan	`https://mcp.wishpool.app/mcp`	ECPay + NewebPay, convenience stores, government e-invoices
🇯🇵 Japan	`https://mcp-jp.wishpool.app/mcp`	konbini コンビニ, PayPay (KOMOJU)
🇰🇷 Korea	`https://mcp-kr.wishpool.app/mcp`	cards, KakaoPay / NaverPay (Toss Payments)
🇮🇩 Indonesia	`https://mcp-id.wishpool.app/mcp`	GoPay, QRIS, Alfamart cash (Midtrans)
🇮🇳 India	`https://mcp-in.wishpool.app/mcp`	UPI — Google Pay / PhonePe / Paytm (Razorpay)
🇧🇷 Brazil	`https://mcp-br.wishpool.app/mcp`	Pix, boleto (Mercado Pago)
🇵🇭 Philippines	`https://mcp-ph.wishpool.app/mcp`	GCash, Maya (PayMongo)
🇹🇭 Thailand	`https://mcp-th.wishpool.app/mcp`	PromptPay QR, TrueMoney (Opn/Omise)
🇲🇾 Malaysia	`https://mcp-my.wishpool.app/mcp`	FPX online banking, DuitNow QR (Billplz)
🇻🇳 Vietnam	`https://mcp-vn.wishpool.app/mcp`	MoMo wallet QR — zero-setup sandbox demo

All ten are on the official MCP Registry under app.wishpool/*, MIT-licensed, zero runtime dependencies.

Why per-country servers?

Global processors skip the rails locals actually pay with. A Japanese buyer wants to pay at 7-Eleven. An Indian buyer scans UPI. A Brazilian uses Pix. A Filipino uses GCash. Those rails were built for humans clicking through checkout pages — there is no agent-ready API for "let my customer pay the way they normally pay."

Each server is a stateless translation layer (~500 lines of Node, no database): it turns one country's hosted-checkout API into two or three MCP tools. Same shape everywhere:

create_payment_link → returns a hosted checkout URL for the buyer
query_payment_status → pull-based polling, no webhooks needed
(Korea only) confirm_payment — Toss requires a server-side approval within 10 minutes of buyer authentication, so the flow is exposed honestly as a third tool

Bring-your-own credentials: the merchant's API keys ride along as HTTP headers on every request and are used in memory only. Funds always flow buyer → gateway → merchant. The servers never touch money — which also keeps them clean legally in every jurisdiction.

Designing for weak models

Most MCP clients aren't frontier models — plenty are small local models that skim tool descriptions. So the guidance lives in the tool results, at the right moment, not in documentation nobody reads:

{
  "payment_url": "https://...",
  "next_steps": [
    "1. Give payment_url to the buyer and ask them to open it and pay.",
    "2. Call query_payment_status with order_id=KR2607091542XYZ every ~15 seconds.",
    "3. When status becomes IN_PROGRESS, immediately call confirm_payment (you have only 10 minutes)."
  ]
}

Every query_payment_status state carries a one-line next hint: "Buyer authenticated — NOW call confirm_payment", "Link expired — create a new one". A 7B model can follow that.

Verification without opening ten merchant accounts

I didn't register merchant accounts in ten countries (each KYC would take weeks). Instead:

Spec verification: every request format checked against official docs, and for signature-based gateways, byte-compared against production SDKs.
Fake-key live probes: every e2e suite fires a fake key at the real production API and asserts the gateway's own auth error comes back (UNAUTHORIZED_KEY in Korean from Toss, Authentication failed from Razorpay…). That proves the wire path is real.
Zero-setup demos where possible: Taiwan (ECPay's public sandbox) and Vietnam (MoMo's documented public sandbox credentials) do real sandbox transactions end-to-end — try them with no credentials at all.
A daily canary replays those probes against every gateway and emails me if any fingerprint changes — so if a PSP moves an endpoint, I know before the first user does. This already paid off during the build: PayMongo's legacy Links API turned out to be dead (404 behind the gateway), which the probe caught, and I shipped Checkout Sessions instead.

The rest of the verification is the BYO architecture itself: the first merchant who brings a real key is the live test, failures are loud and readable, and a beacon mails me the moment a real-key call fails for any non-auth reason.

Try it

Point any remote-MCP client (Claude Desktop / Claude Code / Cursor) at the Vietnam or Taiwan endpoint — both work instantly with no credentials:

{
  "mcpServers": {
    "vietnam-payments": { "type": "http", "url": "https://mcp-vn.wishpool.app/mcp" }
  }
}

Ask your agent to "create a 50,000 VND payment link" and watch it come back with a real MoMo sandbox checkout URL.

All repos: github.com/junter1989k-ai — feedback and country requests welcome.

I built an MCP server so AI agents can accept payments in Taiwan

junter1989k-ai — Wed, 08 Jul 2026 13:03:53 +0000

I run a small education business in Taiwan. When I started letting AI agents handle operations, they kept hitting the same wall: Taiwan's payment gateways and the government e-invoice system are built for humans clicking through web pages. No agent-usable API anywhere.

So I wrapped that layer into a remote MCP server: https://mcp.wishpool.app/mcp

What it does

create_payment_link — TWD payment link (credit card / ATM / convenience store / mobile). Aggregates two local gateways, ECPay 綠界 and NewebPay 藍新, behind one tool — the agent picks with a provider field, or it auto-selects from which credential headers you send.
query_payment_status — pull-based payment check, no webhook needed
issue_einvoice / invalid_einvoice — Taiwan legally requires a government e-invoice (電子發票) for every sale; agents can now issue and void them, including company invoices with a tax ID (統一編號).

Three design constraints that shaped everything

1. Never touch funds

Taiwan's Electronic Payment Act makes holding other people's money without a license a criminal offense (3–10 years). So this is a stateless translation layer:

You bring your own merchant credentials as HTTP headers on each request
Money flows buyer → gateway → merchant directly
The server stores nothing — no database at all. A payment link is literally the signed checkout form encoded into the URL itself.

2. Zero-setup demo

ECPay publishes public sandbox credentials, so with no headers every tool runs against the official test environment. Add the server URL to Claude, Cursor, or any remote-MCP client and you can create a (fake) payment link in about a minute.

3. Zero dependencies

Hand-written JSON-RPC over streamable HTTP. The whole thing is a few small files of plain Node — no framework, no SDK. When you sign payment requests for a living, you want to read every line that touches the crypto.

The crypto part (the scary part)

Payment gateways here use bespoke signing schemes:

ECPay: SHA-256 over a sorted query string with .NET-style URL encoding
NewebPay: AES-256-CBC encrypted trade payloads + SHA-256 TradeSha

For NewebPay (which has no public sandbox), I cross-checked my implementation against two independent production SDKs and verified the AES output is byte-identical to OpenSSL before shipping. Merchants bring their own credentials, so their first sandbox call is the final integration test — and error messages pass through readable.

Why aggregate gateways?

A single-gateway wrapper dies the day that gateway ships its own official MCP. An aggregation layer is a different product: one tool surface across many local gateways, in a market where every gateway has its own bespoke API. That's also the world-scaling plan — the big providers build the global highways; this covers the local roads they don't bother with (Taiwan e-invoices today; the same pattern fits Japan's konbini payments or Korea's local PSPs later).

Links

Endpoint: https://mcp.wishpool.app/mcp (streamable HTTP)
Source (MIT): https://github.com/junter1989k-ai/taiwan-payments-mcp
Official MCP Registry: app.wishpool/taiwan-payments-mcp

Honest caveats: the NewebPay path is verified against reference implementations and OpenSSL but not yet with a live merchant account, and the demo sandbox never moves real money. If you're building agents that need to do real-world commerce in markets the big providers skip — I'd love to compare notes.