Subscription and Payment Automation for Service Businesses

Most failed payments fix themselves once the client knows about it. The card expired, the bank flagged the charge as unusual, or the client switched accounts after a move and never updated their payment method. A short automated sequence catches all three situations within a few days, and the client usually updates their card before they've even thought about canceling. That is the entire premise of payment automation: get to them first, make it easy to fix, and recover the revenue before anyone has to pick up the phone.

This post covers the full billing lifecycle for service businesses running subscription or retainer plans: pre-renewal reminders, failed-payment dunning, the update-payment-method flow, and how a cancellation branch plugs into the end of all of it. It's part of a broader series on business automation for service companies.

Why do most failed payments happen in the first place?

Failed payments are almost always passive, not intentional. The card expired, the bank flagged it, or the client switched cards and forgot to update their information. That distinction matters because it shapes how you respond. A client who wants to leave will behave differently than one who simply has an outdated card on file. When we wire up payment sequences, the data across those builds consistently shows that a three-touch dunning sequence recovers the large majority of failures before the client even realizes there was an issue. The failure was never a signal of dissatisfaction; it was administrative noise.

The three most common root causes:

• Expired card. Issuers replace cards every two to three years. If you billed successfully for two years and then hit a wall, this is almost always it.
• Temporary bank hold or fraud flag. Banks auto-flag recurring charges above certain thresholds, especially if the client traveled recently or changed spending patterns. A single retry two days later often clears this without any action from the client.
• Account change. A client closed a checking account, refinanced, or got a new card after a fraud event. They likely forgot they had a subscription tied to the old one.

Knowing the cause doesn't change the automation logic much, but it does change the tone of your messages. You're writing to someone who probably wants to stay and just needs a nudge to update their card, not to someone who is actively leaving.

Should you send a pre-renewal reminder before charging clients?

Yes, and it reduces disputes more than almost anything else in the billing stack. A pre-renewal reminder sent five to seven days before a charge gives clients time to update an expiring card before the billing attempt runs. It also reduces surprise disputes from clients who forgot they had a recurring charge, which is more common than most business owners expect.

A simple two-message pre-renewal flow looks like this:

• Seven days out: A short heads-up that their renewal is coming. Include the amount and the card on file (last four digits). Give them a direct link to update payment information if anything has changed.
• Three days out: A lighter reminder. At this point you're mostly catching people who missed the first message or who just got a new card in the mail.

Keep these short. Long billing emails get ignored. One sentence on what's happening, one sentence on what to do if their payment info changed, and a link. That's it.

How do you structure a dunning sequence after a payment fails?

A dunning sequence is the automated series of actions that runs after a payment attempt fails. It has three components: the retry logic, the client notification, and the update-payment-method link. All three need to work together for the sequence to recover revenue effectively.

A practical starting structure:

• Day 0 (failure): Log the failure. Fire an immediate SMS and email notifying the client that payment did not go through. Include a direct link to update their card. Keep the tone neutral, not alarming.
• Day 2: Retry the charge automatically. If it clears, send a payment-confirmed message and exit the sequence. If it fails again, send a second notification. This one can be slightly more direct: "We tried again and it didn't go through. Here's the link to update your payment method."
• Day 5: Final retry. If this one fails, send a third notification. At this point it's worth mentioning that their service may be paused if the payment isn't resolved, depending on what your contract allows. This creates mild urgency without being aggressive.
• Day 7 (if still unresolved): Branch to the cancellation or service-pause flow, covered in the next section.

Spacing the retries two to five days apart is intentional. Back-to-back retries on the same failed card rarely succeed and can trigger additional fraud flags. Giving the client 24 to 48 hours between notifications also gives them time to act before you retry.

How does the update-payment-method link actually work?

The update-payment-method link is the most important part of the dunning sequence. A client who receives three messages about a failed payment but has no easy path to fix it will do nothing, not because they don't want to, but because friction kills follow-through.

The link should take them to a pre-filled, branded page where they can enter a new card without logging into anything, digging through a portal, or calling your office. In GHL, this is a form connected to your payment processor that updates the card on file and triggers a confirmation email when complete. The client clicks a link in a text or email, enters their new card details on a mobile-friendly page, and they're done in under a minute.

When we build these flows, we test the update link on mobile every time before the sequence goes live. Most clients who receive a dunning notification are reading it on their phone. If the update page requires a desktop or has form fields that are hard to tap, recovery rates drop noticeably.

What should happen at the end of an unresolved dunning sequence?

If the payment still hasn't been resolved after your final retry and notification, the workflow needs to branch. There are two distinct situations at this point: clients who request to cancel before or during the dunning process, and clients who simply go silent after all three messages.

The voluntary cancellation branch handles clients who reach out to say they want to stop service. This is where cancellation flow automation comes in. That branch typically includes a retention sequence: an acknowledgment of the request, a brief check-in about what wasn't working, and a pause offer or downgrade option before the actual cancellation is processed. Not every client who says they want to cancel actually wants to leave. Some are reacting to a billing surprise or a service hiccup.

The exhausted dunning branch (silent client, three failed payments) is different. Here the right move is usually a service-pause notice. Inform them clearly that their subscription has been paused due to non-payment, explain exactly what that means for their access or service delivery, and give them a single link to reactivate by updating their card. Set an internal task for a team member to follow up by phone if the account value warrants it.

Keep these two branches completely separate in your workflow builder. The tone, offers, and outcomes are different enough that mixing them creates confusion on both sides.

Can you build this inside GHL without a separate billing tool?

Yes. GHL's native payment features combined with its workflow builder can handle the full sequence described here: pre-renewal reminders, retry logic, client notifications, the update-payment-method form, and the cancellation branch. This is one of the places where service businesses consistently over-complicate their stack by adding a separate subscription billing platform when GHL already covers the need.

The key pieces inside GHL:

• Payment triggers: GHL fires workflow triggers on payment success, failure, and subscription cancellation events. These are the entry points for every branch in the sequence.
• Retry logic: You can configure retry attempts directly in the payment settings or use a time-delay step in the workflow to trigger a manual retry action after a set number of days.
• Update-card form: A GHL funnel page with a payment form element can be configured to update the card on file for an existing subscription. Pair it with a unique contact link so the client doesn't need to log in.
• Conditional branches: GHL's IF/ELSE conditions let you route contacts based on whether a payment succeeded, failed, or was resolved within a time window.

Where GHL gets complicated is in businesses that have high transaction volumes or need detailed revenue reporting broken down by plan type. In those cases, a dedicated billing tool (Stripe Billing, for example) handles the financial data better, and GHL handles the communication layer. But for most service businesses running under a few hundred active subscriptions, the native setup is more than enough.

What does this look like for a business actually running it?

A med spa running monthly membership plans was handling failed payments manually before their automation was in place. Two staff members were spending meaningful hours each week identifying which memberships had failed, drafting individual emails, and then following up again when clients didn't respond. The practice owner described it as "the task nobody wanted to own" because it felt like collections work even when the clients weren't actually delinquent.

Once a standard dunning sequence was wired up, the workflow handled the entire process. The client gets a text within minutes of the failure, a follow-up two days later if they haven't acted, and a final notice before the service pause deadline. The staff members who were managing this manually now see it only when a contact reaches the end of the sequence without resolving. The escalations that actually need a human are a fraction of what they were before, and most of those are voluntary cancellation conversations rather than failed payment chases.

This connects directly to the value of retention automation more broadly: a subscription you almost lost because of a billing glitch is not the same as a client who wants to leave, and your systems should treat them differently from the first message.

How should you name and organize these workflows?

Billing workflows accumulate fast once you start building them out. A pre-renewal reminder, three dunning messages, a retry trigger, a service-pause notice, and two cancellation branches is already six or seven individual workflows or branches depending on how you structure them. If they're all named vaguely, your team will have no idea which one to inspect when something goes wrong.

A convention that works across the systems we've built: prefix every billing workflow with BILLING / followed by the trigger and the action. Examples: BILLING / Pre-Renewal Reminder 7d, BILLING / Failed Payment Notify Day 0, BILLING / Dunning Retry Day 2, BILLING / Cancel Branch - Voluntary. When a client contacts your team about a billing issue and a team member needs to find the relevant workflow fast, a consistent naming convention makes that possible without a 10-minute dig through a list of unnamed automations.

For a complete picture of how these billing sequences fit into the larger automation architecture, the client onboarding automation sequence shows how the payment setup step connects to the rest of the client lifecycle from day one.