How Lirova handles your Stripe access
We recover revenue from failed payments — which means we need write access to retry them. Here's exactly what that access is, and the five ways it's locked down.
We never hold a usable key
You don't hand us a Stripe key. You authorize Lirova through Stripe's “Sign in with Stripe” (OAuth), and Stripe delegates access to us. We store the resulting access token encrypted with AES-256-GCM.
The token is never decrypted into a usable form in our application flow — all Stripe calls are made through the platform credential. A leak of our database rows does not yield a working token.
Account calls are authenticated through the platform using your account reference — the stored token isn't used for day-to-day recovery calls.
Read-only by default. Money moves only after you activate.
Connecting your Stripe does not move any money. A new connection is read-only by default — we read subscription and invoice data to surface your at-risk revenue, and nothing else. Write access becomes possible only when you explicitly activate recovery. Until then, the connection can show you what's failing, but cannot act on it.
Write is gated at the worker, not the UI
When recovery is active, every money-moving call passes through an internal write-gate that checks the account is active — at the worker level, not just in the interface. A payment retry cannot be triggered by a stray request or a UI bug; the gate lives where the money actually moves.
We physically cannot double-charge
Every retry carries a deterministic idempotency key. If the same retry is ever delivered twice, Stripe rejects the duplicate — a customer cannot be charged twice for the same recovery. And we don't retry what shouldn't be retried: lost, stolen, and fraudulent declines are stopped outright — zero retries — because retrying a hard fraud decline only flags the account with the issuer.
You revoke access from your side, anytime
You can revoke Lirova's access from your own Stripe dashboard at any time. It's your account and your decision — the authorization is delegated, not owned by us.