The most common questions about ZenoPay — from how it works to what it costs, to how it handles your customers' money.
ZenoPay is an autonomous payment intelligence platform. It sits between your application and your payment processors — routing charges across 15 global payment rails, scoring subscriber churn risk daily, blocking fraud before it reaches the processor, managing subscription billing, and disbursing payouts. All autonomously, with a hard guardrail layer that cannot be overridden by the AI.
The short version: it handles the parts of payments that currently require a person watching dashboards, configuring retry logic, and making judgment calls. ZenoPay makes those decisions automatically, logs every one in plain English, and escalates anything above its configured confidence threshold to a human.
Any business with recurring revenue and more than one payment rail. The original design target was SaaS companies — subscriptions, trials, dunning, churn — but the platform applies broadly to:
The minimum useful setup: a business processing $50K+/month with at least two payment rails and a measurable churn or routing cost problem.
It means the platform acts without waiting for a human to tell it what to do. When a payment fails, the brain evaluates the customer's history, selects the next best rail, and retries — without a dunning configuration wizard, without a person clicking "retry", and without a scheduled job you built. When a customer's churn score crosses the threshold, the brain identifies the cause, selects the appropriate intervention (BNPL offer, outreach, or human escalation), and executes it.
Autonomous does not mean uncontrolled. Every action requires passing the guardrail engine — a structurally independent code path that validates the action against hard limits you define. The brain cannot exceed your configured maximum charge amount, cannot use a rail you haven't approved, and cannot change its own guardrails. Those require human approval, always.
Stripe Billing executes what you configure. ZenoPay reasons about what should happen and acts on it. Stripe Billing routes all charges through Stripe. ZenoPay routes charges across 15 rails — including GoCardless at ~50bps vs Stripe's ~290bps for recurring billing. Stripe Billing has no churn intelligence. ZenoPay scores every subscriber daily across 14 behavioral signals.
Practically: you can connect ZenoPay on top of Stripe without migrating away from it. Stripe becomes one of your 14 available rails. ZenoPay adds the routing intelligence, churn scoring, fraud pre-authorization, and autonomous brain on top. You don't need to choose.
Spreedly and Primer are payment orchestration platforms — they route transactions across multiple processors. ZenoPay does that and significantly more: an autonomous AI brain that scores churn, blocks fraud, manages subscriptions, and learns from its own outcomes. Spreedly charges $2,000–$16,000/month with a history of unilateral price increases. Primer charges 0.2–0.6% per transaction on top of processor fees. ZenoPay charges a flat monthly license with no per-transaction fees.
The deeper difference: Spreedly and Primer are human-operated platforms. You configure the routing rules. ZenoPay reasons about routing decisions autonomously, adapting to live approval rate data on a 7-day rolling window.
Flat monthly license. No per-transaction fees. Three tiers:
Annual contracts with locked pricing. Spreedly charges $2,000–$16,000/month with documented price increases. ZenoPay's pricing is contractually locked for the term.
No. ZenoPay charges a flat monthly license. There are no per-transaction fees on top of that.
Processor fees — what Stripe, GoCardless, Braintree, etc. charge to process the actual payment — pass through to you at cost. ZenoPay does not mark them up. At $1M/month in processing volume routed through GoCardless instead of Stripe, you save approximately $24,000/month in processor fees. That saving is yours entirely.
At $500K/month in processing volume (Primer's minimum), 0.2% is $1,000/month. At 0.6%, it's $3,000/month — just for routing, before any processor fees. At $1M/month, that's $2,000–$6,000/month in routing fees alone.
ZenoPay at the Scale tier is $3,500/month flat. At $1M/month in volume, ZenoPay is less than Primer's routing fee, covers more rails including GoCardless at 50bps, includes full billing engines, churn intelligence, fraud detection, and payout disbursement.
The core connection — tenant creation, webhook endpoint, first vaulted payment method — takes 30–60 minutes. The full integration including billing plans, subscription migration, and rail configuration takes 1–3 days depending on how complex your existing setup is.
If you're already on Stripe Billing, you can connect ZenoPay alongside it without migrating. Point your Stripe webhooks at ZenoPay's endpoint. Set metadata.tenant_id on your Stripe Customer objects. Vault your customers' existing Stripe payment tokens. Done. The brain starts scoring your customer base immediately.
No. ZenoPay works alongside Stripe. Stripe becomes one of your 15 rails — the default primary rail. The router scores it alongside GoCardless, Braintree, and any other rails you configure, and routes to the optimal one per transaction.
Your checkout flow doesn't change. Your customers don't notice. You keep your Stripe credentials and existing payment methods. ZenoPay adds the intelligence layer on top without replacing what's already working.
Three things:
https://app.zenopay.ai/api/webhooks?source=stripetenant_id: YOUR_TENANT_ID to each Stripe Customer object's metadata/api/vault/tokenize from your serverThat's the full integration for an existing Stripe Billing setup. The brain starts watching your customer base immediately. You review its decisions in shadow mode before going live.
Yes. ZenoPay's webhook receiver accepts events from Stripe and Adyen natively. For other processors or home-built billing systems, you send events directly to the brain trigger endpoint at /api/agent/trigger using ZenoPay's event schema. The supported event types are: payment_failed, subscription_renewal, churn_score_breach, usage_threshold, upgrade_intent, manual_trigger, scheduled_analysis, and consent_received.
Your billing system translates its events into ZenoPay's schema and posts them. ZenoPay handles everything from there. The integration guide at /docs-quickstart covers this path.
15 rails across three categories:
All 14 adapters are written and deployed. Regional rails run in simulation mode until real processor credentials are supplied.
Before every charge, the router scores all approved rails against three weighted factors: approval rate (50% weight), processing cost (30%), and settlement speed (20%). It selects the highest-scoring rail and pre-ranks fallbacks.
The router also applies context-aware hints. GoCardless gets a +0.25 bonus for recurring billing — because at ~50bps vs ~290bps for card rails, routing recurring subscriptions through GoCardless is almost always correct. Checkout.com gets a bonus for high-value transactions where authorization rate optimization justifies the premium. Regional rails (UPI, PIX, M-Pesa) are boosted when the customer's context suggests the relevant market.
Performance data feeds back into scoring on a 7-day rolling window. If a rail's approval rate drops, the router learns and adjusts — no manual reconfiguration required.
The next-ranked rail fires automatically in the same request cycle. The customer never sees a failure screen. They never know a fallback occurred.
For subscription renewals, the dunning sequence also cascades across rails before escalating. A payment that Stripe declines on day 3 of dunning may succeed via GoCardless ACH on the same attempt. Every fallback and rail switch is logged with full reasoning in the audit log.
Yes. The approved_rails guardrail is a list you control. Add a rail by updating the guardrail config (which requires human approval, same as all guardrail changes) and supplying the processor credentials as environment variables. Remove a rail the same way — the router immediately stops scoring it and reroutes affected subscriptions.
Regional rails (UPI, PIX, M-Pesa, etc.) run in simulation mode until you supply real processor credentials. Simulation mode means the router scores them and would route to them — but the adapter returns a simulated success rather than making a real API call. You can test regional routing logic before going live with a new processor relationship.
A structurally independent guardrail engine. This is the core architectural choice that makes ZenoPay different from any other AI-augmented billing system.
The guardrail engine runs as a completely separate code path. It is not imported from the LLM inference layer. It cannot be called by the AI. It cannot be instructed, reasoned around, or overridden by any prompt or reasoning chain. Before any financial action executes, the guardrail engine validates it independently — regardless of what the AI decided.
Hard limits enforced by guardrails by default: max $500 single charge, max $2,000 daily ceiling, 85% minimum confidence to charge, 3 retries per 24 hours, consent required above $100. These can only be changed by humans, and the brain cannot propose removing them without your explicit approval.
Shadow mode is a safety mechanism for onboarding. When enabled — which is the default for all new tenants — the brain reasons through every decision and writes it to the audit log, but executes no real charges, rail switches, or subscription changes.
This lets you see exactly what the brain would have done for your specific customer base before any real money moves. You can verify the logic makes sense, check that rail scoring matches your expectations, confirm webhook events are arriving correctly, and then disable shadow mode only when you're confident the brain is reasoning the way you want.
Recommended shadow mode duration: 7–14 days. Shorter for businesses with high confidence in their customer data. Shadow mode transactions do not count toward the rail performance learning window — the router only learns from real execution results.
The brain has 16 tools it can invoke. The decisions it makes fall into five categories:
What the brain cannot do: change its own guardrails, exceed the configured charge limits, use unapproved rails, or execute any action without first writing a plain-English log entry explaining the decision.
ZenoPay uses Anthropic's Claude models, tiered by decision complexity. Routine decisions — dunning retries, subscription renewals, usage threshold checks, scheduled analysis — use Claude Haiku, which is fast and approximately 25x cheaper per token. Complex decisions — novel churn patterns, guardrail proposals, fraud escalations, self-improvement analysis — use Claude Opus.
The tiering is based on event type, applied automatically. Routine events: payment_failed, subscription_renewal, usage_threshold, scheduled_analysis. Complex events: churn_score_breach, upgrade_intent, manual_trigger, consent_received.
ZenoPay's patent-pending mechanism (Patent 1, April 3 2026 priority date) that enables a natural language utterance from a customer — "Yes, charge me" or "Go ahead with the payment" — to constitute legally sufficient payment authorization.
The mechanism stores only a SHA-256 hash of the utterance, never the original text. The consent is session-scoped and single-use — it cannot be replayed or reused. It expires in 30 minutes. An HMAC-signed authorization token is issued on validation. This is the infrastructure that agentic commerce protocols (Visa Intelligent Commerce, Mastercard Agent Pay, Stripe MPP) require to handle AI-agent-initiated payments in a legally compliant way.
No. All customer data is isolated by Row Level Security at the database layer. A tenant can only read and write their own records. No customer PII — names, emails, payment details, behavioral data — ever crosses tenant boundaries.
The one exception: the cross-tenant fraud signal network shares anonymized fraud signals (BIN prefix ranges, IP address ranges, device hash patterns) — never the customer identity behind them. A confirmed card-testing pattern from Tenant A becomes a detection signal for Tenant B without Tenant B ever knowing whose card it was.
ZenoPay never stores raw card numbers, CVVs, or any sensitive payment data. The vault stores processor tokens — references that your payment processor issues after collecting the card data through their own secure elements (Stripe.js, Braintree Drop-in, etc.). ZenoPay encrypts these processor tokens at rest using AES-256-GCM with a per-tenant encryption key.
Your customers' checkout experience is unchanged. Card data flows from the customer's browser directly to the processor through their secure collection mechanism. ZenoPay only receives the tokenized reference, which has no value outside of the processor's environment.
ZenoPay is an SAQ D environment internally — it stores, processes, and transmits payment tokens in encrypted form. However, connecting ZenoPay does not expand your PCI scope. Because ZenoPay uses processor-issued tokens rather than raw card data, and because card collection happens through the processor's secure elements, your application remains at SAQ A (the lowest scope level).
Full PCI DSS certification of ZenoPay itself is in the roadmap. If your compliance requirements need a certified PCI DSS provider today, contact us at derek@huit.ai to discuss your specific requirements.
Yes. The audit log table has SQL-level triggers that block all UPDATE and DELETE operations on committed records. The only operation allowed is INSERT. This is enforced at the database layer — not by application policy, but by the database itself refusing any modification attempts.
The core audit fields (reasoning, decision type, amount, customer) are immutable once written. Non-core fields (resolved_at, human review notes) can be updated by authorized humans only. This architecture makes the audit log suitable as evidence in compliance reviews, regulatory examinations, and insurance underwriter due diligence.
That's the right question. Here's the honest answer: ZenoPay is pre-revenue because it's pre-database. The platform is built — 12,874 lines of production code, 15 rails, 29 API routes, 27 database migrations ready to run. The only step remaining before first live transaction is connecting Supabase. That's a two-hour task, not a rebuild.
The Huit.AI product suite — APEX Platform and APEX Intelligence — bills through ZenoPay. So the platform is processing real business activity. We are our own first customer.
The honest risk: ZenoPay is an early-stage platform and you would be among the first external customers. In exchange, pricing is favorable and you get direct access to the founding team. If that risk is acceptable for the upside, we should talk.
ZenoPay uses a two-phase deployment model: build and activation. The build phase — all 12,874 lines of production code, 15 rails, 29 API routes, 27 database migrations, guardrail engine, and patent-pending agentic commerce adapters — is complete and deployed.
Activation connects the live database, runs the migration stack, and switches the platform from demonstration mode to full operational mode. This is a two-hour configuration step completed at the start of each customer onboarding. If you're evaluating ZenoPay and want to see the platform in fully operational mode, contact us and we'll activate it during your evaluation window.
Openly, yes. The V7 agentic commerce layer — native adapters for Visa Intelligent Commerce, Mastercard Agent Pay, Stripe MPP, and Google Universal Commerce Protocol, plus two patent-pending governance mechanisms with April 3 2026 priority dates — was built with a specific acquirer thesis in mind: a payment network, processor, bank, or enterprise platform that needs a governance layer for AI-initiated payments and doesn't want to spend 18 months building it internally.
ZenoPay is positioned as an acquisition target, not a standalone consumer of institutional capital. The acquirer brief is at zenopay.ai/agentic-commerce. Partnership and acquisition inquiries go to derek@huit.ai.
Three options depending on where you are: