Failed payments.
Clear follow-up.

RescueDunning brings branded follow-up, a customer work queue, optional retention choices and outcome evaluation into one workflow. Keep your existing Stripe retry policy and review overlapping reminders before enabling RescueDunning. A payment after a reminder may still come from Stripe retries or another action. The product does not promise higher recovery than your current setup.

Keep your native retry policy. Saving a card alone does not charge an invoice. Pay now is EARLY ACCESS. Disabled by default. Real Stripe test-mode validation is pending. Keep disabled for customers until that validation is complete. Its intended flow requests separate customer authorization after a verified card save in the same recent browser session. Authentication can continue on the verified hosted invoice. Uncertain results require status checks; they never trigger a blind repeat charge.

No. Pay now, retention offers, activity observation, decline-aware messages, prompt escalation, personal notes, holdout evaluation and digest delivery require their own setup or opt-in. Connecting Stripe or running the audit does not activate them. A saved setting is also distinct from a successful live payment or message delivery.

Create a free account and connect Stripe. The audit reads invoices from the last 90 days and reports failed payments, payments recorded after retries and outstanding balances. Stripe's Connect permission is read/write, but the audit only reads invoices: it does not charge customers, email them or start recovery. Historical observations do not show the additional effect of RescueDunning.

Pre-expiry alerts are available in early access for connected merchants with recovery access. Scanning is on unless the merchant disables pre-dunning; delivery still needs configured scheduling and email service. The nightly scan refreshes Stripe card data and uses 30-, 14- and 7-day windows. Late imports receive only the most urgent current window; missed windows are not backfilled. A failed Stripe refresh skips that scan. Reminders do not guarantee delivery or a successful future payment.

The basic Stripe connection uses OAuth and Connect events, with no merchant webhook to add. In-app prompts and activity observation need an integration inside your product: a signed server session, an account-bound customer identity and approved website origins. Your server must derive billing-admin permission from organization membership. Missing permission shows a contact-administrator message without invoice details or payment links. Activity events are a separate opt-in.

No. It is a stronger advisory reminder with an immediate Continue option and keyboard dismissal. It does not enforce product permissions. Billing, support, cancellation, export and account-recovery routes remain available. Missing, stale or ambiguous billing information leaves access available.

No. These offers are EARLY ACCESS. Disabled by default. Real Stripe test-mode validation is pending. Keep disabled for customers until that validation is complete. They also require merchant opt-in, an eligible provider configuration and a customer preview with explicit consent. The initial supported shape is one fixed monthly item at quantity one, without trials, tax, discounts or an existing schedule. Pause and skip void invoices generated during the stated window; existing debt remains collectible. A downgrade applies at renewal only after the exact schedule is verified. Unsupported combinations do not proceed.

It shows observed authenticated product use over the trailing seven days, with logins labeled separately. Your product must instrument meaningful actions; no observation may mean missing coverage, not inactivity. Current checked balances stay separated by currency. Product use is not proof that a customer intends to pay.

The opt-in evaluation assigns eligible customers prospectively and withholds measured Rescue interventions from controls while the baseline Stripe policy stays unchanged. It uses a fixed 30-day outcome horizon and reports mature and pending cases, uncertainty and integrity checks. Small samples can remain inconclusive. Changing settings, early stopping or contamination can invalidate a causal interpretation. An invoice payment is not the same as new cash, retained funds or profit.

No. Pooled analysis needs separate consent before the shared experiment and a separately enabled pooling service. Eligible participants contribute only to a fixed privacy-qualified aggregate; no merchant cells or customer records are exposed. The pooling service starts disabled, and a pooled estimate is not a promised return for your business.

Personal notes are plain-text drafts for you to review and copy into your own inbox. There is no inbox connection or automatic personal send. Weekly digests require separate email or Slack destination setup, destination verification, owner opt-in and enabled delivery service. Provider acceptance, confirmed delivery or posting, and a person reading a message are different outcomes.

The default sender uses RescueDunning's domain, with your logo and brand color and replies routed to your account email. A custom sender needs ownership checks and DNS verification. The Day 1/3/7 routine uses preset templates; optional decline-aware copy uses current invoice evidence and keeps sensitive bank reasons generic. The outbox separates provider acceptance from delivery evidence and does not prove human reading.

Eligible new accounts can start a 14-day trial after account and email verification. The checkout shows the current billing terms. The 90-day audit is separate and does not require a subscription.

You can request cancellation from your dashboard. Review the billing page for your subscription's cancellation status and remaining access. Canceling RescueDunning is separate from any pause or downgrade you offer your own customers.

Never. Card details are typed directly into Stripe's secure payment fields and go straight to Stripe — the full number never touches our servers, our database, or our logs. The only card-related data we keep is non-sensitive metadata from Stripe: card brand, last four digits, and expiry month/year, used to show which card is on file and to power pre-expiry alerts.

Recovery uses customer contact details, subscription and invoice state, card metadata and delivery records. Optional activity observation stores last-use and last-login timestamps plus hashed deduplication IDs, without URLs, IP addresses, device data or arbitrary event properties. Experiments, draft availability and digest delivery have their own audit records. Review the Privacy Policy and setup guide before opting in.

We work with third-party providers to run RescueDunning and share only the data needed to deliver the service. We don't sell personal data or share it for advertising. Our Privacy Policy explains the details.

In the United States on Google Cloud / Firebase infrastructure, encrypted in transit (TLS) and at rest. Access follows least-privilege principles and login credentials are stored in hashed form.

Account data is kept while your account is active and for up to 3 years after closure for tax, accounting, and legal purposes. Operational Stripe/dunning data is deleted or anonymized within 90 days of closure, unless retention is required by law. Encrypted backups are overwritten on the normal backup rotation cycle. You can request an export or deletion at any time by emailing privacy@rescuedunning.group from your account email address.

Depending on where you live, you can access, correct, delete, or export your personal data, and object to certain processing. We don't sell personal data. If you're one of our merchant's end customers, please contact the merchant directly about your data — we act on the merchant's verified instructions.