SaaS Billing Guide Payment Infrastructure and Processing for Recurring Billing and SaaS
Most subscription businesses treat payments like plumbing — invisible until something backs up. That's a mistake. Your payment stack decides whether month two...
Daniel R. Whitfield 5 min read
Most subscription businesses treat payments like plumbing — invisible until something backs up. That's a mistake. Your payment stack decides whether month two actually renews, whether a dead card gets rescued or quietly churns, and whether the revenue you report to your board bears any resemblance to cash in the bank. This piece is about how the money actually moves when the same customer keeps paying you.
Two words people use interchangeably, and shouldn't
Infrastructure is the chain. Processing is the work happening inside it: authorization, fraud screening, capture, settlement, reconciliation. One-off purchase? That chain runs once and everyone goes home. SaaS is different. The chain runs every billing cycle, for every subscriber, forever, and that repetition rewrites the rules. Nobody cares that your checkout charges a card in 800ms. They care that renewal 14,000 doesn't mysteriously fail on a Tuesday. Plenty of processors demo beautifully on a checkout page and then crumble the moment you feed them proration, dunning, and retries at volume.
Follow a single renewal through the stack
You can't read your own failure data if you don't know the path. Here's the route a typical recurring charge takes.
- Billing engine adds up what's owed — proration, tax, discounts, the lot.
- Gateway encrypts the card and fires an authorization request at the acquirer.
- Card network passes it to the issuing bank. Approve or decline. No appeal.
- Approved funds get captured, then settle into your merchant account — usually later than you'd like.
- Transaction lands in your ledger and gets reconciled against accounting.
Any one of those steps can break on its own, and each failure has its own fingerprint. A gateway timeout is not a soft decline from an issuer, and treating them as the same event is one of the quietest, most expensive mistakes in SaaS billing. You'll recover the wrong failures and write off the ones you could have saved.
What you're actually choosing between
Almost nobody builds this from scratch anymore. You assemble it from vendors, and the seams between those vendors matter far more than the logos on the invoices.
| Component | What it does | What to check |
|---|---|---|
| Payment gateway | Securely transmits card data and routes authorization requests | Tokenization, retry controls, decline codes |
| Merchant account / acquirer | Holds your ability to accept card payments and settles funds | Pricing model, chargeback terms, payout timing |
| Subscription billing engine | Manages plans, proration, invoicing, and dunning | Proration logic, tax handling, webhook reliability |
| Fraud and risk tools | Score transactions and block suspicious ones | False-positive rate on renewals |
| Reconciliation and reporting | Matches processed payments to your revenue records | Settlement detail, currency handling, export quality |
Here's the trap. Modern platforms love to bundle gateway, billing, and fraud into one tidy product. Great — less integration work. Also: you've just welded the pieces together, so swapping out the weak one later means ripping out the whole thing. Growing fast? Before you sign, ask what leaving would cost you. If the answer is "rewrite the billing engine," think hard.
Why renewals fail — and which processing choices save them
Involuntary churn is the leak nobody puts on the dashboard. Customers don't leave because they wanted to; they leave because a card expired or an issuer got twitchy. Expired cards, issuer declines, insufficient funds — all show up as "failed renewal," all need different medicine.
Card updater services, run by the networks through your acquirer, quietly refresh expired or reissued cards before the charge even fires. Smart retries pick a second attempt at a time the issuer is likelier to say yes — not three hammer-blows within the hour. Pre-dunning emails nudge the customer to update details before the charge runs at all. Simple stuff. Underused stuff.
But none of it works if your billing system can't tell you why a charge failed. Demand readable decline codes. Demand webhook events that land in your own systems. Without them you're guessing, and guessing gets very expensive at ten thousand subscribers.
The metrics resting on payment data
MRR, churn, expansion — every one of them traces back to a charge that succeeded, settled, and got recorded correctly. If your processor reports in one currency and your billing engine in another, or settlement dates drift a day from invoice dates, your revenue figures drift right along with them. The board deck is only as honest as the plumbing.
Watch three numbers. Authorization rate: what share of renewals clear on the first attempt. Recovery rate: how many failed renewals you claw back through retries and dunning. Settlement lag: how long the cash takes to actually show up. Between them, they explain most of the gap between "booked" and "in the bank."
What to actually do
You don't need the fanciest stack on the market. You need one that fits your billing model and doesn't box you in. A few things hold true across most subscription businesses.
- Separate billing logic from payment transmission where possible — then a processor swap doesn't force you to rewrite your plans and proration rules.
- Test the whole renewal path before launch. Failed card, successful retry, all of it.
- Keep your own copy of transaction events. A vendor dashboard is not a system of record.
- Once volume is real, compare interchange-plus against flat-rate pricing — the gap widens with every renewal.
Retry rules, tax handling, reconciliation: cheap to build before you have thousands of subscribers, painful and pricey after. Get those right, keep half an eye on authorization and recovery rates, and the rest of your subscription metrics stop lying to you.