DEV Community

junter1989k-ai
junter1989k-ai

Posted on

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

#ai #mcp #payments #showdev

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

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.

Top comments (0)