The mistake to avoid: Do not assume the Stripe connection at agency level and the Stripe connection inside a client sub-account perform the same job. This guide covers the payment processor connected inside one location for collecting that business’s customer payments.
This payment guide is part of the GoHighLevel troubleshooting hub. The goal is not merely to make a green “connected” badge appear. It is to prove that money travels from the customer-facing checkout to the intended Stripe account, creates the expected record, and triggers the correct follow-up.
First, identify the Stripe connection you are actually setting up
HighLevel has several money-related settings, and their names can make them look interchangeable. They are not. A location’s Stripe integration is used when that business collects money from its own customers through supported HighLevel payment experiences. Agency billing, SaaS subscriptions, wallet charges, and rebilling are separate concerns.
| Money flow | Where it is configured | What it controls |
|---|---|---|
| Customer pays the local business | Sub-account → Payments → Integrations | Eligible invoices, links, order forms, calendars, stores, memberships, and other checkout surfaces |
| Agency charges a client | Agency billing or SaaS configuration | Software plans, agency services, and applicable rebilling |
| HighLevel usage costs | Billing and wallet settings | Platform subscriptions, wallet funding, and usage charges |
If a dentist is collecting a deposit from a patient, the dentist’s location needs the dentist’s Stripe account. If an agency is billing that dentist for software, that is an agency-to-client payment flow and should not be confused with the location’s customer checkout.
The five-minute preflight check
Most bad integrations begin with the right clicks in the wrong account. Before selecting Connect, record the following information:
- HighLevel location name and Location ID: confirm you are inside the intended client account, not Agency View or a similarly named test location.
- Stripe business name: know which legal entity should appear on payment records.
- Stripe account ID: record the identifier beginning with
acct_when available so you can distinguish accounts with similar names. - Payout destination: verify the bank account and payout schedule inside Stripe.
- Account readiness: resolve any Stripe verification, restricted-payment, or missing-information notices before launch.
Use a Stripe login owned by the business that will receive funds. Avoid building a client’s payment system around an employee’s personal credentials. The business should retain access if a contractor or agency relationship changes.
Security note: HighLevel’s connection process should send you through Stripe authorization. Do not paste secret API keys into a random form, email, support chat, or workflow field. Protect Stripe logins with multi-factor authentication and give staff only the access their roles require.
GoHighLevel Stripe sub account integration setup: step by step
Step 1: Enter the intended sub-account
From Agency View, select the client location that will collect payments. Pause and verify the location name. Account context matters here in the same way it matters during how to fix GoHighLevel Twilio A2P 10DLC registration: a successful configuration attached to the wrong sub-account does not solve the production problem.
Step 2: Open the Stripe integration
The most direct current route is:
Payments → Integrations → Stripe → Connect
HighLevel may also expose entry points through the sub-account Launchpad or Settings → Integrations. These routes lead to the same underlying objective: authorizing Stripe as the payment provider for that location.
Step 3: Authorize the correct Stripe account
Stripe opens an authorization flow. Sign in, choose the intended existing account or complete the requested onboarding, review the permissions, and approve the connection. If the login can access several Stripe businesses, compare the displayed business details with your preflight record rather than choosing by memory.
Return to HighLevel and confirm that Stripe now appears connected. According to HighLevel’s current documentation, one Stripe account can be connected to a sub-account at a time. Treat a disconnect-and-reconnect operation as a controlled change, not a casual troubleshooting click.
Step 4: Confirm identity on both sides
Open the connected-provider details in HighLevel and then inspect the corresponding account in Stripe. Confirm the business name and, when visible, account ID. A green status proves an authorization exists; it does not prove you selected the right recipient.
Configure how customers can pay
After connecting, go to Payments → Integrations and select Manage beside Stripe. Review the available payment-method controls and the product areas where each method may be offered. Availability can vary by country, currency, Stripe eligibility, HighLevel product surface, and the configuration associated with LeadConnector in Stripe.
Do not enable every method simply because it appears. Choose methods that your team can support and reconcile. Cards provide a familiar starting point. Additional methods may introduce different confirmation timing, refund behavior, dispute rules, or customer requirements.
Match the checkout to the product
Connecting Stripe does not automatically create an offer. You still need a correctly configured product or charge on the customer-facing surface. Review these items before publishing:
- Product name and customer-facing description
- One-time price versus recurring subscription
- Amount, currency, tax settings, and coupon behavior
- Trial period and future billing date, if applicable
- Order bump or upsell terms
- Success page and receipt expectations
- Cancellation, refund, and fulfillment language
For recurring offers, test the full subscription logic rather than judging success by the first charge alone. Confirm where the subscription is visible, what happens after a failed renewal, and which automation handles cancellation or delinquency.
An editable transaction-path chart
Customer submits an eligible HighLevel form, invoice, link, calendar payment, or store order.
The connected Stripe account evaluates and processes the payment attempt.
Payment and customer records appear in the appropriate dashboards.
Payment status triggers the intended receipt, access, notification, or follow-up.
A launch is complete only when all four boxes work. If Stripe receives the charge but the customer gets no access, the processor connection worked and the fulfillment layer failed. If no Stripe event exists, troubleshoot the checkout, selected provider, or authorization before rewriting the workflow.
Run a controlled end-to-end payment test
HighLevel features do not all expose a universal test-mode experience, so test the exact asset you will publish. When the intended surface requires a live transaction, use a small, clearly documented amount and refund it afterward if appropriate. Do not use a made-up card number on a live checkout.
- Create a test product or invoice. Use an unmistakable name such as “Internal checkout verification” and a small amount.
- Open an incognito browser. This reduces the chance that an administrator session hides a customer-side issue.
- Complete checkout as a real customer would. Review mobile layout, required fields, terms, price, currency, and confirmation.
- Inspect HighLevel. Confirm the contact, order or invoice, transaction status, and related opportunity or workflow behavior.
- Inspect Stripe. Confirm the same amount, currency, customer, payment status, and intended Stripe account.
- Verify fulfillment. Check the receipt, internal notification, tags, membership access, appointment status, and any post-purchase message.
- Test the exception path. Know what staff will see when a payment fails, is disputed, or is refunded.
Minimum launch evidence
Save the test date, HighLevel location, checkout URL, Stripe account ID, amount, currency, transaction identifier, workflow result, and refund result. This simple record makes later diagnosis much faster.
Troubleshooting the Stripe connection by symptom
| Symptom | Likely layer | First checks |
|---|---|---|
| Stripe does not show as connected | Authorization | Pop-up blockers, Stripe login permissions, incomplete onboarding, and whether you returned to the same HighLevel location |
| Checkout says no payment provider | Location or checkout configuration | Correct sub-account, connected-provider status, published version, and payment element settings |
| Payment lands in the wrong business | Account selection | Compare Stripe acct_ ID and business identity; pause traffic before reconnecting |
| Charge succeeds but workflow does not run | Automation | Published workflow, correct payment trigger, filters, product mapping, contact record, and execution logs |
| A payment method is missing | Method eligibility or channel support | HighLevel Manage settings, Stripe LeadConnector payment-method configuration, country, currency, and product-area support |
| Payment succeeds but payout is delayed | Stripe balance or payout | Stripe account status, available versus pending balance, payout schedule, bank verification, reserves, and notices |
When should you disconnect Stripe?
Disconnect only when you have verified that the authorization is wrong, the business is intentionally changing processors or accounts, or current support guidance requires it. Before disconnecting, document active funnels, recurring offers, invoices, subscriptions, saved payment behavior, and automations that depend on the provider. Existing Stripe subscriptions and historical transactions do not become a new account’s records merely because you connect a different Stripe account.
If transactions are active, choose a maintenance window and perform a new end-to-end test immediately after reconnection. A payment integration is operational infrastructure; changing it without an inventory can interrupt revenue.
Production launch checklist
- ☐ Correct HighLevel sub-account confirmed
- ☐ Correct Stripe business and
acct_ID confirmed - ☐ Stripe identity and bank requirements completed
- ☐ Payment methods intentionally configured
- ☐ Product name, amount, currency, tax, and billing frequency verified
- ☐ Checkout tested on desktop and mobile
- ☐ Transaction found in both HighLevel and Stripe
- ☐ Receipt, notification, and fulfillment automation verified
- ☐ Refund and failed-payment procedures assigned to a team member
- ☐ Live checkout URL recorded and monitored after launch
Build the checkout and follow-up in one platform
If you want to connect lead capture, appointments, payments, and automated follow-up, you can test GoHighLevel before committing your client workflow.
Start a GoHighLevel Trial
Affiliate disclosure: I may earn a commission if you sign up through this link, at no additional cost to you.
Frequently asked questions
Can each GoHighLevel sub-account connect its own Stripe account?
Yes. A sub-account can connect the Stripe account intended to process that location’s eligible customer payments. Current HighLevel documentation states that one Stripe account can be connected to a sub-account at a time.
Is a sub-account Stripe connection the same as agency SaaS billing?
No. The sub-account connection covered here processes eligible payments collected by the location. Agency SaaS billing and related client charges are configured separately.
Where is the Stripe integration in GoHighLevel?
Inside the intended sub-account, open Payments, choose Integrations, and select Connect for Stripe. HighLevel may also provide routes through Launchpad or Settings → Integrations.
Can I connect the same Stripe account to multiple locations?
The more important question is whether doing so matches the legal entity, bookkeeping, descriptors, tax treatment, products, and payout ownership for every location. Do not share a processor across unrelated client businesses merely for convenience. Confirm the intended account structure with Stripe and the businesses’ financial professionals.
Why is a payment visible in Stripe but not in a GoHighLevel workflow?
The processor and automation are separate layers. Confirm the workflow is published, the trigger matches the payment event and product, filters admit the test contact, and the execution log shows the event. A successful charge proves processing, not fulfillment.
Should I test the integration with a real payment?
Test the exact HighLevel payment surface you plan to publish. If that surface requires a live transaction, use a small authorized payment, document it, and refund it appropriately. Never enter Stripe test card numbers into a live checkout.
Final verification
A reliable GoHighLevel Stripe setup has three proofs: the intended location is connected to the intended Stripe account, the customer-facing checkout creates the correct transaction, and the post-payment automation performs the promised next step. Verify all three before increasing traffic.
For additional account configuration and failure diagnosis, return to the GoHighLevel troubleshooting guide. That keeps this page connected to its virtual-silo hub without creating a web of unrelated spoke links.
Sources and update notes
This tutorial was reviewed against HighLevel’s current Getting Started: Connect Stripe, sub-account connection instructions, and payment-method management guide. Interface labels and supported payment methods can change, so use the records shown inside your account as the final authority.
