VibeWeek
Home/Grow/Dunning & Failed Payments: Recover Revenue Without Churning Customers

Dunning & Failed Payments: Recover Revenue Without Churning Customers

⬅️ Growth Overview

Dunning Strategy for Your New SaaS

Goal: Ship a dunning flow that recovers 60-80% of failed payments — through smart retries, customer-friendly emails, in-product reminders, and graceful access transitions — without firing churn or reputation hits. Use Stripe Smart Retries (or equivalent) as the foundation, layer custom emails for tier-specific messaging, expose the failed-payment state in-product, and have a clear access-degradation policy. Avoid the failure modes where founders silently let subscriptions cancel (10-30% involuntary churn evaporates revenue), build aggressive retry loops that re-charge cards already declined for "insufficient funds" (annoying), or surprise customers with sudden access loss (terrible NPS hit).

Process: Follow this chat pattern with your AI coding tool such as Claude or v0.app. Pay attention to the notes in [brackets] and replace the bracketed text with your own content.

Timeframe: Stripe Smart Retries + basic dunning emails shipped in 2-3 days. In-product banner + tier-specific messaging in week 1. Self-serve update flow + analytics in week 2. Quarterly review baked in.

Why Most Founder Dunning Is Broken

Three failure modes hit founders the same way:

  • No dunning at all. Founder ships subscriptions; doesn''t configure retry / email logic. A customer''s card fails; subscription cancels silently within 7 days; the customer doesn''t know; founder loses 100% of that customer''s LTV. Multiply by 1-3% of customers per month with card failures = 12-36% annual involuntary churn for nothing.
  • Aggressive same-day retries. Founder writes a cron that retries failed cards every 6 hours. Card declined for "insufficient funds" gets retried 4x in 24 hours; bank flags account; legitimate transactions also fail; customer escalates support.
  • Generic "your payment failed" emails. Same email goes to free-trial-converting customers, mid-paid customers, and 5-year enterprise accounts. Tone is wrong; CTAs miss; recovery rate suffers.

The version that works is structured: smart retries (with backoff aligned to bank-decline reasons), tier-specific emails, in-product visibility, self-serve update flow, and a graceful access-degradation policy.

This guide assumes you have already done Trial-to-Paid (the conversion flow), have shipped Refunds & Chargebacks (related billing topic), and have a payment provider (Stripe, Polar, Paddle, Lemon Squeezy) with subscription billing configured.

1. Understand Why Payments Actually Fail

Different decline reasons need different responses. One-size-fits-all dunning misses recovery.

Help me categorize the decline reasons.

The decline reasons (Stripe ~similar across providers):

**Recoverable with retry** (60-70% of total):
- `insufficient_funds`: card has temp low balance; retries in 3-5 days often succeed
- `processor_declined`: bank-side soft decline; retry sometimes works
- `try_again_later`: explicit retry hint
- `processing_error`: temporary system issue

**Recoverable with customer action** (20-30%):
- `expired_card`: customer needs to update card
- `incorrect_cvc`: customer mistyped; needs re-entry
- `card_velocity_exceeded`: bank rate limit; customer needs to contact bank
- `do_not_honor`: bank refused; customer needs to call bank

**Not recoverable (or rarely)** (5-10%):
- `lost_card`, `stolen_card`: cardholder reported card lost/stolen
- `fraudulent`: bank flagged transaction as fraud
- `restricted_card`: card permanently blocked

**Strategic implications**:

- For recoverable-with-retry: smart retry on schedule (Stripe handles this)
- For recoverable-with-customer-action: prompt customer immediately
- For not-recoverable: don''t retry; ask for new payment method

**The bank-soft-vs-hard decline distinction**:

- Soft decline (`insufficient_funds`, `processing_error`): retry usually succeeds
- Hard decline (`do_not_honor`, `fraudulent`): retry won''t help
- Smart retry tools differentiate

**Track per-failure-reason recovery rate**:

- After 90 days, measure: of customers with reason X, what % recovered?
- Inform retry strategy
- Customers with `insufficient_funds`: often recover (delay retry 3-5 days)
- Customers with `do_not_honor`: rarely recover via retry; ask for new method immediately

For my product:
- What payment provider am I on?
- Do I see decline-reason breakdown in their dashboard?
- What''s my baseline recovery rate?

Output:
1. The current recovery rate (if known)
2. The decline-reason breakdown
3. The retry strategy per reason
4. The KPI to track per cohort

The biggest unforced error: treating all declines the same. A do_not_honor declined card retried 4 times in a week makes the customer angry; a different communication strategy (immediate "please update payment") works better. Per-reason logic recovers more revenue.

2. Use Smart Retries

Stripe Smart Retries (or your provider''s equivalent) is the lowest-effort highest-recovery action. Enable it.

Configure Smart Retries.

The pattern:

**Stripe Smart Retries** (called "Recovery" in Stripe):

- Stripe automatically retries failed payments on optimal days
- Uses ML on millions of transactions to predict best retry time
- Per-customer adaptive (not naive cron)
- Requires "Recovery" enabled in Stripe Dashboard

**Why it''s better than manual retries**:

- Bank patterns: payments retry better Monday vs Friday for some reasons
- Cardholder patterns: Pay-day-aligned retries succeed more
- Avoids over-retrying (which would damage your processor reputation)
- Adapts per cardholder over time

**Configure in Stripe**:

1. Stripe Dashboard → Billing → Recover failed payments
2. Enable Smart Retries
3. Configure max retry duration (typical: 30 days)
4. Configure email reminders (Stripe-managed or external)

**Equivalent in other providers**:

- **Paddle**: built into Paddle Billing
- **Polar**: similar built-in retry
- **Lago / Orb / Chargebee / Recurly**: configurable retry schedules
- **Custom DIY**: don''t. The ML behind Smart Retries is hard to replicate.

**Critical implementation rules**:

1. **Don''t add custom retry logic on top.** It conflicts with Smart Retries.
2. **Disable any cron-based retry your previous system had.**
3. **Trust the ML.** Don''t override "this customer will recover" decisions.

**For B2C / consumer**:

- Higher card-failure rates
- Stripe Smart Retries especially valuable (4-7% recovery improvement)

**For B2B**:

- Lower card-failure rates (most B2B uses ACH or invoicing)
- Smart Retries still helps for credit-card B2B

**Don''t**:
- Skip configuring it (default may be off depending on Stripe account age)
- Layer your own retries on top
- Set retry duration too long (>30 days = annoying customer)

Output:
1. The Smart Retry config in your provider
2. The retry duration
3. The "stop retrying after" trigger
4. The metric to monitor (retry success rate)

The biggest single revenue-recovery lift: enabling Stripe Smart Retries (or equivalent). It''s a checkbox; it recovers 5-15% of would-be churn; it requires zero engineering. Skip the DIY retry logic.

3. Send Customer-Friendly Emails

Auto-emails from Stripe are OK; custom branded emails recover more. Build them right.

Design the dunning email sequence.

The pattern (5-touch sequence over 30 days):

**Touch 1: Day 0 (immediate after first failure)**

Subject: Payment issue with your [Product] subscription

Body:
> Hi [Name],
>
> We tried to process your subscription payment for [Product] today and it didn''t go through. This often happens because:
>
> - Card expired or was replaced
> - Bank declined for a temporary reason
> - Updated card needs to be entered
>
> No action needed yet — we''ll automatically retry over the next few days. If you''d like to update your payment method now, you can do so here: [link to billing portal]
>
> Questions? Reply to this email.
>
> [Founder name]

Tone: helpful, not panicked. Don''t threaten access yet.

**Touch 2: Day 4 (after second retry attempt fails)**

Subject: Quick action needed: Update [Product] payment method

Body:
> Hi [Name],
>
> Our automated retry attempts haven''t succeeded. Your subscription is still active, but to avoid interruption, please update your payment method here: [link]
>
> Most common fix: card expired. Takes 30 seconds.
>
> Reply if you need help.

Tone: proactive, action-oriented.

**Touch 3: Day 10 (if still unresolved)**

Subject: Action required to keep [Product] active

Body:
> Hi [Name],
>
> Just a heads-up — without an updated payment method, your [Product] subscription will downgrade to limited access on [date].
>
> Update card: [link]
>
> If you''d like to cancel instead, we get it: [cancel link]. No hard feelings.

Tone: clear consequence, with respectful cancel option.

**Touch 4: Day 20 (final warning)**

Subject: [Product] access will be limited tomorrow

Body:
> Hi [Name],
>
> This is the last reminder before tomorrow''s scheduled downgrade. To keep full access, update your payment: [link].
>
> Or, cancel cleanly here: [cancel link].

Tone: factual, last call.

**Touch 5: Day 30 (post-downgrade)**

Subject: Your [Product] is in limited mode

Body:
> Hi [Name],
>
> Your subscription is now in limited mode. Your data is preserved — restore full access anytime: [link].
>
> If [Product] isn''t the right fit for you anymore, we''d love to hear why: [feedback form].

Tone: door-still-open; data-still-yours.

**Critical implementation rules**:

1. **Personalize**: customer name, plan name, amount
2. **Friendly tone first; firm tone later**: don''t lead with threats
3. **One CTA per email**: don''t fragment attention
4. **Cancel option visible**: counterintuitively, this builds trust and reduces churn anger
5. **Reply-able from a real person**: not a noreply@ address
6. **Mobile-first design**: most emails opened on mobile

**Tier-specific variants**:

- For enterprise / annual customers: add "your account manager will reach out" — assign manually
- For free-trial-just-converted: extra context ("you just signed up — let''s sort this out")
- For longtime customers: warmer ("you''ve been with us 3 years")

**Tools for the emails**:

- Stripe-hosted emails (basic, easy)
- Custom emails via [email providers](https://www.vibereference.com/backend-and-data/email-providers) (Resend, Postmark, Loops)
- Lifecycle tools like Loops or Customer.io can drive these

**Don''t**:
- Send 8 emails in 30 days (becomes spam)
- Hide the cancel option (creates resentment)
- Use "FINAL NOTICE" / aggressive subject lines (kills brand trust)

Output:
1. The 5-email sequence drafted
2. The tier variants
3. The tool / mechanism for sending
4. The unsubscribe / off-ramp

The single biggest recovery lever in emails: the cancel option. Counterintuitively, prominently offering "cancel cleanly here" reduces angry chargebacks AND signals respect — which sometimes converts the wavering customer into a renewal. Hiding the cancel option backfires.

4. Surface Failed-Payment State In-Product

Email gets ignored. In-product banners get attention.

Design the in-product UX.

The pattern:

**On every page when payment is in failed state**:

A non-dismissable (but minimizable) banner at top of the app:
- Yellow/orange (warning, not red/error yet)
- Text: "Payment issue — your subscription will downgrade in [N] days"
- CTA: "Update payment method"
- Secondary: "Manage billing" link

**Severity progression**:

- Days 1-7: yellow warning banner
- Days 8-14: orange banner (more prominent)
- Day 15+: red banner; some features start to disable
- Day 30+: full downgrade; banner shifts to "restore access"

**The "downgrade page"**:

When the subscription is downgraded:
- Hide premium features (don''t error on them; show "upgrade to access")
- Preserve all data
- Allow read-only access to existing content
- Block create / edit on premium features

**Per [tier]**:

- Free → no change (user wasn''t paying anyway)
- Pro → limited Pro (read-only premium features)
- Enterprise → don''t auto-downgrade; assign account manager

**Update payment flow** (per [Stripe Customer Portal](https://www.vibereference.com/auth-and-payments/stripe-customer-portal)):

- One-click from the banner to a hosted payment-update page
- Stripe Customer Portal handles this nicely
- Mobile-friendly
- Returns user back to the app with success state

**Critical implementation rules**:

1. **Don''t trap user in modal.** They might be mid-task; let them dismiss the banner temporarily.
2. **Save state during update.** User clicks "update payment"; they fill in card; come back to where they were.
3. **Confirm immediately on success.** Banner disappears; "subscription restored" toast; they continue work.
4. **Don''t block legitimate work.** Even in failed state, allow read-only / data-export.

**Don''t**:
- Show "your account is suspended" (overly punitive)
- Hide payment status (customers want to know)
- Skip the in-product layer (email alone misses 60% of customers)

Output:
1. The banner component
2. The severity progression
3. The downgraded-feature behavior
4. The update-payment flow

The biggest recovery channel beyond email: the in-product banner. Email open rates are 30-40%; in-product banner views are 90%+ for active users. Customers who ignore email engage with the banner.

5. Make Update Self-Serve

Customers who have to email support to update their card take 4× longer to recover. Self-serve everything.

Design the self-serve update flow.

The pattern:

**Stripe Customer Portal** (or equivalent):

- Stripe-hosted page where customers manage:
  - Update payment method
  - View invoices
  - Update billing email
  - Update billing address
  - Cancel subscription
- Configurable in Stripe Dashboard
- Customer authenticated via magic link or session token

**Implementation (Stripe)**:

```ts
// Server: generate portal session
const session = await stripe.billingPortal.sessions.create({
  customer: customerId,
  return_url: `${appUrl}/billing/done`,
})
res.json({ url: session.url })

// Client: redirect to portal
async function openBillingPortal() {
  const res = await fetch('/api/billing/portal', { method: 'POST' })
  const { url } = await res.json()
  window.location.href = url
}

Customer goes to Stripe; updates card; comes back to your app.

Per tier customization:

  • Free / individual tiers: full portal access
  • Team plans: only billing admins see the portal
  • Enterprise: contact account manager (don''t expose portal)

Beyond payment update, the portal supports:

  • Plan changes (upgrade / downgrade)
  • Cancel subscription (with optional cancel-survey)
  • Invoice download
  • Tax-ID / VAT updates

Critical implementation rules:

  1. Use the hosted portal. Don''t build your own card-collection form (PCI compliance).
  2. Restrict to billing admins. Per RBAC: not every user should manage billing.
  3. Audit billing changes. Per Audit Logs.

For non-Stripe providers:

  • Paddle: similar customer portal
  • Polar: customer portal supported
  • Custom-billed: build a billing-management page (carefully)

Don''t:

  • Build custom card-collection (PCI scope explodes)
  • Hide the portal (defeats the point)
  • Skip the audit trail

Output:

  1. The portal-session endpoint
  2. The "open portal" UX
  3. The permission gating
  4. The audit integration

The single biggest recovery acceleration: **a one-click "update payment" link from email or banner.** Customer clicks; lands in portal pre-authenticated; updates card; done in 60 seconds. Without this, recovery rate drops dramatically.

---

## 6. Decide on Access Degradation

When a customer''s payment fails for 30 days, what happens? Plan it.

Design the access-degradation policy.

The patterns:

Pattern A: Hard cutoff

  • Day 30: subscription marked cancelled
  • Customer locked out completely
  • Data preserved for X days then deleted

Pros: clean Cons: brutal UX; lost LTV; high CSAT hit

Pattern B: Soft downgrade

  • Day 30: subscription marked "past due"
  • Account moves to free tier (or "limited" tier)
  • Premium features hidden / disabled
  • Data preserved indefinitely
  • Customer can restore by updating payment

Pros: customer-friendly; recovery still possible Cons: free-tier abuse risk

Pattern C: Read-only mode

  • Day 30: account becomes read-only
  • All data accessible but no creates / edits / API
  • Cancel-friendly (customer can export data)

Pros: respects customer; lowest churn signal Cons: requires more product work

For most indie SaaS in 2026: Pattern B (soft downgrade).

The downgrade decision matrix:

Tier Downgrade Action When
Free trial Convert to free tier Trial end (no payment)
Free user (paid via subscription? no) N/A N/A
Pro paid Move to free tier; preserve data Day 30 of failed payment
Business paid Move to read-only Pro tier Day 30
Enterprise paid Don''t auto-downgrade; manual handling Day 60+

Communication during downgrade:

  • Email: "Your subscription has been downgraded; restore by updating payment"
  • In-product: persistent banner with "restore access" CTA
  • Don''t auto-delete data
  • Maintain ability to cancel-cleanly

Restoration flow:

When customer updates payment:

  • Charge for the prorated amount immediately
  • Restore tier to previous level
  • Welcome-back email
  • Toast: "Subscription restored"

Critical implementation rules:

  1. Document the policy publicly. Per terms of service.
  2. Honor cancel-during-failure. A customer who wants to cancel during the dunning window should be able to without paying.
  3. Don''t delete data within reason. GDPR / account-deletion-data-export timeframes apply.

Don''t:

  • Lock customers out of their own data
  • Charge a "reactivation fee" (kills good will)
  • Send to collections (only for enterprise; never for SMB)

Output:

  1. The chosen pattern
  2. The per-tier behavior
  3. The restoration flow
  4. The data-retention policy during downgrade

The biggest churn-reduction lever: **soft downgrade (Pattern B) instead of hard cutoff.** A customer who can come back in 60 days and restore vs one who has to start over from scratch — the first churns at 30%; the second at 70%. The math wins on customer-friendly defaults.

---

## 7. Avoid Common Dunning Failures

Standard mistakes that destroy dunning effectiveness.

The common failures.

Failure 1: Same email to all tiers

  • Free-trial-converting customer gets the same email as 3-year enterprise
  • Fix: tier-specific copy and tone

Failure 2: Too many retries; bank flags account

  • Aggressive retry causes "card velocity exceeded"
  • Cardholder''s legit transactions also fail
  • Fix: trust Smart Retries; don''t add custom

Failure 3: Hidden cancel option

  • "We''ll keep trying for 30 days" but no cancel
  • Customer files chargeback to "make it stop"
  • Chargeback fee + lost revenue
  • Fix: prominent cancel option in every email

Failure 4: Surprise data loss

  • Customer''s data deleted at day 31; customer didn''t know
  • Lawsuit / Twitter rage incoming
  • Fix: data preserved per published policy

Failure 5: Generic "update card" messaging

  • "Update your payment method" — but customer may have been reissued
  • Specific guidance: "if your card expired, update; if your bank flagged, contact them"
  • Fix: per-decline-reason messaging

Failure 6: Localization gaps

  • English emails to non-English customers
  • Currency mismatches in messaging
  • Fix: localize per customer locale

Failure 7: Mobile-broken flows

  • Email link goes to desktop-only billing portal
  • Customer on phone gives up
  • Fix: mobile-first portal

Failure 8: No human escalation for enterprise

  • Big customer''s card fails; gets generic email
  • Manager rotates to next vendor
  • Fix: alert account manager for high-LTV failures; manual intervention

Failure 9: Failure to track recovery rate

  • Don''t know what''s working; can''t improve
  • Fix: per-touchpoint recovery metrics

Failure 10: Reactivation fees / re-onboarding pain

  • Customer comes back; finds added fees or repeated onboarding
  • Fix: smooth restoration; no penalty

Output:

  1. Audit current dunning for each failure
  2. Fixes per failure
  3. Priority ranking

The biggest churn predictor: **whether customers can restore their account quickly when they come back.** A 30-second card-update + immediate restore predicts 60%+ recovery. A 5-step onboarding-from-scratch predicts <10%. The friction at restoration time matters more than the dunning sequence itself.

---

## 8. Track Recovery Metrics

Without measurement, dunning is opaque. Track everything.

Design dunning metrics.

The metrics:

Recovery rates (per cohort):

  • % recovered within 7 days
  • % recovered within 30 days
  • % recovered ever
  • Compare across decline reasons

Email engagement:

  • Open rate per touchpoint
  • Click-through rate per touchpoint (to update flow)
  • Unsubscribe rate (canary for spam)

Funnel:

  • Failed payment → email opened → CTA clicked → portal accessed → card updated → restored
  • Where''s the drop-off?

Financial:

  • Total ARR lost to involuntary churn (per quarter)
  • Total ARR recovered via dunning (per quarter)
  • Recovery rate (recovered / failed)
  • Industry benchmark: 60-80% recovery (anything below 50% means dunning is broken)

Per-segment:

  • New customers vs returning
  • Free-trial-conversion vs longtime
  • By tier (Pro / Business / Enterprise)
  • By decline reason

Tools:

  • Stripe Sigma / Stripe Reports for SQL on Stripe data
  • Or pipe Stripe events to your data warehouse
  • Visualize in Mode / Hex / Looker

Dashboards to build:

  • Weekly recovery rate trend
  • Per-decline-reason recovery
  • Email-touchpoint engagement
  • Top customers in failed state (alert)

Alerts:

  • Recovery rate drops 10% week-over-week
  • Total failed-payment volume spikes
  • Specific high-value customer in failed state >7 days

Don''t:

  • Skip the metrics (you''ll fly blind)
  • Trust default Stripe Recovery dashboard alone
  • Forget to segment by customer tier

Output:

  1. The metric dashboard
  2. The funnel breakdown
  3. The alert rules
  4. The benchmark targets

The biggest improvement signal: **per-touchpoint funnel data.** Knowing 70% open the email but only 15% click the CTA tells you the email body needs work. Knowing 80% click but only 20% complete the portal tells you the portal is broken. Diagnose where the drop happens.

---

## 9. Handle Special Cases

Real customers have weird situations. Plan for them.

The edge case checklist.

Edge case 1: Customer paid via ACH / wire

  • Different failure modes than credit card
  • Slower retry cycle (3-5 days vs 1-2 days for cards)
  • Different communication template

Edge case 2: Customer paid via Apple/Google Pay

  • Updates may need to happen in-app
  • Same dunning principles; different flow

Edge case 3: Customer used a one-time discount that''s expired

  • Renewal at full price fails because card has spending limit
  • Specific email: "your discount expired; consider [paid plan options]"

Edge case 4: International / FX issues

  • Currency conversion can cause "amount differs" declines
  • Customer may want USD billing instead of local
  • Offer currency selection

Edge case 5: Tax-related declines

  • New tax (VAT in EU) causing decline
  • Customer needs to provide tax ID
  • Surface this in email

Edge case 6: Multi-card / family accounts

  • Customer has multiple cards on file
  • Stripe should auto-fall-back to next card
  • If all fail, dunning sequence

Edge case 7: Account deletion mid-failure

  • Customer requests deletion while in failed state
  • Honor the request per account deletion
  • Don''t hold their data hostage to "settle the balance"

Edge case 8: Refund disputes during dunning

  • Customer disputes a charge while next charge is pending
  • Pause dunning until dispute resolved
  • Don''t double-charge

Edge case 9: Subscription pause requests

  • Customer wants to pause, not cancel
  • Implement pause functionality (per refunds-chargebacks-chat)
  • Pause stops dunning for the pause duration

Edge case 10: Bank fraud false-positives

  • Customer''s bank flags your charge as fraud
  • They contact bank; bank approves; retry succeeds
  • Smart Retries handles; ensure you don''t auto-cancel before this completes

Output:

  1. Handling per edge case
  2. The communication templates
  3. The fraud-flag detection

---

## 10. Quarterly Review

Dunning effectiveness drifts. Quarterly review keeps it sharp.

Quarterly dunning review.

Recovery metrics:

  • Recovery rate trend
  • Per-decline-reason recovery
  • Email engagement trend

Cost / impact:

  • ARR recovered this quarter
  • ARR lost to involuntary churn
  • Compare to voluntary churn (different problem)

Customer feedback:

  • Support tickets about dunning
  • "Surprised by downgrade" reports
  • Cancel-survey reasons related to billing

Processes:

  • Email sequence still resonates?
  • Templates need refresh?
  • Tier-specific variants accurate?

Provider:

  • New Stripe / Paddle features?
  • Smart Retry config still optimal?
  • Any new decline categories?

Output:

  • Quarter recovery rate
  • 1-2 email tweaks
  • 1 process improvement

---

## What "Done" Looks Like

A working dunning system in 2026 has:

- Smart Retries enabled in your payment provider
- 5-touch email sequence over 30 days with tier-specific variants
- In-product banner with severity progression
- Self-serve update flow via Stripe Customer Portal (or equivalent)
- Soft downgrade policy (not hard cutoff)
- Restoration flow that recovers customer in seconds
- Per-decline-reason messaging
- Recovery-metric dashboard
- Quarterly review baked into the team rhythm
- Documented public policy on access degradation
- Edge-case handling for ACH / international / tax / fraud

The hidden cost of weak dunning: **10-30% of paying customers churn involuntarily each year**. For a $500K ARR business, that''s $50K-$150K of recoverable revenue evaporating annually. Smart Retries + tier-specific emails + in-product banners + self-serve update flow recovers 60-80% of would-be involuntary churn. The infrastructure pays back in days; the discipline is what compounds the recovery rate over time.

---

## See Also

- [Trial-to-Paid](trial-to-paid-chat.md) — the conversion flow that precedes dunning
- [Refunds & Chargebacks](refunds-chargebacks-chat.md) — related billing topic
- [Reduce Churn](https://www.launchweek.com/4-convert/reduce-churn) — broader retention context
- [Roles & Permissions (RBAC)](roles-permissions-chat.md) — billing-admin role gating
- [Audit Logs](audit-logs-chat.md) — billing changes logged
- [Account Deletion & Data Export](account-deletion-data-export-chat.md) — data preservation rules
- [Email Deliverability](email-deliverability-chat.md) — dunning emails must reach inbox
- [Multi-Tenant Data Isolation](multi-tenancy-chat.md) — workspace billing context
- [Payment Providers](https://www.vibereference.com/auth-and-payments/payment-providers) — Stripe / Polar / Paddle / Lemon Squeezy
- [Subscription Billing Providers](https://www.vibereference.com/auth-and-payments/subscription-billing-providers) — full billing engines
- [Stripe Customer Portal](https://www.vibereference.com/auth-and-payments/stripe-customer-portal) — self-serve update
- [Email Providers](https://www.vibereference.com/backend-and-data/email-providers) — Resend / Postmark for dunning emails
- [Email Marketing Providers](https://www.vibereference.com/marketing-and-seo/email-marketing-providers) — Loops / Customer.io for lifecycle emails

[⬅️ Growth Overview](README.md)