GoHighLevel Stripe payment failed? Why it happens and how to fix it

When a Stripe payment fails in GoHighLevel, HighLevel is usually just the messenger. The charge is refused by the customer’s bank or by Stripe’s fraud screening, or it never gets that far because the checkout shows no usable payment method. Each of those has a different fix, and the decline code in your Stripe Dashboard tells you which one you are dealing with.

This guide covers the six problems I see most often on GoHighLevel accounts: a Stripe connection that is not really connected, declined cards, missing payment methods and wallets, Test vs Live mode mix-ups, 3D Secure, and subscription renewals that fail and never get recovered. Each section ends with the exact fix. Menu paths are as of October 2026.

Start with the decline code, not the order form

The order form only says the payment failed. The reason lives in Stripe. Open the Stripe Dashboard, go to Payments, filter by Failed, open the payment and read the decline code and the risk outcome. Then use this table:

What Stripe shows	What it means	Who fixes it
insufficient_funds	The card does not have enough funds	Customer — use another card
do_not_honor	The bank refused without giving a reason (network code 05)	Customer — call their bank
generic_decline	Declined for an unknown reason, or blocked by Stripe Radar	Check the risk outcome first, then the customer
authentication_required	The bank wants 3D Secure	You — let authentication complete (see below)
Blocked, reason highest_risk_level	Radar judged the payment too risky	You — review it, allow-list if genuine
No payment in Stripe at all	The charge never reached Stripe	You — connection, mode or payment-method setup

That last row matters most. If there is no attempt in Stripe, no amount of asking the customer to try again will help.

Cause 1: Stripe is not properly connected

HighLevel’s guide says each sub-account connects to one Stripe account at a time, and if Stripe does not show as connected after authorising, the authorisation was probably done by a Stripe user without enough permissions.

The fix:

1. In the sub-account, go to Payments > Integrations.
2. Next to Stripe, click Connect and sign in with the Stripe account owner (or an Administrator).
3. Authorise HighLevel and return to Payments > Integrations. The Stripe card should show as connected.
4. In Stripe, confirm the account has finished activation and can take live payments — an unverified account cannot charge real cards.
5. If you see “No such customer”, HighLevel says the usual causes are a deleted Stripe customer, a changed Stripe account, or a sub-account moved between agencies. For SaaS sub-accounts the documented fix is to disable and re-enable SaaS so the customer mapping is rebuilt. You also have to disable SaaS on dependent sub-accounts before you can disconnect a Stripe account.

Cause 2: the card was declined by the bank

For insufficient_funds, do_not_honor and plain generic_decline, the bank made the decision and Stripe’s guidance is the same: the customer contacts their issuer or uses another payment method. You cannot override it. What you can do is stop the customer leaving.

The fix:

1. Make sure the order form shows the error and lets the customer try again without re-entering everything.
2. Offer a second method — a wallet or another card — so a declined card is not a dead end (Cause 3 covers why methods go missing).
3. Send a recovery message. Build a workflow on the Payment Received trigger with the filter Payment status = Failed, which HighLevel recommends for follow-up and dunning. Add the Source filter to limit it to order forms.
4. Text or email a short note with a payment link:

Hi {{contact.first_name}}, your payment to Brightside Fitness didn’t go through — this usually means the bank wants you to approve it. You can try again here: [payment link]. Reply if you need a hand.

HighLevel’s articles disagree on whether the trigger fires on failed payments without filters, so test it with a declining test card before you rely on it. If workflows on this trigger are not firing at all, my guide to a GoHighLevel workflow not triggering covers the usual causes.

Cause 3: Stripe Radar blocked the payment

When generic_decline comes with a blocked outcome, the bank never saw the charge. Stripe blocks payments at the highest risk level by default, and the outcome reason reads highest_risk_level.

The fix:

1. Open the blocked payment in Stripe and read the risk insights — mismatched country, many cards tried from one IP, a disposable email.
2. If you know the customer is genuine, click Add to allow list on the payment. Stripe notes this does not retry the payment; it stops future blocks for that card or email.
3. Ask the customer to pay again from your order form or a fresh payment link.
4. Do not switch off Radar to “fix” declines. Card testing on a public order form is exactly what it is there to stop.

Cause 4: payment methods or Apple Pay are missing

This is the most misunderstood one. HighLevel states that Stripe renders the checkout element and decides which payment methods appear; HighLevel only controls whether a method is switched on at its end. Stripe hides methods based on your account’s default currency, the presentment currency, the payer’s location and IP address, and each method’s amount limits.

Wallets add their own rules. HighLevel’s Apple Pay and Google Pay article says Apple Pay shows only on Apple devices and Google Pay only in supported browsers with a valid card saved, and Apple Pay needs the funnel’s domain registered with Stripe.

The fix:

1. In HighLevel, go to Payments > Integrations, open the Stripe card and choose Manage Payment Methods. Switch on the methods you want.
2. In the Stripe Dashboard, open Settings > Payment methods, make sure the same methods are on, and click View details on any missing one to see its currency, country and amount limits.
3. For Apple Pay, open Payment method domains (Web Domains) in Stripe and check the exact domain the funnel runs on — pay.brightsidefitness.com, not just the root domain. Add it if it is missing. HighLevel calls this a quick fix and asks you to raise a ticket if the domain does not register automatically when you turn the toggle on.
4. Test on a real iPhone or Mac with a card in Wallet, and on Android Chrome for Google Pay. Desktop Chrome without a saved card will never show Apple Pay.

If the funnel’s custom domain itself is not connecting properly, fix that first — see GoHighLevel domain not connecting.

Cause 5: the checkout is in the wrong mode

HighLevel’s payment-method settings are configured separately for Test and Live, and a method enabled only in Test will not appear in Live. I regularly find funnels that were tested perfectly, then launched with an empty or half-empty checkout.

The fix:

1. Decide which mode you are configuring, and check the toggle in both Stripe and HighLevel before you change anything.
2. Repeat the Manage Payment Methods setup for Live — it does not copy across from Test.
3. Check the order form or payment link is using Live before launch.
4. Run one small real charge on your own card, refund it, and confirm it appears in Stripe under live payments.

Cause 6: 3D Secure and authentication_required

For card payments where both the business and the cardholder’s bank are in the UK or EEA, Strong Customer Authentication applies, and 3D Secure is how card payments meet it — banks may decline payments that skip it. Saved cards charged later (renewals, a workflow charge) are usually treated as merchant-initiated, but the bank still decides and can ask for authentication.

The fix:

1. Take the first payment on-session through a HighLevel order form or payment link, so the customer completes 3D Secure once and the card is saved for later.
2. Do not wrap the checkout in anything that blocks pop-ups or iframes — the bank’s challenge must be able to open.
3. When a renewal fails with authentication_required, send a payment link so the customer can authenticate, rather than retrying the saved card.
4. Test the flow with Stripe’s 3D Secure test cards before going live.

1. 1Read the decline codeStripe Dashboard > Payments > Failed.
2. 2Check the connectionPayments > Integrations shows Stripe connected.
3. 3Match Test and LiveEnable methods separately in each mode.
4. 4Register wallet domainsAdd the funnel domain in Stripe for Apple Pay.
5. 5Let 3D Secure finishAuthenticate on-session, then reuse the card.
6. 6Recover the failuresFailed-payment workflow with a pay link.

Failed subscription renewals: set up recovery

Renewals fail more often than people expect. Stripe’s own documentation says about 10% of subscription charges fail on the first try, and a well-run retry process gets much of that money back.

• Charges that fail first time10%
• Lapsed subscriptions caused by payment failure25%
• Failed payments recovered by Smart Retries57%

Three separate Stripe figures, not one funnel: first-attempt failure rate, the share of lapsed subscriptions due purely to payment failure, and Stripe’s average Smart Retries recovery rate.

Source: Stripe, Revenue recovery docs; Smart Retries blog; Billing features (as of October 2026)

Stripe says 25% of lapsed subscriptions are purely due to payment failures and that Smart Retries has helped businesses recover 57% of recurring payments that originally failed on average — Stripe’s figures about its own product.

In HighLevel, when a subscription payment fails, an invoice is generated and sent so the customer can pay with an existing or new card, and the charge is retried — by default three times, one day apart. If the customer pays the invoice first, the retries stop.

Where the charge comes from	Default retries	What happens after
Subscription	3 retries, 1 day apart	Stays Unpaid, or auto-cancels if you tick the box
Recurring invoice with auto-pay	2 more attempts, 24 hours apart	Must be paid manually
Stripe One Time Charge (workflow)	No documented retry setting	Error in Stripe; a user report says the workflow carries on

The fix:

1. Go to Payments > Settings > Subscriptions. HighLevel’s retry settings allow 1–3 retries with gaps of 1, 3, 5 or 7 days. HighLevel lists this setting for NMI, Authorize.net and Square, so on Stripe also check the revenue recovery retry settings in the Stripe Dashboard.
2. Choose whether a subscription stays Unpaid or moves to Cancelled after the last retry. I keep it Unpaid for a week so the customer can still pay.
3. Build the failed-payment workflow from Cause 2, filtered to subscription transactions, with an email and SMS on day 0 and day 3.
4. After any Stripe One Time Charge action, add an If/Else branch on the payment result so a failure stops the workflow and alerts your team, instead of sending a “thanks for your payment” message.
5. On SaaS Paywalls, the error “No default payment method found” means the customer must click Add Payment Method and enter a valid card; “Please update the billing address” means the postcode, address or CVV does not match the card.

Mistakes that keep payments failing

Keeps failing

• ✕Avoid: Telling every customer “card declined”
• ✕Avoid: Methods enabled in Test only
• ✕Avoid: Apple Pay domain never registered
• ✕Avoid: Retrying cards that need 3D Secure
• ✕Avoid: Workflow carries on after a failed charge

Gets paid

• ✓Do: Decline code checked in Stripe first
• ✓Do: Live configured and tested separately
• ✓Do: Exact funnel domain added in Stripe
• ✓Do: Pay link sent for authentication
• ✓Do: Failed branch stops and alerts the team

Two more I see often: switching off Radar after a run of blocks, which invites card testing, and connecting a Stripe account through a staff login that lacks permissions, which leaves the integration half-connected.

Getting payments working reliably

A dependable checkout in HighLevel comes down to four things: a properly connected Stripe account, Live mode set up and tested on its own, wallets with registered domains, and a recovery workflow for the payments that still fail. Once those are in place, most “Stripe isn’t working” reports turn out to be a bank decision you can recover with a single text.

If you would rather hand it over, I set up payments, order forms and failed-payment automations as part of GoHighLevel CRM setup, and build the checkout pages themselves through funnels and landing pages. If your clients are in different states, the locations pages show how I work with businesses across the US.