Security
Last updated 26 July 2026
Connecting RetryPilot means giving a third party write access to your billing. That deserves specifics rather than a badge wall — including an honest list of what is not in place yet.
The Stripe connection
RetryPilot uses standard Stripe Connect OAuth with read_write scope. Write access is not optional for this product: retrying an invoice and attaching a replacement card are both write operations. A read-only token can report on the problem but cannot fix it.
What we actually call
- Invoices — list, retrieve, and pay (the retry itself)
- Subscriptions and customers — retrieve, to link a failure to a subscriber
- Setup intents — create, so a customer can save a new card
- Charges and payment intents — retrieve, to read the decline reason
What we never do
- Create payouts or move money to any account other than yours
- Create, modify or delete your products, prices or coupons
- Issue refunds or cancel subscriptions
- Read anything outside the billing surface listed above
Revoking is immediate and entirely on your side: Stripe Dashboard → Settings → Connected applications → revoke. Every RetryPilot call stops working the moment you do, and we mark the connection revoked when Stripe tells us.
Card data
RetryPilot never receives a card number. The hosted card-update page mounts Stripe Elements in an iframe served by Stripe, so the card details your customer types are posted from their browser straight to Stripe. Our servers see only the resulting Stripe payment-method ID.
This is why we can operate without being in PCI-DSS scope beyond SAQ-A, and it is the single most important design decision in the product.
How credentials are stored
| Secret | Protection |
|---|---|
| Your Stripe OAuth token | Encrypted before insert using Fernet (AES-128-CBC with HMAC-SHA256 authentication), under a 32-byte key held only in the server environment and never in the database or the repository. |
| Your password | Argon2 hash. Login verification runs the full hash cost whether or not the account exists, so response timing does not reveal which emails are registered. |
| Session cookie | Signed, and set HttpOnly, Secure and SameSite=Lax. Changing your password invalidates every existing session. |
| Card-update links | 288 bits of cryptographic randomness, single-purpose, scoped to one invoice, and expiring after 30 days. Not guessable and not enumerable. |
Webhooks
Every inbound Stripe webhook is verified against its signing secret before anything is read from it, and each event ID is recorded so a replayed event cannot cause a second retry or a duplicate email. Platform events (our own billing) and Connect events (your account) are verified against separate secrets.
Tenant isolation
Every query is scoped to the workspace of the authenticated user. Guessing another workspace's identifier returns a 404 — it does not confirm that the workspace exists.
Infrastructure
- Servers and database in the European Union (Hetzner).
- TLS on every public endpoint; the API is not reachable except over HTTPS.
- Database and worker are on a private network; only the web and API ports are exposed publicly.
- The app refuses to start with a placeholder or weak session secret or encryption key — a misconfigured deploy fails loudly rather than running insecurely.
What is not in place yet
RetryPilot is early-stage and run by a small team. Rather than imply otherwise:
- No SOC 2 or ISO 27001 certification. Neither is in progress. If your procurement process requires one, we are not the right fit yet.
- No third-party penetration test has been carried out.
- No two-factor authentication on RetryPilot accounts yet. Use a unique, strong password until it ships.
- No published uptime SLA. Recovery is asynchronous, so a short outage delays retries rather than losing them — but we are not promising a number we cannot yet measure.
These are listed here because you are about to make a trust decision, and finding out later would be worse than knowing now.
Reporting a vulnerability
Email security@retrypilot.com with steps to reproduce. We aim to acknowledge within two working days. We will not pursue legal action against good-faith research that avoids accessing other customers' data, degrading the service, or exfiltrating information.