Recurring Billing 101 for Service SMBs.

If you're running recurring billing for a service SMB and you're not actively managing failed payments, you're leaking 6-8% of MRR every single month. On a $50K MRR business, that's $3K-$4K disappearing silently, every month, forever, until you fix the dunning.

This post is the exact playbook we run across 1,500+ SMBs and 2,400+ recurring contracts. It's not theory. It's what works in production.

Why payments fail (the actual breakdown)

The failure breakdown:

The takeaway: ~96% of payment failures are recoverable with the right system. Most SMBs recover <30% because they don't have a system.

The 3-retry rule that recovers 92% of failures

Stripe research (and our own data on 1,500+ SMBs) is consistent: the optimal retry schedule for recurring charges is:

1. First retry: Day 3 — catches insufficient funds (payday cycles) and transient bank declines
2. Second retry: Day 7 — catches card replacements, gives customer time to notice missed payment notification
3. Third retry: Day 14 — final attempt before requesting card update or pausing

If all three fail, you don't keep blindly retrying. You pause the account and trigger a "please update your payment method" workflow.

The "please update" workflow that converts

When you finally email the customer "your card on file failed," 60-70% will update if you do it right. Here's the formula:

Subject line that works

Bad: Payment failed — action required (sounds threatening)
Good: Quick heads up — let's get this sorted (sounds collaborative)
Best in Spanish: Ojo — el cobro no pasó, te ayudo a arreglarlo

Email body structure

1. Acknowledge it's not their fault — "Cards expire, banks decline, it happens."
2. Tell them exactly what to do — one button, one link, 30 seconds
3. Tell them what happens if they don't — "We'll retry in 3 days. If we can't recover, your account pauses (not deletes — you can resume anytime)."
4. Offer human help — "Reply to this email if you'd rather talk to a person."

Card expiration: catch it 30 days before

Every payment processor stores card expiration date. A simple cron job that scans daily for cards expiring in the next 30 days and emails the customer recovers 4-6% of MRR that would otherwise have failed.

Sample email subject: The card on file expires next month
Spanish: La tarjeta que tenemos vence el próximo mes

The customer updates the card before the next billing cycle. Zero downtime. Zero failed payment to recover.

SMS dunning: when it's worth it

For customers paying $200+/month, SMS dunning recovers an additional 8-12% on top of email. The math: if 100 customers fail, 70 update via email, and 8 of the remaining 30 update via SMS, you're at 78% recovery instead of 70%. On a $50K MRR business that's an extra ~$400/mo recovered.

Twilio SMS costs ~$0.01 per message. The math always works for B2B SMBs.

The bilingual angle

Here's something most US SaaS misses: if your customer base is 40%+ Hispanic, your dunning recovery rate is 15-20 percentage points higher when emails and SMS arrive in Spanish.

The reason isn't comprehension — most customers can read English. It's response rate. A bilingual email that opens in Spanish for a Spanish-preferring customer feels personal. An English-only email feels like spam. Spam gets deleted; personal emails get acted on.

The complete checklist

The cheap shortcut

Building all this yourself is 2-3 weeks of engineering. Stripe has built-in Smart Retries and Dunning emails — turn them on. They cover 80% of what's described above. The remaining 20% (bilingual, SMS, expiration cron) is where platforms like RentingOS bridge the gap.

If you're DIY-ing, start with Stripe's built-ins, layer on the rest over a quarter. If you're using a platform, just check the box.