Set Up Recurring Payments Without Losing Clients to Failed Cards

The mechanical layer under a retainer: what you actually store, when the charge fires, what happens the night it is declined, and how your CRM finds out.

Most agencies get the pricing conversation right and the plumbing wrong. The retainer is agreed, a subscription is created in the billing tool, and for three months everything looks fine. Then a card expires, the charge is declined at two in the morning, nobody is told, and the first person to notice is the client — weeks later, asking why they have not been invoiced.

A recurring charge is the only part of an agency’s operations that runs unattended, indefinitely, against a credential that has an expiry date. Whether it survives depends on decisions made before the first charge.

What it takes to set up recurring payments that keep working

Assume the commercial question is settled — whether the work should be billed once or on a cycle is its own decision, and this article starts after it. What follows is the mechanical layer: what you are storing, when it fires, what happens when it fails, and how your CRM finds out.

You are storing permission, not a card

The customer gives a standing permission and the processor keeps a token representing it. Your system holds a reference to that permission and a schedule; nothing about the card itself belongs in your database.

Two consequences surprise people. Because the merchant initiates the charge, the cardholder is not present to approve it, which is why a decline that would clear instantly at a checkout can fail silently on a scheduled run. And the permission is revocable at the customer’s bank as well as with you — a cancellation you never see is a real scenario your reconciliation has to allow for.

Three shapes of recurring charge, and they behave differently

People say “subscription” for all three, then are surprised by the behaviour.

The instalment plan is the one most often built wrong. Configured as an open-ended subscription with a reminder to cancel it later, it eventually overcharges someone — usually the happiest client, because they never checked. If the total is known, the schedule should know it too.

The anchor date decides half your support load

The charge repeats relative to a start date, and that date follows the customer forever. Decide once, as policy: bill on each signup anniversary, or on a common day of the month? Anniversary billing spreads failures across the month; a common billing day simplifies reconciliation and concentrates every decline into one morning. Neither is wrong. Choosing by accident is.

Then decide what happens to a partial first period. A prorated first charge is defensible and reliably confuses people, because the first invoice never matches the number in the proposal.

Mid-cycle changes need a stated rule

Upgrades, downgrades and pauses all raise one question: does the change take effect now with a balancing adjustment, or at the next renewal? Write the answer into the agreement rather than deciding it while a client waits.

Declines are the normal case, not the exception

Cards expire, get reissued after fraud, and get replaced when someone changes bank. A charge that runs long enough will be declined for reasons unrelated to the client’s willingness to pay.

What matters is the difference between a decline worth retrying and one that is not. Insufficient funds, a temporary hold and an issuer timeout genuinely change on their own. A card reported lost or stolen, a closed account or an explicit revocation will not clear later, and retrying those counts against you with the card networks.

Space the attempts you do make across days rather than minutes, and let each follow a notification rather than replace it. An account short at nine is usually still short at ten.

Dunning is a communication problem wearing a billing costume

The recovery process — dunning — is the sequence of messages running alongside the retries, and it recovers more than the retries do. Most of these failures are fixed by a person spending a few seconds updating a card, and they will only do that if they know.

Send it as a short sequence rather than a single email: a first message assuming an expired card and no bad faith, a second saying what happens next and when, and a final one before access changes. Each needs a single link straight to updating the payment method.

Two things decide whether any of it arrives. Billing mail has to come from an authenticated sending domain — it is the message your customer most needs and the one most likely to be filtered if your sending setup is loose. And because the address on file may be as stale as the card, a text message often lands where email does not; on a large retainer, a person picking up the phone beats another automated attempt.

Also make dunning exempt from suppression rules on your nurture campaigns. A rule written to keep marketing email away from billing contacts will, if written carelessly, also stop the message telling someone their payment failed. An advance notice before an annual renewal belongs in the same category — it turns a surprise charge into an expected one, which is the difference between a question and a chargeback.

Your CRM only knows what the processor tells it

This is where otherwise sound builds fall over. The processor is the system of record for whether money moved; the CRM is where the relationship, access and automation live. They agree only if the first tells the second what happened, and the mechanism is usually a webhook.

So read the webhook payload for the events that change state — payment succeeded, payment failed, subscription cancelled, plan changed — and map each to something observable on the contact record. Polling nightly is a workable fallback, but a failed payment can then be a day old before anything reacts.

Then decide each consequence explicitly. Which failure pauses delivery, which removes access, which only notifies a human. Vague answers produce the two worst outcomes here: a client who stopped paying and keeps receiving work, and a client who paid and got locked out because a stale event arrived late.

Cancellation is part of the setup, not an afterthought

How someone leaves is decided when they arrive. Write down the notice period, whether the final period is served or refunded, and what happens to their access afterwards — then build cancellation so it stops the schedule rather than flagging it for a human.

A cancellation requiring an email to a person reliably generates chargebacks, because the customer’s alternative route is their bank and their bank is faster than you. The same logic applies where a trial that is meant to convert becomes a paid subscription: state the date the charge begins and send a reminder before it does. Trials that convert quietly convert once and then produce refund requests, a poor trade against retention work that actually holds.

Where this sits in the rest of the stack

Recurring billing touches three things usually built separately. It depends on the checkout, so what you learn from an order bump or from the page that sells it applies to the moment the mandate is created — a confused checkout produces mandates people did not understand. It depends on operations, which is why the failure path belongs in a written playbook rather than in one person’s memory. And it sits on top of the platform bill underneath it, worth knowing before committing to a margin that processing fees quietly narrow.

What to watch once it is running

Three numbers tell you whether the setup works, and none is revenue. The share of scheduled charges failing on the first attempt tells you how stale your stored credentials are. The share of those eventually recovered tells you whether the dunning sequence lands. The gap between a cancellation request and the schedule stopping tells you whether your cancellation path is real or ceremonial.

Watch them by client segment. A single large retainer failing quietly is invisible inside a healthy-looking total, and it is the one you would most want caught the same morning.

Frequently Asked Questions

What is the difference between a subscription and a payment plan?

A subscription repeats the same amount at the same interval until someone cancels it. A payment plan splits a known total into a set number of charges and stops on its own when the last one clears. Building a payment plan as an open-ended subscription with a note to cancel it later is the most common way agencies end up overcharging a client who never checked.

How many times should a failed payment be retried?

Fewer times than most people expect, and spread over days rather than minutes. Retry the declines that genuinely change on their own — insufficient funds, a temporary hold, an issuer timeout. Do not keep retrying a card reported lost or stolen, a closed account or a revoked authorisation, because those will not clear and repeated attempts count against your merchant account.

Why do recurring charges fail when the same card works at checkout?

At checkout the cardholder is present and can complete an additional verification step if the issuer asks for one. A scheduled charge is merchant-initiated with nobody there to respond, so a challenge that would have been cleared in a second becomes a decline instead. It is also why the notification matters more than the retry: the fix usually needs the customer.

Should every client bill on the same day of the month?

Both approaches work, but choose deliberately. Billing everyone on their signup anniversary spreads failures across the month and keeps each client’s cycle easy to explain. A common billing day makes reconciliation simpler and concentrates every decline into one morning, which needs someone rostered to handle it.

What should happen in the CRM when a payment fails?

Something observable on the contact record, driven by a webhook from the billing processor rather than by a nightly report. Decide in advance which failure pauses delivery, which one removes access, and which only notifies a human. Without that mapping you get both failure modes: clients who stopped paying and keep receiving work, and clients who paid and got locked out.

Do dunning emails need different handling from marketing email?

Yes. They must be exempt from the suppression rules that keep marketing messages away from billing contacts, or the one email someone genuinely needs never reaches them. They should also send from an authenticated domain, since a filtered billing notice looks identical to a client who is refusing to pay.

How should cancellation be built?

So that it stops the schedule directly, without a human step in between. A cancellation that requires emailing someone leaves the customer with a faster alternative — their bank — and a disputed charge costs the fee, the admin and the relationship. Decide the notice period and whether the final period is served or refunded at the point you write the agreement.

What is worth measuring on a recurring billing setup?

The share of scheduled charges that fail on the first attempt, the share of those failures eventually recovered, and the delay between a cancellation request and the schedule stopping. Track them by client segment, because one large retainer failing quietly disappears inside a healthy-looking total.

We build your GoHighLevel account for you

CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.

• Setup (one-time)$850
• Ongoing (per month)$38.80

Get my free setup quote

No obligation quote · reply within 1 business day

This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.