Recurring Billing Software: What to Require When Failed Rebills Leak Revenue

Recurring billing software runs the plans, the invoices and the renewals of a subscription business. When you shortlist one, it's easy to spend the whole demo on pricing models, tax and revenue reports, and give failed payments one line. That line is where a lot of revenue is decided.

This guide is for teams choosing recurring billing software. It doesn't rank vendors. It covers what the software does, where it hands off to the payment layer, and how to test what happens when a renewal fails, before you sign. If you need the basics first, start with what recurring charges are.

What recurring billing software does

Strip away the feature grids and recurring billing software does two jobs.

The first is billing: the plans and prices you sell, trials, the schedule each subscription renews on, the invoices it creates, the portal where customers manage their plan, and the reports finance needs.

The second is collecting: charging the saved payment method when a renewal is due, and deciding what to do when that charge fails. That failure handling is the part called dunning.

The first job is easy to judge in a demo. The second only shows itself when a real card declines, which is why it's worth testing on purpose.

Where billing software ends and the payment layer starts

FloPay sits on the payment side of billing. It keeps saved cards in its vault, picks the gateway for each charge, and runs the retries when a renewal fails.

For subscriptions FloPay manages, it also owns the schedule, the invoices, the past-due state and the webhooks your systems listen to. Subscriptions your payment provider manages keep that provider's own retry rules, and FloPay does not start a recovery campaign for them. The subscriptions guide spells out which is which.

FloPay sits on the payment side. For subscriptions it manages, it also owns the schedule, invoices, past-due state and webhooks.

That split matters when you shortlist. Ask every vendor the same thing: when a renewal fails, whose rules decide the next attempt, and on which gateway?

One retry rule for every failure leaks revenue

A renewal can fail for very different reasons. A generic do-not-honor or an insufficient-funds decline can be worth another attempt later in the cycle. A card the issuer reports lost or stolen is a hard stop for that card. Retrying both the same way wastes the attempts that could work and repeats the ones that can't.

FloPay sorts each failed renewal by what the decline means. A generic do-not-honor or insufficient-funds decline gets scheduled retries that stay inside the billing cycle. A card the issuer reports lost, stolen or expired is set aside for the rest of the campaign, while the customer's next saved method is tried. How a campaign is timed is on our subscription recovery page. For your shortlist, the question is simpler: does the tool you're looking at make this distinction at all?

We haven't published which decline is most common for our merchants, so we won't name one here.

Stale saved cards

Some renewals fail because the token stored for a saved card has gone stale, not because the customer did anything wrong. When that happens, FloPay mints a fresh token from the card details held in its vault, saves it on the payment method and retries once. If that still fails, it moves to the customer's next saved method instead of looping.

Every scheduled recovery retry also looks up the customer's saved methods again, so a card they updated during the campaign can pay the renewal without anyone stepping in. PayPal methods don't go stale this way and are not refreshed. The full rules are in the routing and reliability guide.

What we saw when a merchant switched

ClickTech, one of our merchants, moved from Recurly to FloPay and saw a large uplift in successful rebills, using the same underlying payment gateways. The gateways didn't change. The layer deciding what happens around each renewal did.

If you're weighing Recurly yourself, our FloPay vs Recurly page sets the two side by side.

Test it before you sign: one failed renewal

Demos show the happy path. Run one failed renewal through each tool in a sandbox and watch four things:

1. The subscription stays past due, and its paid-through date does not move until money clears.
2. Retries stop before the next billing date.
3. A card the issuer reported lost or stolen is set aside, not retried.
4. When a processor times out, the tool proves what happened before it charges again. A timeout is not a decline, and charging again without checking risks billing the customer twice for one renewal.

What a failed renewal should look like in your test: past due while retries run, renewed once when the money clears.

Then check that a second gateway is really switched on for failover. In FloPay, a newly added gateway starts with failover off, so connecting it is not enough on its own. The routing and reliability guide shows the setting.

Questions to ask any billing vendor

Put these to every vendor on your list, and ask for the answers in writing:

• Can a failed retry ever move the paid-through date, or send a renewed event before the money clears?
• When a charge times out, do you charge again or first prove whether it went through?
• Can a retry use the same saved card on a second gateway, and who holds that card?
• Is a recovered renewal reported apart from a first-attempt renewal, without being counted twice?

The third question decides how much you can change later. Where your saved cards live determines which processor a retry can reach. What a credit card vault is explains why, and payment orchestration for subscription merchants covers routing beyond renewals.

What recovery reporting should show

Ask how a tool reports the renewals it recovered after a first failure. In FloPay, recovered renewals are counted and summed, and shown as part of the renewal totals rather than added on top of them, so a recovered payment is never counted as a second sale. The analytics and reporting guide shows where they appear.

We don't publish a recovery rate. Those figures are still being built, so you won't find a percentage here.

Where FloPay fits

FloPay isn't a ranked entry in this guide. It's the payment and recovery layer that sits under or beside your billing tool: the vault, the gateway for each charge, and the recovery of failed renewals. If you're comparing it with a billing platform directly, our side-by-side pages say what each one does: FloPay vs Chargebee, FloPay vs Recurly, and every comparison.

The short version

• Recurring billing software does two jobs, billing and collecting. Demos show the first, so test the second.
• Know whose rules decide the next attempt when a renewal fails, and on which gateway.
• A good tool sorts declines: it retries the ones that can clear and sets aside the cards that can't.
• Run one failed renewal in a sandbox before you sign, and check your failover switch.
• Ask how recovered renewals are reported, and make sure they're never counted twice.

See how FloPay recovers failed renewals, check pricing, or browse the FloPay docs.