Trust & Security

What these servers can see, what they structurally cannot, and how to stop trusting us entirely.

The short version. There is no database. Your API keys travel in an HTTP header, are used once to call your payment gateway / tax authority / carrier, and are gone when the function returns. Money never touches us — it flows buyer → gateway → you. And because every server is MIT-licensed, you can deploy the identical code to your own account and point your agent at your own URL. Then the question "who can see my keys?" answers itself: you can, and nobody else.

Threat model — what each party can see

Data	Your AI agent	This server (hosted by us)	Your gateway / tax authority
Your API keys / certificates	Holds them (in your client config)	In memory for one request, never written anywhere	Yes — they are its keys
Buyer card / bank details	Never	Never — buyer enters them on the gateway's own page	Yes
Order amounts, invoice contents	Yes	In memory for one request only	Yes
Funds	Never	Never — we are not a payment institution	Yes — settles directly to you

Data

Your AI agent

This server (hosted by us)

Your gateway / tax authority

Your API keys / certificates

Holds them (in your client config)

In memory for one request, never written anywhere

Yes — they are its keys

Buyer card / bank details

Never

Never — buyer enters them on the gateway's own page

Yes

Order amounts, invoice contents

Yes

In memory for one request only

Yes

Funds

Never

Never — we are not a payment institution

Yes — settles directly to you

Why "stateless" is a structural claim, not a promise

These servers run as serverless functions with no database attached, no object storage, no log of request bodies. A promise not to look at your data can be broken. An architecture with nowhere to put your data cannot. You can verify this the same way we do: read the source. Every repository is public and MIT-licensed.

What is recorded: an availability heartbeat (endpoint reachable / not reachable) and — if the operator has configured it — a notification when a tool call succeeds or fails, containing the country, the tool name, and whether credentials were present. Never a key, never a buyer, never an amount.

Don't trust us — run it yourself

Every server in the family is a small, dependency-light repository you can deploy in about a minute. Your own deployment, your own domain, your own environment variables. The behaviour is identical because the code is identical.

git clone https://github.com/junter1989k-ai/taiwan-payments-mcp cd taiwan-payments-mcp npx vercel --prod # your account, your URL # then point your agent at your own deployment: # "url": "https://your-own-deployment.vercel.app/mcp"

This is the honest answer to "is it safe to send production credentials to a shared remote MCP server?" — for most people the shared endpoint is fine, because nothing is stored. For a business that would rather not find out, self-hosting removes us from the picture entirely, at zero cost and with no loss of function. We would rather you self-host than not use it at all.

Owner guardrails (the agent cannot relax them)

Money-moving tools accept optional policy headers, set by the human owner in the client config. The agent sees the resulting restriction but cannot remove it, because it lives in the transport, not in the conversation.

Header	Effect
`x-agentpay-max-amount`	Any call above this amount is refused with `POLICY_BLOCKED`.
`x-agentpay-approval-above`	Above this amount the tool returns an unsigned draft instead of executing — a human confirms and re-issues.
`x-agentpay-allowed-tools`	Hides and hard-blocks every tool not on the list (e.g. allow `query_payment_status`, forbid `refund_payment`).

Header

Effect

x-agentpay-max-amount

Any call above this amount is refused with POLICY_BLOCKED.

x-agentpay-approval-above

Above this amount the tool returns an unsigned draft instead of executing — a human confirms and re-issues.

x-agentpay-allowed-tools

Hides and hard-blocks every tool not on the list (e.g. allow query_payment_status, forbid refund_payment).

Credential model, per family

Family	Who holds the secret	Who signs
Payments (81 countries)	You — your gateway's API keys, sent per request	The server computes the gateway's signature per request; nothing cached
E-invoices (31 national rails)	You — your certificate lives in your own account with the tax authority or provider	You do. For Saudi Arabia, Korea, Uruguay, the Dominican Republic and others, the server relays an envelope you already signed. Your private key never leaves your side.
Logistics (19 countries)	You — your carrier or aggregator token	n/a
Merchant of Record (8 platforms)	You — your platform key	n/a

Family

Who holds the secret

Who signs

Payments (81 countries)

You — your gateway's API keys, sent per request

The server computes the gateway's signature per request; nothing cached

E-invoices (31 national rails)

You — your certificate lives in your own account with the tax authority or provider

You do. For Saudi Arabia, Korea, Uruguay, the Dominican Republic and others, the server relays an envelope you already signed. Your private key never leaves your side.

Logistics (19 countries)

You — your carrier or aggregator token

n/a

Merchant of Record (8 platforms)

You — your platform key

n/a

Known limits (stated plainly)

Reporting something

Found a flaw, a misleading description, or a tool that claims a capability it does not have? Open an issue on the relevant repository, or write to reports@wishpool.app. Honest gaps are documented in every README on purpose — if you find one we missed, that is a bug.