The exact permissions we ask for
You connect Stripe with a restricted API keythat you create in your own Stripe dashboard. Restricted keys are scoped by Stripe itself: the key can only ever do what you granted it, no matter what MRRdue's code tries. We ask for read access to five resources and nothing else:
| Stripe resource | Access |
|---|---|
| Customers | Read |
| Subscriptions | Read |
| Invoices | Read |
| Prices | Read |
| Products | Read |
| Everything else (charges, refunds, payouts, payment methods, portal sessions…) | None |
One optional exception, always opt-in: enabling expiring-card alerts requires adding read-only access to Payment Methods (card brand, last four digits, and expiry month — never full numbers, which Stripe exposes to no one). If you never enable that alert, the scope is never needed.
What MRRdue cannot do — enforced by Stripe, not by us
Because the key has no write permission, the following are not policy promises. They are API-level facts: Stripe rejects the request before our code runs.
- Charge, refund, or move money
- Create, modify, or cancel subscriptions
- Retry failed payments
- Create Customer Portal or payment-update sessions
- Email or contact your customers directly
- See card numbers or CVCs (Stripe never exposes these to anyone)
We reject secret keys at the door
If you paste a full secret key (sk_…) instead of a restricted key, MRRdue's server refuses it. The connect endpoint only accepts keys in the restricted format (rk_…), so an over-powered credential is never accepted, stored, or used — even by mistake.
We verify your key is read-only — and warn you if it isn't
At connection time, MRRdue runs a write-probe against a customer ID that cannot exist. If Stripe rejects it on permissions, your key is provably read-only and your dashboard shows a Verified read-only badge. If Stripe would have accepted the write, we warn you that the key is over-permissioned and show you how to narrow it. Either way, nothing can be mutated by the probe — the target does not exist.
How your key is stored
- Encrypted at rest with AES-256-GCM using a server-side encryption key that is separate from the database.
- Used only on the server. The key is never sent to browser JavaScript and never appears in logs; the dashboard shows only the last four characters.
- Webhook payloads are signature-verified, and each workspace gets its own unguessable webhook endpoint.
Audit everything we read
Stripe logs restricted-key requests separately in your own dashboard (Developers → Logs, filtered by the key). You never have to take our word for what MRRdue accessed — the authoritative record lives in your Stripe account, outside our control.
Revoke access in seconds
- Delete (or roll) the restricted key in your Stripe dashboard — MRRdue loses access instantly, without contacting us.
- Or disconnect from MRRdue's settings page, which deletes the stored key immediately. You can also choose to delete all imported Stripe data at the same time.
Data retention and deletion
Imported billing metadata (customers, subscriptions, invoices, failure reasons) exists so your recovery queue and reports work. Disconnecting Stripe offers a full delete of imported data. Expired and canceled workspaces are retained for 30 days so you can reactivate, then cleaned up. You can request complete account deletion at any time — see the privacy policy for details.
Your Stripe account is never used to bill you
MRRdue's own subscription is billed through Dodo Payments, completely separate from your connected Stripe account. The read-only key you provide is used for recovery signals only.
Reporting a vulnerability
If you believe you have found a security issue, email us and we will respond promptly. Please do not test against workspaces you do not own.