RecoverTrust
Security
Last updated 28 July 2026
You are being asked to connect the system that takes your money. That deserves a straight account of how the connection works, what we can and cannot reach, and what protections we do not yet have. This page includes the last part, which most security pages leave out.
How the connection works
- RecoverFlow connects through Stripe Connect OAuth. You authorise it from Stripe's own screen, not from a form we wrote.
- We never ask for, and never receive, your Stripe API keys.
- The access token we do receive is encrypted at rest in our database.
- You can revoke it in one click from your Stripe dashboard, at any time, without contacting us. That immediately ends our ability to read or act on your account.
What we never see
Card numbers, CVCs, expiry dates and bank details never reach our servers. Stripe holds all of it and performs every charge.
When a customer updates their card through a link in a recovery email, the form is built on Stripe's own hosted card elements. The card details go from the customer straight to Stripe. We receive only a reference to the new payment method, never the card itself.
This is why RecoverFlow falls under the lightest PCI scope, SAQ A. Not because we built clever infrastructure, but because we deliberately never touch the data in the first place.
We also never store passwords. Signing in uses a one-time link to your email address, so there is no password database to breach.
How your data is separated from everyone else's
- Every query against merchant data is scoped to a single merchant at the database layer, using query filters applied globally rather than remembered case by case. This is the protection that stops one merchant's data ever appearing in another's dashboard, and it is enforced in one place rather than trusted to every individual query.
- Background jobs that legitimately run across all merchants, such as monthly billing, filter explicitly by merchant and are written to be safe to re-run.
Infrastructure
- Hosted on Render, in a United States region, with a managed PostgreSQL database.
- All traffic is over HTTPS. The marketing site, the API and the application all redirect plain HTTP to HTTPS.
- Database encryption at rest is provided by the managed database.
- Secrets are held as environment variables, not in the source code. The repository is public and contains no credentials.
- Session and token-signing keys are persisted on a mounted disk so that a redeploy does not silently invalidate your session or your sign-in links.
Billing safety
The billing path is the place where a bug costs you real money, so it is written defensively. Before any charge is created, the invoice record and the specific recovery cases it covers are written in a single atomic database transaction. If the process crashes at any point after that, the next run resumes that exact invoice rather than billing the same recoveries twice.
Fees are calculated in integer cents and rounded down, so rounding always favours you.
What we do not have
Being straight about the gaps, because you will find them out eventually anyway and it is better you hear it here.
No SOC 2. Not Type I, not Type II. It is a months-long process and RecoverFlow launched in July 2026. If your procurement requires SOC 2, we do not meet your bar today and you should not buy.
No third-party penetration test has been carried out yet.
No ISO 27001, and no other formal certification.
No SSO or SCIM, and no bug bounty programme.
No 24/7 on-call. There is one person. Serious problems get attention quickly, but not instantly at 4am.
These are all on the roadmap. None of them are done. When any of them changes, this page changes with it and the date at the top will move.
Reporting a vulnerability
If you find a security problem, email admin@recoverflow.org with enough detail to reproduce it. It goes straight to Bruce.
There is no cash bounty, because there is no revenue to fund one yet. What you will get is a fast, non-defensive response, a fix, and public credit if you want it. Please give a reasonable window before disclosing publicly.
Related
The full list of sub-processors and exactly what data each one touches is in the privacy policy. What we store, down to the field, is in section 2 of the same document.