GoHighLevel Stripe Integration: Payments, Subscriptions & Failed Payment Recovery (2026)

If you sell anything inside GoHighLevel — a one-off service, a recurring membership, or a full SaaS subscription — Stripe is almost certainly the engine taking the money. Connecting it is the easy part. What separates a tidy payments setup from a leaky one is everything that happens after the card is charged: how you handle subscriptions, what you do when a payment fails, and whether your reporting actually reconciles against Stripe at the end of the month. I've set this up dozens of times for Australian agencies and SMBs, and the same gaps appear again and again.

This guide walks through the full lifecycle: connecting Stripe to a sub-account, building one-time and recurring products, wiring order forms with bumps and upsells, sending invoices and text-to-pay links, and — most importantly — building a failed payment recovery (dunning) flow with Workflows so you stop bleeding revenue from declined cards. I'll also cover the bits that catch Australian operators specifically: AUD currency, GST, and how SaaS Mode rebilling changes the picture. Everything below reflects how GoHighLevel and Stripe behave in 2026.

Connecting Stripe to a GoHighLevel sub-account

Stripe connects at the sub-account level, not the agency level, which means every location you take payments from needs its own connection. Inside the sub-account, go to Payments > Integrations, find the Stripe card, and click Connect. You'll be redirected to Stripe to authorise the OAuth connection. If you already have a Stripe account, log in and authorise; if not, you can create one in the flow. Once connected, GoHighLevel can create Payment Intents, manage subscriptions, and read transaction data through Stripe's API.

A few things to check straight away. Confirm the connected account's default currency is AUD before you create a single product — changing currency after the fact on a Stripe account is painful and sometimes requires a new account. Confirm you're connecting the live Stripe account and not a sandbox if you're going live. And if you deliver sub-accounts from a snapshot, note that the Stripe connection itself is never carried in a snapshot for security reasons — products, order forms and Workflows come across, but the payment integration must be reconnected per client.

One-time vs recurring (subscription) products

Products live under Payments > Products. When you create one, you choose a price type: one-time for a single charge, or recurring for a subscription billed on an interval (weekly, monthly, quarterly, annually). A single product can hold multiple prices, so you can offer monthly and annual options on the same item. For recurring prices you can also set a trial period in days, which Stripe honours before the first real charge lands.

Where products get used

Products plug into order forms, invoices, and (if you're running SaaS Mode) your rebilling plans. The key mental model: GoHighLevel products are a wrapper around Stripe Prices. When a customer buys a recurring product, GoHighLevel creates a real Stripe Subscription, and Stripe — not GoHighLevel — owns the billing schedule, proration, and retry behaviour. That distinction matters a lot when we get to failed payments.

Order forms, order bumps and upsells

Order forms are built inside funnels. You drop the Order Form element onto a step, attach your product(s), and the form renders a Stripe-powered checkout. Two revenue levers worth using deliberately: order bumps (a tick-box add-on shown on the checkout itself) and one-click upsells (a post-purchase offer on the next funnel step that charges the already-stored card without re-entering details). Done well, these lift average order value without adding friction.

If you want a deeper build walkthrough of bumps and upsell sequencing, I've covered the funnel-level mechanics in a separate guide on GoHighLevel order forms and upsells. The short version: keep the bump cheap and complementary, make the upsell genuinely additive, and always tag buyers so your fulfilment and follow-up Workflows know exactly what was purchased.

Invoices and text-to-pay

Not every sale runs through a funnel. For quotes, deposits and ad-hoc billing, use Payments > Invoices. You can build a one-off invoice or a recurring invoice schedule, attach products, apply a discount, and send it by email. The text-to-pay option sends the payment link by SMS through your LeadConnector/Twilio number, which closes far faster than email for high-intent leads — people pay an invoice from their phone in seconds. Invoice status changes (sent, paid, void) are available as Workflow triggers, so you can automate reminders for unpaid invoices and a thank-you sequence once paid.

Subscription management

Active subscriptions appear under Payments > Subscriptions, where you can view status, cancel, or let a customer manage their own plan. Because the subscription lives in Stripe, you can also manage it from the Stripe Dashboard — both stay in sync. For self-service, give customers a way to update their card; the cleanest approach is a Stripe customer portal link or a card-update funnel step, so they can fix an expired card without contacting you. Reducing that friction is the single biggest lever on involuntary churn, which leads us straight to the most important section.

Failed payment recovery (dunning)

Most lost subscription revenue isn't customers choosing to leave — it's involuntary churn: expired cards, insufficient funds, and bank declines. Stripe will retry failed charges on its own schedule (Smart Retries), but if you rely only on Stripe's default emails, recovery is poor. The fix is to layer your own dunning sequence on top using GoHighLevel Workflows.

The core trigger

Build a Workflow with the Payment Failed trigger (under payment/order triggers). When a recurring charge declines, this fires and the contact enters your recovery sequence. From there:

• Add a tag like payment_failed so the contact is segmented and visible across the sub-account.
• Send an immediate SMS via Twilio/LeadConnector: short, friendly, with a direct card-update link. SMS outperforms email here every time.
• Send a parallel email via Mailgun with the same update link as a fallback.
• Use Wait steps to space follow-ups across Stripe's retry window — typically day 1, day 3 and day 5 — so your reminders land alongside Stripe's automatic retries rather than fighting them.

Closing the loop

The mistake I see most is a recovery flow that never stops nagging someone who has already paid. Add a second Workflow on the Payment Received (or subscription-renewed) trigger that removes the payment_failed tag and uses a Workflow goal or "remove from other Workflows" action to pull the contact out of the dunning sequence the moment their card clears. For accounts with volume, a Conversation AI bot can handle the inevitable "I've updated my card, has it gone through?" replies without a human stepping in. If a subscription ultimately can't be saved after all retries exhaust, route the contact into a win-back pipeline rather than letting them vanish.

SaaS Mode and rebilling implications

If you run SaaS Mode, payments get a second layer. Your clients pay you through your agency Stripe connection for their software plans, while their own customers pay through the client's Stripe connection inside their sub-account. Rebilling for Twilio, Mailgun, email, and AI usage is metered on top. That means a failed payment can happen at two levels — an end customer's subscription, or your client's SaaS plan — and they need different recovery logic. A client whose card fails risks losing their whole sub-account, so that dunning flow should be more aggressive and tied to a clear suspension policy.

Getting the rebilling markup and plan structure right is its own topic; I walk through it in detail in the guide on SaaS Mode pricing and rebilling. And because involuntary churn is the silent killer of any SaaS book, the dunning principles above pair directly with the broader tactics in this piece on SaaS Mode churn reduction.

AUD currency, GST and Australian tax considerations

Set your product prices and Stripe account currency to AUD from the outset. For GST, decide whether your displayed prices are GST-inclusive (the norm for B2C in Australia) and price accordingly — GoHighLevel's tax settings under Payments let you define tax rates and apply them to products and invoices, and the GST line will appear on the invoice. If you're registered for GST, your Stripe payout and GoHighLevel transaction records become the source data for your BAS, so keep them clean. Note that Stripe's processing fees are themselves subject to GST in Australia, which matters when you reconcile net payouts. If you sell internationally, be deliberate about whether GST applies to overseas customers — that's a question for your accountant, not your funnel builder.

Test mode vs live mode

Always validate a new payment setup in test mode before flipping to live. In Stripe, test mode uses separate test API keys and the well-known test card numbers (such as 4242 4242 4242 4242 for a success, and dedicated numbers that simulate declines so you can prove your Payment Failed Workflow actually fires). Run a one-time purchase, a recurring subscription, an order bump, and a deliberate decline end to end. Confirm tags apply, SMS and email send, and the contact exits the dunning flow on success. Only once that full loop passes should you connect the live account and run one small real transaction as a final smoke test.

Reconciliation and reporting

At month-end, your GoHighLevel Payments > Transactions view should reconcile against your Stripe Dashboard. GoHighLevel records the order and customer context; Stripe records the authoritative money movement, fees, refunds and payouts. Reconcile the two regularly so you catch mismatches early — a subscription that's active in GoHighLevel but cancelled in Stripe, or a refund issued in Stripe that your Workflows never reacted to. For reporting, lean on tags and custom fields set during purchase so you can segment revenue by product, plan, and acquisition source, and feed clean payment events into your pipelines.

Stripe events mapped to GoHighLevel automation

Common mistakes to avoid

• Connecting a test Stripe account and forgetting to swap to live — or going live without ever testing a declined card, so the Payment Failed Workflow has never actually run.
• Setting the Stripe currency to USD by default when your business and customers are in AUD, then discovering you can't easily change it.
• Building a dunning sequence with no exit — it keeps texting customers who already paid because nothing removes the payment_failed tag on success.
• Relying solely on Stripe's built-in retry emails and assuming recovery is handled; your own SMS-led sequence recovers far more.
• Expecting a snapshot to carry the Stripe connection across to a new client sub-account — it never does, and the integration must be reconnected each time.
• Ignoring GST on prices and invoices, leaving messy records that make BAS reconciliation a nightmare at quarter-end.

If you want help setting up Stripe payments, subscriptions and failed-payment recovery inside GoHighLevel, book a strategy call with the HL Growth Partner team.

Book Your Strategy Call →

Frequently asked questions

Can I connect Stripe at the agency level instead of per sub-account?

No. Stripe connects at the sub-account level under Payments > Integrations, and each location you take payments from needs its own connection. Your agency Stripe is separate and is used for billing your SaaS clients, not for processing their customers' payments.

Does GoHighLevel or Stripe control subscription billing and retries?

Stripe does. When a customer buys a recurring product, GoHighLevel creates a real Stripe Subscription, and Stripe owns the billing schedule, proration and automatic retry (Smart Retries) on failed charges. GoHighLevel's role is to react to those events with Workflows — which is exactly how you build effective failed-payment recovery on top.

How do I recover a failed subscription payment automatically?

Build a Workflow on the Payment Failed trigger. Tag the contact, send an immediate SMS and email containing a card-update link, and space follow-ups across Stripe's retry window. Add a second Workflow on Payment Received that removes the tag and pulls the contact out of the dunning sequence as soon as their card clears.

Will my Stripe connection transfer when I load a snapshot?

No. Snapshots carry products, order forms, funnels and Workflows, but never the Stripe payment connection itself, for security reasons. You must reconnect Stripe in Payments > Integrations for every new sub-account before it can take payments.

How do I handle GST on GoHighLevel payments in Australia?

Set your account and product currency to AUD, then configure tax rates under the Payments tax settings so GST is applied and shown as a line item on invoices. Decide whether your displayed prices are GST-inclusive, keep your transaction and Stripe records clean for BAS, and confirm international GST treatment with your accountant.