Meet us at conferences around the world
SBC Summit Lisbon
SiGMA Europe
A practical guide to integrating a subscription billing API. The two places recurring payments break, why dunning is a routing problem and not a retry loop, and the go-live sequence that protects your MRR.
By Daniel Karpilovsky, Head of Success, Payneteasy
A subscription billing API looks simple from the outside: charge the same customer every month, done. The teams I onboard learn quickly that it breaks in two very specific places, and that most lost subscription revenue is not customers cancelling, it is payments quietly failing. Get those two places right before launch and churn from payment failures stops being your problem.
If your business runs on subscriptions, this is the part of the integration that protects your revenue. Not the part that charges a card, anyone can do that, but the part that decides what happens when a renewal fails. That is where the money is kept or lost.
A subscription billing API charges your customers automatically on a schedule and manages the whole lifecycle around it: the plan, the renewal, the failure, the recovery. The charging part is easy and everyone gets it right. The lifecycle part, especially what happens on a failed renewal, is where subscription businesses keep or lose their recurring revenue.
After many onboardings, I can tell you the two places it almost always breaks. The first is the first failed renewal: a card that worked last month is declined this month, and a system that treats that as a cancellation loses a customer who never meant to leave. The second is the card update: cards expire and get reissued constantly, and if you cannot prompt for and accept a new card smoothly, the subscription simply dies on renewal. Plan for both before launch, and you have handled most subscription churn that is actually payment churn in disguise.
Most teams build dunning as a timer: payment failed, wait three days, try the same thing again. That is a retry loop, and it leaves money on the table. A failed renewal one bank declines is often approved by another. The smarter approach treats each failure by its reason, an expired card needs a card update, a soft decline needs a retry on a different bank or at a better time. Route the recovery by the failure reason instead of blindly repeating it, and you keep subscriptions a blind loop would lose.
The difference is not effort; it is whether the retry is informed.
| Naive retry loop | Smart dunning | |
|---|---|---|
| Trigger | Fixed timer after any failure | Reason-aware response per failure |
| Expired card | Retried, fails again | Customer prompted to update the card |
| Soft decline | Same bank, same way | Retried on another bank or a better window |
| Result | Wasted attempts, lost subscribers | Recovered renewals, retained revenue |
| Double-charge risk | Real if no safeguard | Prevented with idempotency keys |
Do these in order before you migrate real recurring volume:
The order matters more than the speed; go-live is a sequence, not a switch.
Payneteasy handles recurring billing where it actually counts, on the failed renewal. Because it sits inside an orchestration platform, dunning is genuinely a routing decision: a declined renewal can cascade to another bank, and recovery is matched to the failure reason, not a blind timer. We get you live, then we get you winning, and for a subscription business winning means the renewals you used to lose now clear. Test a failed renewal in the sandbox first; that is the scenario worth rehearsing.
Practical next step: read the platform overview, request a sandbox key, and deliberately fail a test renewal to see the recovery work before you migrate live subscriptions.
A way for your software to charge customers automatically on a schedule, monthly or yearly, and to handle what happens when one of those charges fails, all without anyone approving each renewal by hand.
Cards expire, get reissued with new numbers, hit temporary bank limits, or trip a cautious fraud rule on a recurring charge. The customer still wants the service; the payment just needs another path or an updated card.
The process of recovering a failed recurring payment, retrying it intelligently and prompting the customer to update their card if needed, before the subscription lapses. Good dunning quietly saves revenue you would otherwise lose.
Because a renewal that one bank declines is often approved by another. Retrying the same way on the same bank wastes attempts; retrying on a different bank, by the right reason, recovers the payment. That is routing, not a blind loop.
Idempotency keys. They let you retry a renewal safely without ever taking two payments for one billing period.
Thank you for reaching us. Your request has been sent successfully. We will get back to you as soon as possible.
Message was not sent
