What's new on Rebounce

Until today, the only signal you got when your first recovered invoice landed was the in-app celebration modal. That meant you had to be in the dashboard to see it. Many trial users sign up, connect Stripe, and check back days later, missing the moment entirely.

From now on, the first time a failed payment flips to recovered for your org, you get a one-shot email summarizing the amount and the customer it came from, with a direct link to the dashboard. It only fires once per account.

When a Stripe Checkout session expires, Stripe only returns a recovery_url if you have enabled after_expiration.recovery on the session. Most orgs do not. The previous behavior was to silently skip the follow-up email in that case (sending a CTA-less message is worse than not sending one).

You can now configure a fallback URL in Dashboard → Checkout Recovery. When Stripe does not provide a per-session recovery link, that fallback gets used as the email's call to action. Leave it blank to keep the skip behavior.

When Stripe re-emits an invoice.payment_failed webhook (which it does on its own retry schedule, and in some race conditions), the original logic could occasionally create two active failed-payment rows for the same invoice. This caused duplicate dunning messages for one or two customers.

The ingest path now enforces a database-level constraint that allows at most one active failed-payment per (org, invoice) pair. Re-emitted events are detected and silently ignored. Historical duplicates were cleaned up at the same time.

Dunning SMS used to embed a 270+ character signed token directly in the URL. On routes that bill by segment, especially international SMS, this turned a single recovery message into multiple billed segments.

Each SMS now contains a short URL that resolves server-side to the same canonical payment update page. Same security model (the same JWT, same 72h expiry), much shorter on the wire. Customers see rebounce.dev/p/<7chars> instead of a token-shaped string.

Previously, customers with both a WhatsApp-eligible number and a phone number could receive two messages about the same failed invoice. Annoying for them and wasteful on cost.

The dunning worker now waits a short window after a WhatsApp send, then re-checks the message log. If a WhatsApp went out successfully, the SMS for the same payment is skipped. If no WhatsApp landed (number not on WhatsApp, opt-out, delivery failure), the SMS still fires. Reach is preserved; duplicates are not.

Launched a dedicated page for every Stripe decline code at /stripe-decline-code. 37 codes covered across soft declines, hard declines, authentication, and fraud categories.

For each code you get:

• What the code means, with plain English explanation
• Whether to retry, and if so, the optimal timing window
• The right customer message (and what words to avoid)
• Best practices and common mistakes
• Related codes and FAQs

Rebounce uses this same classification internally to decide how to handle each failure - but the reference is useful even if you are not a Rebounce customer.

Two new free tools, both public and no-signup:

• Churn Calculator: plug your MRR, failure rate, and average subscription price. See annual loss, Stripe Smart Retries recovery projection, and Rebounce recovery projection. Generates a shareable Twitter/LinkedIn preview card with your specific numbers.
• Dunning Template Library: 22 copy-paste templates spanning friendly first-touch through final notice, plus specialized variants for expired cards, insufficient funds, bank blocks, SCA/3DS, and more. Covers email, SMS (TCPA-compliant), and WhatsApp (Meta-approved patterns).

Each template page includes subject line variations, why-it-works rationale, implementation tips, and FAQs. Every page has copy-to-clipboard buttons so you can take the template into your own ESP in seconds.

When testing dunning sequences in the dashboard, you can now specify a recipient email address for the test messages instead of always using your own. Useful for previewing the flow as a customer would see it, or for QA across different inboxes.

Fixed a friction point where evaluating Rebounce in a Stripe sandbox required extra setup before you could test end-to-end. The install flow now works out of the box in sandbox, so you can try the full recovery flow before switching to live mode.

Re-reviewed every landing page section and every dashboard view on mobile. Touch targets, tap areas, form controls, and horizontal scrolling all cleaned up. The dashboard is now fully usable on a phone (including the Failed Payments table, settings, and channel toggles).

Three new blog posts covering:

• Dunning email templates that actually recover payments - 9 templates with subject line variants and decline-code-specific copy
• Stripe Account Updater explained - what it does, when it helps, and the gap you still need to fill
• How to reduce involuntary churn - a practical playbook for SaaS founders

Wired up Reddit Pixel (client-side) and Conversions API (server-side) so organic and paid Reddit traffic can be tracked through signup and trial activation. Dedup is handled via event IDs on both sides.

Added reusable channel toggle UI and a dashboard section for enabling or disabling each dunning channel per organization. Flip a channel off and Rebounce stops sending on it immediately.

Available in Settings → Dunning Channels, and as quick toggles in the Recovery Channels panel on the dashboard overview.

Added an exit-intent popup on all blog posts that links to the free Stripe audit tool. Also added inline audit CTAs mid-post and at the end of each post, with PostHog event tracking on every click so we can measure which posts convert best.

Shipped a new content cluster focused on payment provider selection:

• How to choose a payment provider for your SaaS
• Stripe vs Paddle for SaaS
• Stripe vs Lemon Squeezy vs Paddle

Plus dedicated /vs/ pages for each dunning tool alternative.