Zenoz is multi-tenant regulated money movement infrastructure with deep integrations into tier-1 processors and banks. Push to a card in seconds, settle cross-border over XRP Ledger or SWIFT, run ACH, RTP and FedNow, deliver cash for pickup, and board merchant accounts — all from one API, one ledger, one dashboard, operating under a PCI-certified card processing environment.
Coming September 15, 2026
curl -fsSL https://cloud.zenoz.ai/install.sh | shThen zenoz login and zenoz init. Nothing issued here can move real money. See the whole flow ↓
A walkthrough for banks, program managers and platform partners evaluating Zenoz as the gateway under their portfolio.
The shell script is a bootstrapper, not a wizard. The browser owns identity. The terminal never sees a password, and it ends in money moving — not in "you have an account."
curl -fsSL https://cloud.zenoz.ai/install.sh | sh — verifies SHA-256 against a signed manifest, installs to ~/.local/bin, never uses sudo, never edits your dotfiles. Under 250 readable lines, because you'll open it first.
zenoz login opens a browser tab. OAuth device flow (RFC 8628), the same mechanism behind gh and stripe. Your sandbox tenant links to this machine; credentials land in ~/.zenoz/credentials.toml, mode 0600.
zenoz init asks two things — rail and language — then sends a $25.00 sandbox payout, renders every status transition, and writes a quickstart containing the exact request that just settled, with your key already in it.
Zenoz is built for the partner who sits above merchants: a bank, a program manager, a platform. Every tenant gets its own merchants, keys, limits and ledger — and you see all of it.
Tenants own merchants; merchants own recipients and keys. Every transaction row carries merchant and tenant attribution, so portfolio questions narrow to one merchant without switching context.
Visa Direct, Mastercard Send and Visa VPC for push-to-card; Ripple over XRPL and SWIFT wires for cross-border; ACH same-day and next-day, RTP and FedNow for domestic. Rail mix is a query, not a re-integration.
Capability flags per merchant, per-transaction and velocity limits per rail, sanctions screening on every recipient, and a two-phase quote/commit so nothing moves on a single call.
Submit a merchant application from your own onboarding flow — MCC, average ticket, expected volume, owners, settlement account — and get back an application ID, an auto-approve or manual-review decision, and a MID when approved. Webhooks tell you when the status changes.
Send a payout to be collected in cash at an agent location. Track it from ready to claimed, extend or cancel before collection, and let unclaimed funds return to the merchant ledger automatically on expiry.
Zenoz operates under a PCI DSS–certified card processing environment. Card data for push-to-card payouts and acquiring stays inside that boundary, so merchants and partners integrate without taking on the cardholder-data scope themselves.
Self-serve credentials are sandbox-scoped and enforced by the token itself. Production keys are minted in the dashboard, behind KYB and an owner-role check.
The Zenoz MCP server answers "what's stuck in manual review?" and "what's our effective rate on RTP?" straight from the API. Read-only, tenant-scoped, no CSV export.
Nine rails and cash pickup, one request shape. Recipient, amount and idempotency key stay the same; Zenoz handles the processor, the bank, the agent network and the settlement path — push-to-card, XRPL and SWIFT cross-border, same-day and next-day ACH, the two instant networks, and cash collected in person.
Push to a debit card. Settles in seconds. The default first rail in zenoz init.
Push to a debit card across the Mastercard network. Seconds to settle, same request shape.
Push to a card via Visa Payout Connect for programs that need the VPC path.
Cross-border settlement over the XRP Ledger. Test XRPL addresses in sandbox; a few seconds to settle.
International wires over the SWIFT network for correspondent-bank payouts where the recipient isn't on XRPL. Multi-currency, with tracking on the same ledger.
Same-day ACH credits and debits through the Nacha same-day windows. Returns land on the same ledger as the original item.
Standard next-day ACH for scheduled payouts and lower-cost volume where speed isn't the point.
Real-time payments over The Clearing House network. Final and irrevocable, 24/7/365, with request-for-payment on the roadmap.
The Federal Reserve's instant rail, for banks and credit unions on FedNow rather than RTP. Same request shape as everything else.
For recipients without a card or bank account. The payout becomes a pickup code delivered to the recipient; the funds are held on the merchant ledger until an agent location confirms collection. Manage the whole lifecycle from the API — ready, claimed, extended, cancelled, expired — with unclaimed funds returning to the merchant automatically.
Card acquiring (CARD) runs on the same ledger, with refunds, voids, chargebacks and ACH returns tracked as first-class transaction types.
Two capabilities that usually mean a second vendor live on the same API, the same key and the same ledger as your payouts: merchant account boarding and cash pickup management.
Submit the application, get a decision, receive the MID. Auto-approval handles the clean cases; anything else lands in a manual-review queue your team can see the age of. KYB, MCC and risk tier are on the record from day one.
// POST /v1/merchants/applications const app = await zenoz.merchants.applications.create({ legalName: "Acme Retail LLC", dba: "Acme", mcc: "5812", averageTicket: { value: 32800, currency: "USD" }, expectedMonthlyVolume: { value: 1174500, currency: "USD" }, owners: [{ name: "Jordan Lee", ownershipPct: 100 }], settlementAccount: { routing: "•••••", account: "•••••" }, services: ["card_acquiring", "payouts"] }, { idempotencyKey }); // → { id: "app_4d1f", status: "MANUAL_REVIEW" } // webhook application.approved → { mid: "830387595323273", riskTier: "medium" }
A cash pickup is just another rail on the payout request. Zenoz issues the pickup code, holds the funds on the merchant ledger, and reports every state change until an agent confirms collection — or the pickup expires and the money comes back.
// POST /v1/payouts — same call, rail: cash_pickup const payout = await zenoz.payouts.create({ rail: "cash_pickup", recipient: "rcp_7c21", amount: { value: 2500, currency: "USD" }, pickup: { expiresIn: "P7D", notify: "sms" } }, { idempotencyKey }); // → { id: "pyt_01JQ9M4", status: "READY_FOR_PICKUP", pickup: { expiresAt } } await zenoz.pickups.extend(payout.id, { expiresIn: "P3D" }); await zenoz.pickups.cancel(payout.id); // funds return to the merchant ledger
Pickup codes are never returned to the merchant in the API response — they go to the recipient only, so the merchant can't become the phishing vector. Both APIs are available in sandbox through the same zenoz login credentials.
Connect the Zenoz MCP server to Claude and ask about volume, fees, rail mix, stuck money and your onboarding queue the way you'd ask a colleague. Every answer comes straight from the API, scoped to what your key can see.
Read-only today. Nothing you ask can move money or change state — the money-moving payout.quote / payout.commit tools ship with their own key class and step-up confirmation.
Account creation, terms, email verification and tenant creation happen on cloud.zenoz.ai, where consent records, bot defenses and KYB live. The CLI never collects a password.
Card processing runs inside a PCI DSS–certified environment. Test PANs in sandbox, tokenized card references in production, and no raw card data in your systems or in API responses.
Applications submitted by API go through the same KYB, MCC and risk-tier checks as the dashboard. Production processing for a boarded merchant starts only on approval, and the decision is on the record.
Self-serve tokens carry a sandbox environment claim that cannot be exchanged for production scopes — enforced server-side, not by the client.
Access tokens live one hour; refresh tokens rotate on use and a reused one revokes the whole family. Every device approval writes an audit event with one-click revoke.
SHA-256 against a manifest signed in CI. No sudo, no dotfile edits, atomic writes, and a main() wrapper so a truncated download runs nothing.
Natural-language intents extract to a rigid schema; anything ambiguous is a refusal. Policy runs server-side and re-runs at commit, bound to the quote the merchant actually read.
A pickup holds funds on the merchant ledger until an agent confirms collection. Codes are single-use, delivered to the recipient only, and unclaimed funds return automatically at expiry.
The literal request, the extracted schema, the quote hash, every preflight result and the confirmation evidence are logged — because "the merchant said send it" is not a defense.
We'll run a payout on each rail from the sandbox, walk the tenancy and control model, and show what your team could ask the MCP server on day one. Bring a merchant list if you have one.