How to set up recurring billing for SaaS and memberships

What a recurring billing program is

A recurring billing program is an arrangement in which a customer authorizes you once and you charge a stored payment credential repeatedly, on a schedule both sides agreed to in advance. That is the whole idea, and nearly every failure in subscription payments comes from one half of it being much weaker than the other: the charging side is automated, tested and reliable, while the authorization side is a checkbox nobody kept a record of.

Recurring billing is not the same thing as remembering a card for convenience. A retailer that saves a card so a returning customer can check out in one tap holds a credential the customer reaches for each time. A subscription business charges without the customer present, on its own initiative, under permission given months earlier. The two arrangements look identical in a database and behave nothing alike when a cardholder calls the bank.

This guide follows the order a merchant actually meets these problems: the permission and the record of it, the credential and how it is stored, the failures that come from the credential going stale, the retry logic that recovers them, and then the trial, cancellation and plan-change paths that decide whether an unhappy customer disputes a charge or simply leaves.

Stored card, card-on-file mandate and recurring authorization

These three terms describe three different levels of permission, and the card networks treat them as three different things. Getting the label right on each charge is not paperwork; it is what the issuer sees when it decides whether the transaction looks normal.

A stored card is a credential kept for the customer’s own convenience. Every charge against it is customer-initiated: the customer is present, chooses to pay and approves the amount at that moment. A card-on-file mandate is merchant-initiated but unscheduled — an account top-up, a variable usage balance, a no-show fee, a damage charge. The customer agreed that you may charge the card, but did not agree to a specific amount on a specific date. A recurring authorization is merchant-initiated and scheduled: a fixed cadence, with the amount, the interval and the term disclosed before the first charge.

The distinction shows up in dispute outcomes because a transaction carries indicators that tell the issuer which of the three it is, and issuer risk models and network dispute rules read those indicators. A charge submitted as an ordinary card-not-present sale, when it is really the eleventh instalment of a subscription, looks to the issuer like a card number being used while the cardholder is somewhere else. It attracts more scrutiny, it is likelier to be declined, and when the cardholder does not recognize it you have no framing to answer with. A correctly flagged recurring transaction backed by a mandate is a far simpler defence: you can show what the customer agreed to, when they agreed, and what they have been receiving since.

Decide which of the three each charge is before you build it, and make sure the integration sends the matching indicator. If a single stored credential serves more than one purpose — a subscription that renews monthly and an occasional overage billed on top — those are two different kinds of charge against the same credential, and they should not be submitted identically.

What consent has to say, not just that it was given

Consent to a recurring charge has to record what the customer agreed to, not merely that they agreed to something. A timestamp against the words “accepted terms” tells a dispute reviewer nothing, because it does not show what was on the screen.

For merchants on RapidCents this is a term of the Services Agreement rather than a recommendation. Clause G.4 requires affirmative consent to the recurring mandate before the first charge is made, given by an affirmative act directed specifically at that mandate. The clause also states plainly what does not count as consent: a pre-selected box, the customer’s inaction, continued browsing, bundling the mandate into acceptance of unrelated terms, or placing it in a document the customer is not required to open.

G.4 then lists what you must disclose to the customer, clearly and in the same place consent is given: the amount of each charge, or how a variable amount is calculated and any maximum that applies; the currency; how often the charge is made and on what date or billing cycle; how long the mandate runs, whether it renews automatically and the length of each renewal period; what the customer receives for each charge; for a free trial, discounted period or introductory offer, the date it ends, the amount of the first charge after it ends and the date of that charge; how the customer cancels, including the method, where it is found and any notice period; and the billing descriptor that will identify you on the statement.

The descriptor is worth a second look, because it is the one disclosure the customer reads long after the fact. Clause G.5 requires it to correspond to the name the customer actually dealt with — the trading name, storefront, brand, application or website — and not only a holding company, a registration number or an internal code. In practice, build the whole disclosure into the signup screen next to the button, in text the customer cannot avoid passing. A link to a terms page is not the same place.

The consent record is what decides the chargeback

A consent record is only worth having if you can produce it later in a form that shows what the customer saw. That is a storage and versioning problem, and it has to be solved before launch rather than during your first dispute.

Clause G.4 sets out what the record contains and how long it lives. For each recurring mandate you must create and retain a record sufficient to establish the customer’s consent, what was disclosed at the time consent was given, the date and method of consent, every charge made, every notice given under the clause, and any cancellation and the date it took effect. You must keep it for as long as the mandate remains in effect and for at least a further twenty-four months after the last charge — longer where the network rules, applicable law or the agreement’s data section require more. And you must produce it to RapidCents on request, within the time RapidCents specifies.

The consequence is the part to read twice. If you cannot produce the record, the transaction in question is treated under the agreement as having been made without the customer’s consent, and the resulting dispute, chargeback, refund, fine actually levied and cost actually incurred by RapidCents are yours. That is a contractual reallocation of loss triggered by a missing file, not by anything the customer did.

In build terms: version the terms and the signup screen so you can reproduce the exact wording in force on the date of consent; store the timestamp, the method, and an identifier tying the consent to the session and the customer; keep the notices you sent along with evidence of delivery; and keep all of it past the point where the subscription ends and the customer record is otherwise archived. A deletion policy written for privacy hygiene will quietly erase your dispute defence if nobody carves this out of it.

Store a token, not a card

Storing a token instead of a card number is the only model that keeps repeat billing working without putting card data in your systems. Tokenization exchanges a card entered on a RapidCents-hosted surface for a reference that only RapidCents can map back to the credential; your software stores the token against the customer record and charges it on schedule. The secure card vault is the PCI-scoped store those tokens point at.

Two consequences are worth stating outright. The first is scope: your systems hold a reference that is useless anywhere else, which keeps raw credentials out of the environment you have to assess. The second matters more for a subscription business — the credential becomes updatable independently of your database. The token stays stable while the card behind it is refreshed, so a reissued card does not require a schema change, a migration or a message to the customer.

A token can be charged across channels on the same account, which is why a customer who signs up online can be billed by the same stored method when your team handles the account by phone later. Keep one distinction clear, though: the token and the consent record are separate objects with separate lifecycles. Deleting a token when a customer cancels is good vault hygiene, and it does nothing to relieve you of retaining the consent record for the period G.4 sets.

Involuntary churn is several problems wearing one name

Involuntary churn is revenue lost when a customer who still wants the service stops paying because the credential failed. It is a single line on a dashboard and at least five different underlying problems, each with a different fix.

An expired card is predictable: the date is known months ahead and the failure is avoidable. A reissued card is not predictable — the customer’s bank replaces the number after a loss, a theft or a portfolio migration, and you find out when a charge fails. Insufficient funds means nothing is wrong with the card at all; the timing was wrong. A closed account means the credential is gone for good. An issuer stop instruction means the customer told their bank to stop the charges, which is not a payment failure at all but a message about the relationship.

Because the causes differ, the responses have to differ. Expiry and reissue are credential problems, fixed by refreshing the credential. Insufficient funds is a timing problem, fixed by retrying at a better moment. A closed account or a stop instruction is a customer problem that only the customer can fix, and retrying it produces nothing except declines on your record. Any retry logic that does not branch on the decline reason will waste attempts on the failures it cannot recover and give up too early on the ones it could.

What Account Updater fixes, and what it does not

Account Updater refreshes stored credentials with the card networks when a card expires or is reissued, so a schedule keeps running without asking the customer for a new card. The refreshed details apply to the stored token in the background, the token your systems hold does not change, and methods that could not be refreshed are flagged so you know which customers to contact.

It does not fix insufficient funds, because the credential was never the problem. It does not fix a card the customer cancelled without taking a replacement, an issuer stop instruction, or a customer who simply wants to pay with a different card. Coverage also depends on the network and the issuer participating in update services, so the honest description is that it reduces credential-driven failures rather than eliminating them.

The operational point most programs miss: the exception report is a work queue, not a log. The value of the service is not only in the credentials it refreshed silently but in the flagged ones you contact before the next billing date arrives, while the customer is still a customer and not yet an involuntary cancellation. Give that queue an owner and a turnaround time.

Dunning: retry timing beats retry count

Retry timing matters more than retry count because the most recoverable declines resolve on the customer’s cash cycle, not on yours. Adding attempts to a badly timed schedule mostly adds declines.

Start by separating soft declines from hard ones. A soft decline — insufficient funds, a temporary hold, a velocity limit — describes a condition that may not be true tomorrow. A hard decline — a closed account, a card reported stolen, a refusal the issuer means permanently — describes a condition that will still be true on every future attempt, and repeated attempts against it are noise that issuers and networks can see.

For the soft declines that dominate recurring failures, the recovery moment follows money arriving in the customer’s account, which follows pay cycles measured in days rather than hours. Retries clustered inside the first day mostly re-test the same empty balance. Spacing attempts across several days, and making sure at least one attempt lands after a likely deposit, is the change that moves the outcome. RapidCents recurring payments ship with configurable retry windows and retries on day three, day seven and day fourteen with alerts at each step; the reason the windows are configurable is that a consumer subscription and a business plan billed on net terms do not have the same recovery curve, and neither should inherit the other’s schedule.

Treat customer communication as part of dunning rather than a courtesy attached to it. A message on the day of failure that says what happened, what it was for and how to fix it recovers charges no retry schedule will reach, because a card that has been cancelled will never succeed and a customer who replaces it takes two minutes. Send a secure link that lets the customer update the stored method themselves; asking them to telephone during business hours converts a two-minute fix into a cancellation.

Decide the stop rule before you launch: how many attempts, across how many days, and what happens at the end. Suspension, downgrade to a free tier and full cancellation are three different endings with three different recovery profiles, and choosing between them after the fact usually means choosing nothing and giving the service away.

Free trials that do not turn into disputes

Most trial disputes are not really about the trial. They are about a charge the customer did not expect, on a date they had stopped thinking about, from a name they did not recognize. Each of those three is fixable in the signup flow.

Clause G.4 makes two of the fixes mandatory for RapidCents merchants. At the moment consent is taken you must disclose, for a free trial or discounted or introductory period, the date it ends, the amount of the first charge after it ends and the date that charge will be made. Separately, before that first charge you must give notice of the conversion, its amount and its date, by email or another method the customer has agreed to receive — within the period the applicable network rules and law require and, in any event, not less than seven days before the charge. Where the trial itself runs shorter than seven days, the notice must be given when the trial begins.

That last sentence has a design consequence people miss: a short trial carries its conversion notice at the start, which means the signup confirmation is the notice, and it has to contain the amount and the date rather than a welcome message. Send conversion notices through your transactional mail path, not your marketing one. A customer who unsubscribed from marketing has not waived the notice, and a notice that lands in a promotions folder is a notice you will have trouble relying on.

The third fix is the descriptor. The conversion charge reaches a statement weeks after signup, and it is read next to twenty other lines. A descriptor that matches the brand the customer signed up with is the difference between a moment of recognition and a call to the bank. Where the trial begins with a card verification, tell the customer what they will see, because a pending authorization from an unfamiliar name is itself a source of inquiries.

Cancelling should be no harder than subscribing

Under clause G.4 the cancellation method must be available to the customer at least as readily, and by at least as simple a process, as the method by which they enrolled, and through the same channel where that channel remains available. This is the standard, and it is stated as an obligation on the merchant.

The clause is specific about the common workarounds. A customer who enrolled online or in an application cannot be required to cancel by telephone, by mail or in person. You must not impose a retention step, an offer sequence or a delay the customer cannot decline and move past. A cancellation takes effect no later than the end of the then-current billing period, and you must not charge under the mandate after it takes effect. G.4 also addresses what happens when the instruction arrives from the other direction: where RapidCents receives an instruction from a customer, an issuer, the acquirer or an association to stop charges, or the payment method is reported lost, stolen or closed, further charges may be declined or reversed — and you must not re-present, re-enrol or re-establish a cancelled or stopped mandate without fresh consent obtained the same way as the first.

There is a commercial argument underneath the compliance one. A cancellation flow that traps people converts a lost subscription into a chargeback, and a chargeback costs more than the month you saved. Under clause C.4 you are responsible for the full amount of the chargeback plus the dispute fee, the amount is debited from your balance, payout account or reserve, and the dispute counts toward the ratios the associations monitor. The month you clawed back is the cheapest thing in that transaction.

The productive version of retention offers is to show them without blocking. Pause, downgrade, change the billing date and switch to annual can all sit on the same screen as the cancel button, as choices the customer can see and ignore. That satisfies the standard and still catches the customers whose real problem was the price or the timing rather than the product.

Proration, plan changes and refunds

A plan change is two events, not one: the end of a billing arrangement and the start of another. Handling it means deciding what the customer is charged for the fragment of period between them, and deciding it the same way every time so the answer is defensible when a customer questions it.

Proration credits the unused portion of the current period against the new amount, and RapidCents recurring payments calculate that credit for a mid-cycle change. The decisions that stay yours are the ones that cause arguments: whether an upgrade takes effect immediately or at the next cycle, whether a downgrade refunds cash or issues account credit, and whether the billing date moves with the change or stays where it was. Write them down and apply them uniformly.

Price increases are governed rather than discretionary. Clause G.4 requires notice of any increase in the amount, any change in frequency and any material change in what is supplied, before the change takes effect, with at least the notice the network rules and applicable law require and in any event not less than thirty days; and where applicable law requires the customer’s consent to the change, you must obtain that consent before charging the changed amount. Practically, a price rise is planned a month ahead, and the notice becomes another document in the consent record.

Refunds behave differently from the reversal people imagine. Under clause C.5 a refund goes back to the original payment method, and refunding a card sale in cash or by another method is generally prohibited by the network rules. Refunds are subject to standard transaction processing fees unless your fee schedule says otherwise, and if your balance is insufficient the funds may be debited from your payout account or reserve. A refund is therefore a second transaction with its own cost, not an undo of the first. It is still cheaper than a dispute: refunding a customer who is right costs the fee, while losing a chargeback costs the amount, the dispute fee and a mark against your ratio.

The numbers worth watching

Four measurements tell you whether a recurring program is healthy, and all four are yours to compute against your own history. There is no published figure that tells you whether your rate is normal for your price point, your billing cycle and your customer base, so the comparison that matters is with last quarter.

Failed payment rate is failed attempts divided by scheduled charges, per cycle, segmented by decline reason. The aggregate number tells you something is wrong; the segmentation tells you whether the answer is updater enrolment, retry timing or a customer conversation.

Recovery rate is the share of failed charges ultimately collected, measured both by attempt number and by elapsed days. Measuring by attempt shows you where your retry schedule stops earning; measuring by day shows you whether your window is long enough to reach the next pay cycle. Recovery that arrives after the customer has already been suspended is worth counting separately, because the churn happened anyway.

Dispute rate on recurring charges should be tracked apart from dispute rate on one-off sales, because the two have different causes and averaging them hides both. When recurring disputes run higher, the cause is almost always disclosure, descriptor or cancellation rather than fraud, and the reason codes will say so. This one has a ceiling attached: the RapidCents Services Agreement notes that sustained chargeback rates above association thresholds — it gives roughly one per cent of transaction count or volume as the common figure — can bring closer scrutiny, higher fees, reserve requirements and, at the far end, termination.

The fourth is the split between voluntary and involuntary churn, meaning customers who cancelled and customers whose payments failed. A single churn number hides which of two entirely different problems you have. Worth tracking alongside it: the share of stored credentials the updater refreshed versus flagged, the time from a failed charge to first contact with the customer, and the age of the oldest unresolved flagged credential — the last one is usually the honest measure of whether anyone owns the queue.

What changes on an annual plan

An annual plan concentrates a year of revenue into one charge, which changes the cost of every failure and the memory of every customer. The same billing engine runs it, but almost every threshold you set for a monthly plan is wrong for an annual one.

A failed annual renewal is twelve months of revenue rather than one, so the effort justified in recovering it is larger and the dunning window should be longer. The credential is also a year older at renewal, which makes expiry and reissue far likelier than on a monthly cycle. Enrol annual plans in credential refresh as a matter of course, and check the stored method in the weeks before the renewal date rather than discovering the problem on the day, when there is no time left to ask the customer.

The customer last thought about you eleven months ago. On a monthly plan the receipt is a reminder that arrives twelve times a year; on an annual plan there is nothing between the signup and the charge unless you put something there. G.4 already requires you to disclose how long the mandate runs and whether it renews automatically, and a renewal reminder ahead of the date is what actually prevents the dispute that begins with a customer saying they had forgotten the service existed.

Money moves in larger units, and that has knock-on effects. Proration on a mid-year change is a meaningful amount rather than a rounding line. A refund of an annual charge is a single large debit against your balance, and under C.5 it may be taken from the payout account or reserve if the balance will not cover it. Collecting a year in advance against service still to be delivered is also one of the profiles the agreement names in clause C.7 when it lists long fulfilment times among the factors that can lead to a reserve — worth knowing before you build a business model that assumes the full amount is available the week it settles.

Where recurring programs leak

The same handful of gaps account for most of the revenue that leaves a subscription business without anyone deciding it should. Consent is collected but never recorded in a form that can be produced. Retry logic ignores the decline reason and treats a closed account like a temporary shortfall. The trial conversion notice goes out through the marketing channel and lands where nobody reads it. The billing descriptor names a legal entity the customer has never heard of. Cancellation sits behind a phone number, and the customers who cannot reach it call their bank instead.

The largest one is simpler than any of those: nobody owns the failed-payment queue. Every mechanism in this guide produces a list — flagged credentials, exhausted retries, pending cancellations, disputes awaiting evidence — and each list works only if a named person clears it on a schedule. A billing system automates the charging. It does not automate the following up, and that is where the recoverable revenue sits.