Engineered for absolute security.

Subscription businesses live and die by billing integrity. A compromised checkout flow or a bug in a cancellation script can cause catastrophic revenue leakage or customer trust loss.

Revora is engineered around a Zero-Trust Billing Perimeter. We isolate client UI widgets inside open Shadow DOM roots, decouple billing keys using strong cryptography, and guarantee that payment operations are handled directly on your verified Stripe account.

When you link your Stripe account via Stripe Connect OAuth, Revora never takes custody of your payout balances, bank routing numbers, or primary customer credit cards.

• OAuth Scoped Access: We request only the permissions necessary to manage subscription items, create discount coupons, and pause collection (read_write).
• No Frontend Key Exposure: Your Stripe secret keys never touch client browsers. The browser only holds a public publishable key (pk_live_revora_...) used exclusively to initialize safe session tickets.
• Revocable at any time: Disconnecting Stripe Connect from your Stripe dashboard immediately invalidates Revora's access token — no support ticket required.

All merchant Stripe access tokens are encrypted at rest inside our PostgreSQL database using authenticated AES-256-GCM encryption with scrypt key derivation (lib/revora/encryption.ts).

The master decryption key lives exclusively in secure server-side environment variables (REVORA_ENCRYPTION_KEY) and is inaccessible to client-side runtimes or third-party scripts. The key is enforced at a strict 32+ character minimum at boot time — the application fails to start rather than run with a weak or missing key.

Why GCM specifically: unlike plain AES-CBC, GCM is an authenticated encryption mode — it detects if ciphertext has been tampered with in storage, rather than silently decrypting corrupted or altered data into a usable (and dangerous) token.

Network timeouts or frantic double-clicks can cause duplicate API submissions. Revora eliminates this risk through server-enforced idempotency keys — never trusting the client to prevent a repeat request.

Every discount application or billing pause generated during an offboarding session carries a unique, deterministic idempotency key, generated server-side in lib/revora/stripe-operations.ts. If a request is retried due to a dropped connection, Stripe safely recognizes the key and prevents duplicate coupon generation or overlapping pause schedules.

Our error classifier (lib/revora/stripe-errors.ts) distinguishes between definitive card/request failures (surfaced to the customer) and ambiguous network drops (safely retried server-side), so a flaky connection never results in a subscriber being charged twice or granted two concurrent concessions.

Regulatory bodies heavily penalize subscription apps that use “dark patterns” (e.g., hiding cancel buttons behind chat bots or forcing phone calls). Revora provides built-in legal defense:

• Equal Ease Architecture: Declining an offer and continuing to cancel is a single, direct, unhindered click — never more steps than subscribing required.
• Statutory Confirmation Receipts: Automatically dispatches verifiable written receipts to the subscriber's email for both retained concession terms and confirmed terminations.
• No Artificial Delay: Revora never introduces waiting periods, retry walls, or mandatory support contact as a condition of completing cancellation.

Revora runs on top-tier cloud architecture (Vercel Edge Network and Supabase PostgreSQL).

All database tables storing session logs and analytics (revora_sessions, revora_merchants) are strictly isolated by organization ID, enforced at the database layer via PostgreSQL Row Level Security — not application-layer filtering alone. Tenant data cannot cross boundaries, and raw export files (CSV) neutralize spreadsheet formula injection before leaving our servers.

Client-facing widget sessions are bound to cryptographic, non-enumerable session tokens with a strict 30-minute expiration window, preventing an attacker from guessing or iterating through active session IDs.

Revora is an early-stage product. We have not yet completed a third-party SOC 2 or ISO 27001 audit, and we won't claim one we don't hold. What we can tell you plainly: every control described on this page reflects our actual production code, not aspirational architecture.

A full internal security audit log — covering secret management, data flow, IDOR testing, and payment logic review — is available on request for any merchant evaluating Revora for production use. Contact us below and we'll share it directly.