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 thousands of SMBs and thousands of 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 across thousands of 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.