Connecting GoHighLevel to Stripe: Payments, Subscriptions and Failed-Payment Recovery (2026)
Connecting GoHighLevel to Stripe: Payments, Subscriptions and Failed-Payment Recovery (2026)
Most GoHighLevel accounts I audit have Stripe connected but barely used. The card capture works, money lands in the Stripe balance, and that is roughly where the thinking stops. Nobody has wired the integration into Workflows, nobody is tagging paying customers, and when a subscription card declines the only signal is a quiet drop in monthly recurring revenue three weeks later. The payment processor is doing its job; the platform around it is asleep.
This guide walks through connecting Stripe to GoHighLevel properly: not just taking a payment, but building Products, collecting through order forms, payment links and invoices, automating off payment triggers, and standing up a failed-payment recovery sequence so declined cards get chased instead of forgotten. I have set this up for Australian service businesses billing in AUD, and the difference between a connected Stripe account and an organised one is usually a measurable chunk of recovered revenue each month. None of this is tax advice, and where GST comes up I am pointing at the settings, not telling you how to lodge.
Why connect Stripe to GoHighLevel at all
You can take a Stripe payment from a standalone Stripe payment link without GoHighLevel ever knowing. The problem is that the payment then lives in a silo. The contact record in GHL does not get tagged, no Workflow fires, the opportunity does not move down the pipeline, and your fulfilment, onboarding and receipting all have to be triggered by hand. Connecting Stripe properly means a successful payment becomes an event your automation can react to.
Once the integration is live, a paid order can tag the contact, add them to a nurture or onboarding Workflow, move their card along a pipeline, grant access to a members area, and send a branded receipt, all without anyone touching it. That is the whole point: the payment stops being an endpoint and becomes a trigger. If you have already organised your sales process into stages, connecting payments lets you close the loop between "deal won" and "money received" inside the same system.
Connecting your Stripe account step by step
The connection itself is genuinely quick. The discipline is in doing it on the right account and testing before you go live.
Make the connection
In your sub-account, go to Payments > Integrations. You will see Stripe listed as a connection option. Click connect, and you will be redirected to Stripe to authorise the OAuth handshake. Log in to the correct Stripe account, confirm, and you are returned to GoHighLevel with the integration showing as connected. Make absolutely sure you are connecting the Stripe account that belongs to the client or business, not your agency account, and that the Stripe account currency is set to AUD if you are billing Australian customers. Currency is a Stripe-side setting and cannot be changed after the account has processed live charges, so check it first.
Test mode before live
Stripe runs in test mode and live mode. Before you publish a single order form, switch your Stripe dashboard to test mode and run a transaction using Stripe's test card numbers. Confirm the payment shows in GoHighLevel, confirm the contact is created or updated, and confirm any Workflow you have built actually fires. Stripe webhooks are what carry the payment event back to GHL, so if your test payment succeeds in Stripe but nothing happens in GoHighLevel, the webhook or the trigger is where you look. Only once a test order flows cleanly end to end do you switch to live and reconnect if required.
Building Products: one-time and subscription
Payments in GoHighLevel are organised around Products. A Product is the thing you are selling and it carries the price, the currency and, critically, whether the charge is one-time or recurring.
One-time Products
A one-time Product is a single charge: a strategy session, a setup fee, a digital download. You create it under Payments > Products, set the price in AUD, and decide whether to add tax. If you are registered for GST, this is where you set the relevant tax behaviour so the 10 per cent is handled consistently rather than reverse-calculated later. Set it once at the Product level and every order form using that Product inherits it.
Subscription (recurring) Products
A subscription Product is a recurring charge: a monthly retainer, a membership, a payment plan. When you create it you set the billing interval (weekly, monthly, annually) and, if relevant, the number of cycles for a fixed-term payment plan versus an open-ended membership. Subscriptions are where failed payments come from, because cards expire and balances run dry, so any recurring Product is a candidate for the dunning sequence later in this guide. If you are using recurring Products to gate memberships, courses or a client portal, the subscription status becomes the thing that controls access, which makes recovery even more important.
Collecting payments: order forms, payment links and invoices
There are three main ways to actually present the charge to a customer, and they suit different situations.
Order forms inside funnels
An order form is a payment element you drop onto a funnel or website step. You attach one or more Products to it, configure bump offers if you want them, and the customer pays in the flow of a funnel. This is the right choice for self-serve checkout: a lead lands on a sales page, clicks through, and pays on the next step without you involved. The order form submission and the payment are both events you can automate against.
Payment links
A payment link is a standalone hosted checkout you can send by SMS or email. It is ideal when a salesperson has agreed a price on a call and just needs to get the card details without building a funnel. You create the link against a Product and send it; the payment still flows back into GoHighLevel and still triggers automation.
Invoices
Invoices suit businesses that bill after work is agreed or delivered. You raise an invoice against a contact, add line items, optionally set it to recur, and GoHighLevel sends a payable invoice the customer settles via Stripe. Invoices give you a clearer paper trail and are the natural fit for B2B and professional services billing in AUD where a tax invoice is expected.
Automating with Workflows on payment triggers
This is where the integration earns its keep. GoHighLevel exposes payment events as Workflow triggers, and each one is a hook for automation.
The core triggers you will use are Payment Received (a successful charge), Order Form Submission (someone completed an order form, paid or otherwise), and the subscription and failed-payment events that fire when a recurring charge succeeds, fails, or a subscription is cancelled. On a Payment Received trigger you can filter by the specific Product so a "Strategy Session" purchase runs a different Workflow from a "Monthly Retainer" subscription.
A practical first build: Payment Received for your onboarding Product adds a tag, creates or advances an opportunity in your pipeline, sends a receipt and onboarding email, and starts a welcome sequence. If your delivery lives outside GHL, you can pass the payment event to other tools through a Zapier or Make automation bridge rather than trying to force everything into native Workflows. The table below maps the common events to the actions worth attaching to them.
| Payment event (trigger) | Typical Workflow actions | Why it matters |
|---|---|---|
| Payment Received (one-time) | Add "Customer" tag, send receipt, start onboarding sequence, move opportunity to Won | Turns a sale into fulfilment without manual handoff |
| Order Form Submission | Tag the attempt, notify sales if no payment follows, retarget abandoners | Catches near-misses and abandoned checkouts |
| Subscription Payment Success (recurring) | Confirm renewal, extend membership access, log MRR continuation | Keeps active members in good standing automatically |
| Subscription Payment Failed | Tag "Payment Failed", enter dunning sequence, alert account manager | Triggers recovery before the revenue is lost |
| Subscription Cancelled | Remove access tag, start win-back, update opportunity | Closes the loop cleanly and opens a save attempt |
Building a failed-payment recovery (dunning) sequence
Dunning is the polite, systematic chasing of failed recurring payments, and it is the single most under-built part of every Stripe-plus-GHL setup I see. Stripe will retry a declined card on its own schedule (Smart Retries), but Stripe only talks to the card. It does not email your customer from your brand, tag them, alert your team, or pause access. GoHighLevel does all of that, which is why you build the dunning sequence in Workflows on the Subscription Payment Failed trigger rather than relying on Stripe alone.
The shape of a good sequence is a few timed touches across email and SMS that get progressively firmer, give the customer an easy way to update their card, and end with a clear consequence. The intent is recovery, not punishment, so the early messages assume an innocent expired card rather than a deadbeat. The timeline below is a sensible default for a monthly AUD subscription.
The mechanics: the failed-payment trigger applies a "Payment Failed" tag and drops the contact into the dunning Workflow. Each step sends a message containing a link for the customer to update their payment method. If a later Subscription Payment Success fires, a separate Workflow removes the "Payment Failed" tag and pulls them out of the sequence so they are never chased after they have already paid. That tag-removal step is the one people forget, and it is the difference between a recovery system and an embarrassing one.
Reconciling and reporting
Two systems hold payment data now, and they need to agree. Stripe is the source of truth for money actually settled; GoHighLevel is the source of truth for who the customer is and what automation ran. Reconcile by checking that every successful Stripe charge has a corresponding paid order and triggered Workflow in GHL, and that subscription counts match between the two. If a charge exists in Stripe but no Workflow fired, your webhook or trigger filter is the culprit.
For reporting, lean on tags and pipelines. A "Customer" tag, a "Payment Failed" tag, a "Recovered" tag and a "Churned" tag give you instant segment counts. Mirroring subscription status into a pipeline lets you see active, at-risk and churned subscribers as opportunity stages, which makes recovered-revenue and churn reporting visual rather than a spreadsheet exercise. If you have built a pipeline to set up and forecast revenue, feeding subscription health into it gives you a far more honest forecast than new sales alone.
Common mistakes to avoid
- Connecting the wrong Stripe account, usually the agency's instead of the client's, then having to disconnect, reconnect and rebuild every Product.
- Going live without running a test-mode transaction, so the first real customer is your QA process.
- Setting the Stripe account currency to USD by accident, then discovering it cannot be changed and Australian customers are paying in the wrong currency.
- Building no automation on Payment Received, so paying customers get no receipt, no tag and no onboarding.
- Relying on Stripe's retries alone for failed payments and never building a branded dunning sequence in Workflows.
- Forgetting the tag-removal step, so customers who update their card keep getting chased after they have paid.
- Ignoring GST behaviour at the Product level and trying to reverse-calculate tax across messy orders at lodgement time.
If you want your Stripe payments, subscriptions and failed-payment recovery fully wired up in GoHighLevel, book a strategy call with the HL Growth Partner team.
Frequently asked questions
Can I connect more than one Stripe account to a single GoHighLevel sub-account?
No. Each GoHighLevel sub-account connects to one Stripe account through Payments > Integrations. If you need to bill from a different entity, that generally means a separate sub-account with its own Stripe connection. Plan your account structure around this before you start taking live payments.
Will GoHighLevel handle GST on my AUD payments?
GoHighLevel can apply tax at the Product level so the relevant rate is added consistently to each charge, and Stripe records the amounts. How you account for and lodge GST is a matter for your accountant; the platform organises the data, it does not advise on tax. Set the tax behaviour at the Product level so it stays consistent across every order form and payment link.
What happens to a subscription if a customer's card keeps declining?
Stripe runs its own retry attempts, and each failure can fire the Subscription Payment Failed trigger in GoHighLevel, which feeds your dunning Workflow. If the card is never updated and the subscription ultimately ends, the Subscription Cancelled event fires, letting you remove access and start a win-back. The recovery and the consequence are both automated.
Do I have to use funnels, or can I just send a payment link?
You do not need a funnel. Payment links and invoices let you collect payment without building any funnel, and both still flow the payment back into GoHighLevel so your Workflows, tags and pipelines all fire exactly as they would from an order form. Use whichever suits the sales motion: order forms for self-serve, payment links for call-closed deals, invoices for B2B billing.
Why did my Stripe payment succeed but nothing happened in GoHighLevel?
Almost always the webhook connection or the Workflow trigger. The payment succeeded in Stripe, but the event did not reach a published Workflow, or the trigger had a Product filter that excluded the charge. Reconnect the integration if needed, confirm the Workflow is published, and check that any Product filter on the trigger actually matches the Product purchased.
