GoHighLevel Checkout Orchestrator: Setup and Operations Guide

What GoHighLevel Checkout Orchestrator controls

The Checkout Orchestrator sits between the customer-facing checkout experience and the payment and order records behind it. Depending on the features enabled in the account, it can coordinate products, prices, one-time charges, recurring billing, payment methods, taxes, trials and offer-specific settings.

The key relationship is:

• Product: what is being sold.
• Price: how that product is charged, including amount, currency and billing interval.
• Offer: the commercial configuration presented to the customer.
• Checkout page: where the customer submits information and payment.
• Order or subscription record: the business record created after the transaction or billing event.

This distinction matters when a business has multiple funnels, plans or payment options. A checkout that works technically can still create operational confusion if two offers have similar names, a recurring price is attached to a one-time promotion or the sales team cannot identify what was purchased.

Prepare the account before creating an offer

Start by confirming that the sub-account has access to Payments or Billing and that the person configuring the system has permission to manage gateways, products and offers. Exact menu labels can change as GoHighLevel updates its interface, so use the account’s current Payments, Settings and Checkout Orchestrator areas as the source of truth.

Before changing settings, write down the intended commercial model:

• What is the customer buying?
• Is the charge one-time, recurring or a combination?
• Which currency should be used?
• Which payment methods should be available?
• What should happen after a successful payment?
• Who owns failed payments, refunds and customer questions?

These questions prevent a common systems problem: configuring the screen before defining the business state it is meant to create. If the offer is not clear in plain language, it is usually too early to build it in the platform.

Connect and verify payment gateways

Connect the payment gateways that match the checkout strategy. Stripe and PayPal are commonly available options in GoHighLevel, but availability and capabilities can depend on the account configuration and current platform support.

Stripe connection

1. Open the sub-account’s Payments or integration settings.
2. Select Stripe and choose the connection option.
3. Sign in to the relevant Stripe account and authorize the connection.
4. Return to GoHighLevel and confirm that the gateway appears connected or active.
5. Check whether the account is using live mode or a test mode before running transactions.

PayPal connection

1. Open the payment or integration settings.
2. Select PayPal and start the connection process.
3. Authenticate with the intended PayPal Business account.
4. Confirm the connected status in GoHighLevel.
5. Document which offers are intended to use PayPal if more than one gateway is available.

Do not treat a visible connection as proof that a checkout is ready. Confirm that the gateway, currency, billing type and test process are compatible with the offer. A gateway connection is an infrastructure dependency, not the checkout design itself.

Define products and prices as reusable building blocks

Create the product first, then add the price or prices that represent how it can be purchased. Keep names understandable to both the customer-facing team and the people reviewing orders later.

Create a product

1. Open the Products area within Payments.
2. Create a new product.
3. Enter a clear name and useful description.
4. Save the product before adding its pricing options.

Add a price

1. Open the product record.
2. Add the amount and currency.
3. Choose one-time or recurring billing.
4. For recurring billing, define the billing interval and any supported trial or limit settings.
5. Save and review the price before using it in an offer.

Use separate prices when the billing logic differs. For example, a monthly subscription and an annual subscription should not be treated as the same price with informal notes attached. Clear separation makes offer selection, reporting and customer support easier.

Avoid creating duplicate products for every funnel unless the commercial terms are genuinely different. Excessive duplication makes it harder to determine which record is current and can lead to inconsistent reporting.

Build the Checkout Orchestrator offer

An offer is the configuration that connects the product and price to the checkout experience. It should have a name that identifies the customer-facing proposition and, where useful, the funnel or campaign it belongs to.

1. Open Checkout Orchestrator from the Payments area.
2. Create a new offer.
3. Give it a specific name, such as the product, billing model and intended use.
4. Select the relevant product and price.
5. Choose the supported payment gateways.
6. Configure available trials, coupons, taxes, order bumps or upsell relationships according to the actual commercial process.
7. Save the offer and review every selected dependency.

Separate the main purchase from optional additions where the platform supports that distinction. A team should be able to answer what the customer bought by looking at the offer and order records, without reconstructing the transaction from page names or campaign notes.

Attach the offer to the correct checkout page

After the offer is ready, attach it to the funnel or website step where the customer completes the purchase. The exact editor and widget names may vary, but the configuration principle remains the same.

1. Open the relevant funnel or website.
2. Select the checkout step.
3. Open the checkout element or payment widget settings.
4. Select the intended Checkout Orchestrator offer.
5. Review the displayed product, price, payment methods and optional items.
6. Save, publish and record which page uses the offer.

Use a naming convention that makes the relationship visible. For example, a page, offer and internal fulfillment workflow can share a meaningful product identifier. This reduces the risk of changing an offer that is still used by another funnel.

Where the purchase should create or update CRM information, define the expected handoff. The payment event may need to trigger a confirmation message, fulfillment task, onboarding workflow or sales notification. For broader CRM architecture and pipeline ownership, see ConsultEvo CRM Consulting.

Test the complete payment and handoff path

Testing should validate more than whether a card can be charged. Use a controlled test transaction where the connected gateway supports it, then inspect the resulting records and notifications.

Document the expected result for each test. A useful test record states the offer used, the expected order status, the expected customer record and the person responsible for resolving an exception.

Manage orders, subscriptions and exceptions

Once live, review the Payments area as an operating queue rather than only a reporting screen. Orders should make it possible to identify what was purchased, when it was purchased and whether the next business step has been completed.

For subscriptions, monitor active, canceled and past-due states according to the account’s available features. Decide in advance who handles failed payments, customer requests, refunds and access changes. If no owner is assigned, the system can record the event without producing a timely response.

If additional systems must receive payment or customer data, use an integration only after the event and field mapping are understood. Automation platforms such as Zapier workflow automation can help connect systems, but automation should not compensate for unclear offer definitions or inconsistent source data.

Troubleshoot checkout problems by tracing dependencies

When a checkout fails, start with the dependency that is closest to the symptom. This is usually faster than changing several settings at once.

• Payment method unavailable: verify the gateway connection, account mode, currency and offer configuration.
• Wrong amount shown: inspect the selected price, recurring interval, taxes and optional items.
• Checkout page does not process the offer: confirm that the page is using the intended offer and that the latest version is published.
• Order record is incomplete: review required fields, product mapping and the event or workflow receiving the data.
• Subscription is not behaving as expected: check whether the offer uses a recurring price and review the gateway’s transaction state.
• Team cannot act after purchase: define an explicit notification, task or CRM ownership rule.

Change one dependency at a time and retest the full path. Multiple simultaneous edits make it difficult to identify the actual cause and can introduce new inconsistencies.

Maintain a reliable checkout operating model

Checkout configuration should be reviewed when products, prices, payment gateways, taxes, funnels or fulfillment processes change. Keep a simple record of active offers, the pages that use them, the billing model and the owner for exceptions.

For a growing operation, the Checkout Orchestrator is one part of a wider system that may include CRM records, fulfillment tasks, reporting and automation. ConsultEvo’s systems and automation services can help map those dependencies when checkout problems are symptoms of a broader process issue.

The practical sequence is straightforward: define the business state, configure the smallest set of products and prices that represent it, create a clear offer, connect the offer to the correct page, test success and failure paths, then assign ownership for what happens next. More checkout settings do not automatically create a better customer or operational experience.