V1 · V2 · Plans · Billing · Provisioning
GoHighLevel SaaS Mode
Use GoHighLevel SaaS Mode with a clear understanding of the current V1 and V2 architectures: where products live, which payment providers are supported, how checkout provisions sub-accounts, how snapshots attach, and how rebilling and subscription changes behave.
This page owns the SaaS Mode architecture and platform mechanics. General setup, pricing strategy and reselling each have separate pages.
We use current HighLevel behavior rather than older assumptions that every SaaS plan is Stripe-only.
SaaS Mode Architecture Process
SaaS Mode Intent
Separate the platform architecture from the broader SaaS business model
The parent GoHighLevel SaaS page covers product, operations and commercial strategy. This page focuses on what SaaS Mode does inside HighLevel.
GoHighLevel SaaS setup is the hands-on setup workflow; SaaS Mode explains the architectural choices those steps depend on.
The most important current distinction is SaaS V1 versus SaaS V2.
SaaS V1
Understand the Stripe-centered architecture before modifying legacy plans
In current HighLevel documentation, SaaS V1 uses Stripe as the system of record and Stripe as the payment provider. It is appropriate for established Stripe SaaS setups and supports behaviors tied closely to Stripe subscription management.
Existing V1 agencies should not migrate only because a newer architecture exists. We inventory current products, price IDs, customers and automation first.
GoHighLevel Stripe integration should remain healthy when V1 relies on Stripe.
SaaS V2
Use HighLevel-managed products when broader provider and CRM integration are required
SaaS V2 manages SaaS products inside HighLevel and supports a broader payment-provider architecture, including supported Marketplace payment providers. This can be useful for markets where Stripe is not the preferred provider.
Current V2 rules differ from V1 in areas such as subscription management and billing interval changes, so customer-facing promises must reflect the selected architecture.
GoHighLevel integrations should be reviewed when a custom or regional payment provider is part of the plan.
Parallel Operation
Run V1 and V2 side by side when staged migration is safer
Current HighLevel guidance allows V1 and V2 to operate together. That enables agencies to leave stable legacy customers on V1 while launching new offers or providers through V2.
We label products, customer cohorts and operational procedures clearly so staff know which billing system to inspect when a client asks about subscription changes.
GoHighLevel SaaS implementation can manage a staged migration or mixed-architecture rollout.
Plan Categories & Levels
Use hierarchy to structure product progression
Current SaaS Configurator uses categories and levels to organize related plans and influence upgrade/downgrade relationships. Currency and hierarchy should be defined before plan sprawl begins.
GoHighLevel SaaS pricing owns the economic strategy, while SaaS Mode owns how that hierarchy is represented in the platform.
Existing customers may retain current entitlements when hierarchy changes, so edits are reviewed for future upgrade paths rather than assumed to rewrite every active subscription.
Checkout & Provisioning
Let SaaS Mode create the sub-account after successful purchase
Current SaaS checkout can create a sub-account, apply an attached snapshot, send onboarding access and set active or trialing subscription status.
GoHighLevel SaaS automation can add internal workflow actions around the built-in provisioning sequence.
We test real production-compatible checkout because test-mode payment or incomplete product setup can prevent sub-account creation.
Snapshots
Use plan-linked snapshots to standardize the initial account configuration
A SaaS plan can apply a snapshot when the sub-account is provisioned. GoHighLevel snapshots should therefore be version-controlled and tested before the plan is sold.
The snapshot provides reusable configuration but does not eliminate customer-specific integrations, credentials or domain work.
We treat snapshot version as part of the SaaS product release so account delivery stays consistent over time.
Rebilling
Understand agency wallet, pass-through and markup rules
HighLevel rebilling can pass supported usage charges to sub-accounts. Current pricing guidance distinguishes pass-through at cost from markup, with agency-plan eligibility and product-specific rules.
GoHighLevel SaaS pricing should define whether usage is included or separately charged.
We verify client payment methods and service-level rebilling settings before usage grows, because enabling a feature does not guarantee the cost is being recovered.
Upgrade & Downgrade
Design customer plan changes within current architecture constraints
Current HighLevel supports configurable plan hierarchy, client upgrade settings and downgrade flows. V2 currently has interval constraints for changes between monthly and annual billing on existing subscriptions.
We document effective date, feature changes and customer communication before enabling self-service plan changes.
GoHighLevel SaaS automation can support notifications and lifecycle tasks around plan changes.
Mode Governance
Keep one architecture map for plans, providers and customer cohorts
We maintain a table showing every SaaS plan, V1/V2 type, provider, currency, snapshot, rebilling rule and active customer cohort. This becomes the support team's first reference when billing questions arise.
GoHighLevel CRM reporting can complement subscription data with activation, support and customer-success outcomes.
Architecture changes receive controlled testing because one plan edit can affect future upgrades, provisioning or margin even when existing customers appear unaffected.
V1/V2 Decision Framework
Choose architecture from existing subscriptions, payment market and lifecycle requirements
A new agency with no legacy subscriptions can choose SaaS architecture from its preferred payment provider, currencies and subscription operations. An established agency needs an additional question: what happens to the customers already on V1 products and Stripe subscriptions? We map current products, price IDs, billing intervals and client accounts before deciding whether new plans should stay on V1, move to V2 or operate in parallel.
SaaS V2's broader provider architecture can be valuable for agencies serving markets where Stripe is not ideal. GoHighLevel PayPal integration is a separate payment-provider page for supported HighLevel payment use cases, while SaaS V2 can also use supported Marketplace payment providers. Provider availability is confirmed in the current SaaS Configurator rather than assumed from general Payments support.
We also consider lifecycle rules. If an agency relies heavily on a specific proration or interval-change behavior, that requirement is tested against the chosen architecture before sales promises are written. The architecture decision should be visible in the support runbook so billing questions reach the correct system of record.
A mixed V1/V2 environment is manageable when naming and ownership are disciplined. Plan names, customer cohorts and support procedures identify the architecture clearly, reducing the chance that staff tries to fix a V2 subscription in Stripe or treats a V1 client like a HighLevel-managed V2 product.
Mode Change Control
Review plan hierarchy and customer entitlements before modifying active SaaS products
Plan categories and levels can influence future upgrade and downgrade behavior. Current HighLevel guidance notes that moving or reordering plans changes hierarchy relationships without necessarily rewriting existing subscriber entitlements. That means a Configurator edit can have a bigger effect on future customer journeys than on the clients you inspect immediately afterward.
We document the intended hierarchy before changing it and compare each adjacent tier. GoHighLevel SaaS pricing should provide the commercial reason for the progression, while SaaS Mode ensures the platform hierarchy reflects it. If a higher tier inherits a feature after a reorder, that feature should be part of the pricing promise.
Downgrade settings also deserve governance. HighLevel can collect downgrade reasons and offer configured deflections in supported flows. Those tools are useful only when the customer still receives accurate information about effective date, feature access and billing. Retention tactics should not make the subscription state ambiguous.
We run a test upgrade or downgrade on a controlled account after significant plan-hierarchy changes. That test confirms billing, entitlement and customer experience before a real client uses self-service controls.
Architecture Support Playbook
Give support a clear diagnostic path for subscription questions
A customer saying “my plan is wrong” can describe several different problems: payment failed, entitlement changed, upgrade is pending, the account is on a different V1/V2 architecture, or the snapshot did not contain the expected asset. We create a support sequence that starts with subscription architecture and plan status before staff change features manually.
For V1 customers, the support team knows which subscription details remain tied to Stripe. For V2 customers, the team checks the HighLevel-managed SaaS product and applicable provider. GoHighLevel SaaS setup for agencies should define who is allowed to make billing or entitlement changes after diagnosis.
We also log exceptions rather than normalizing them. If staff repeatedly need to repair the same plan transition, the SaaS Mode configuration or hierarchy should be corrected at the product level. A support playbook is useful not only for faster tickets but also for identifying systemic architecture problems.
Implementation QA
Validate V1/V2 ownership, provider, plan hierarchy, provisioning, rebilling and subscription-change rules
- V1/V2Is the SaaS architecture explicit for every plan?
- System of recordDoes the team know where product/subscription truth lives?
- ProviderIs the payment provider supported for the chosen architecture?
- HierarchyAre categories and plan levels intentional?
- SnapshotIs the correct snapshot attached and tested?
- ProvisioningDoes successful checkout create the account?
- RebillingAre supported usage charges configured intentionally?
- UpgradeDoes client upgrade behavior match plan hierarchy?
- DowngradeAre downgrade timing and deflection rules understood?
- CohortsCan support identify whether each client is V1 or V2?
Implementation Process
How we implement GoHighLevel SaaS Mode
Map architecture
Identify existing customers, providers and V1/V2 requirements.
Configure SaaS Mode
Build categories, plans, features, snapshot and rebilling.
Test subscription events
Validate checkout, account creation, upgrades and downgrades.
Document operations
Create a support map for providers, cohorts and lifecycle rules.
Common Questions
GoHighLevel SaaS Mode FAQs
What is GoHighLevel SaaS Mode?
It is HighLevel's agency functionality for packaging platform access into SaaS plans with billing, provisioning and related controls.
What is SaaS V1?
V1 is the Stripe-centered SaaS architecture with Stripe as the system of record.
What is SaaS V2?
V2 manages SaaS products in HighLevel and supports a broader payment-provider architecture.
Can V1 and V2 run at the same time?
Yes. Current HighLevel guidance says they can run side by side.
Can SaaS V2 use non-Stripe payment providers?
Yes. Current V2 supports multiple providers, including supported Marketplace payment-provider integrations.
Can SaaS Mode create client sub-accounts automatically?
Yes, configured checkout can provision the sub-account after successful payment.
Can a snapshot be attached to a SaaS plan?
Yes. The snapshot can be automatically applied during provisioning.
Does SaaS Mode support rebilling?
Yes, supported usage can be rebilled subject to agency-plan and product rules.
Can clients upgrade or downgrade?
HighLevel supports configurable plan-change flows, with rules that vary by architecture and plan hierarchy.
Do you provide GoHighLevel SaaS Mode services?
Yes. We configure and document V1/V2 architecture, plans, billing, snapshots, rebilling and lifecycle behavior.
Know Which SaaS Architecture Owns Every Customer
Configure SaaS Mode around current V1/V2 behavior instead of legacy assumptions
We can map SaaS V1/V2, plans, providers, snapshots, rebilling, checkout, upgrades, downgrades and operational governance.