Model Context Protocol server
Lets an AI assistant work with the ZEN.com Payment Gateway: create hosted payment links, look up transactions, issue refunds, send payouts and pull reconciliation reports.
Not affiliated with, endorsed by, or maintained by ZEN.com. The name refers to the API it talks to, nothing more.
It was built from public documentation without access to a live merchant account. Verify endpoint versions, field shapes and signing behaviour against ZEN's current OpenAPI or Postman collection before you point it at real money.
claude mcp add zen \ --env ZEN_API_KEY=your_terminal_api_key \ -- npx -y @krystiangw/zen-mcp
{
"mcpServers": {
"zen": {
"command": "npx",
"args": ["-y", "@krystiangw/zen-mcp"],
"env": {
"ZEN_API_KEY": "your_terminal_api_key",
"ZEN_PAYWALL_SECRET": "your_paywall_secret",
"ZEN_IPN_SECRET": "your_ipn_secret",
"ZEN_ENV": "sandbox"
}
}
}
}
Mock mode answers every API-backed tool with deterministic canned data and never touches the network, so you can walk the whole surface before signing up for anything.
ZEN_MOCK=1 ZEN_IPN_SECRET=demo npx -y @krystiangw/zen-mcp
The dummy IPN secret is there because verify_webhook_signature does real cryptography rather than calling the API, so it needs a secret even in mock mode. Any value works for a demo.
In the ZEN merchant panel: my.zen.com → Shop settings → Terminal.
Start on sandbox. The default host is api.zen-test.com, though sandbox availability and onboarding requirements are worth confirming with ZEN directly.
No merchant account yet? You can open a ZEN business account. That is a referral link: it credits the author of this project if you sign up through it, and costs you nothing. Every other link here is a plain one.
| Name | Kind | What it does |
|---|---|---|
| list_payment_methods | read | Payment methods available to the terminal |
| get_transaction | read | One transaction, by ZEN id or your own merchant id |
| list_payment_links | read | Hosted payment links |
| get_payment_link | read | A single hosted payment link |
| get_payout | read | One payout, by ZEN id |
| download_report | read | Transaction and settlement reports for reconciliation |
| list_supported_currencies | read | Documented supported currencies |
| verify_webhook_signature | read | Checks an IPN signature locally, no network call |
| create_payment_link | write | Hosted checkout link and QR code, no card data involved |
| create_customer | write | Customer record, groundwork for recurring payments |
| capture_transaction | destructive | Captures an authorised transaction |
| cancel_transaction | destructive | Cancels a transaction |
| refund_transaction | destructive | Full or partial refund |
| create_payout | destructive | Sends money out. The most sensitive tool here. |
Anything that moves or reverses money carries the destructive hint, so MCP clients can hold it behind a confirmation instead of letting a model fire it off mid-sentence. Read tools are marked read-only and stay that way.
Payment acceptance goes through ZEN-hosted links, which means card numbers never pass through this server and there is no PCI surface to inherit. Raw card charges are deliberately left out of the MVP rather than bolted on.
Secrets are read from environment variables only. They are never tool arguments, so they cannot end up in a transcript, a log line, or a model's context by accident.
The request signing algorithm follows public documentation, but nested-object and array flattening are not fully specified there. That part is isolated in one module, covered by tests, and flagged for verification against the live API.
ZEN_API_KEYZEN_PAYWALL_SECRETZEN_IPN_SECRETZEN_ENVsandbox (default) or production.ZEN_BASE_URLZEN_ENV.ZEN_MOCK1 for offline canned responses.ZEN_HASH_ALGZEN publishes an official API for the Payment Gateway only. The consumer side, meaning cashback, Reward Zone, personal cards and accounts, has no public API, so it is out of scope here rather than approximated by scraping something fragile.
Still on the list: raw card charges once there is a deliberate PCI design behind them, recurring and one-click payments after the tokenisation flow has been verified against a live account, and a remote Streamable HTTP transport with OAuth after the stdio version has proven itself.
TypeScript, validated with Zod, tested with Vitest against an in-memory MCP transport.