CodeCanyon HostBilling - WordPress Plugin

How to Configure CodeCanyon HostBilling for a Hosting Business

Think of CodeCanyon HostBilling as more than a place to issue invoices. It connects your service catalog, orders, payment gateway, hosting control panel, and client portal. A mistake in a plan name, API permissions, or payment email can cause a real operational problem: a service is sold but no account is created; payment arrives but the order remains inactive; or the client cannot find where to open a support ticket. This guide focuses on a practical rollout, with a clear way to verify each step.

This guide is for small hosting providers, digital agencies with recurring services, and administrators who need to connect hosting, domain, or service packages with billing and self-service. It assumes you have obtained the product legitimately and are installing it in your own environment. It does not cover purchasing, activation, or bypassing licensing. It focuses on configuring an existing system and safely checking that it works.

We’ll first define what HostBilling does and where its scope ends, then prepare the server and a backup, build the service catalog, set up a payment route, add a server or control panel, run a test order, and monitor the outcome. We’ll also cover the client portal, ticket handling, importing existing accounts, and tracing problems from the order through to the provisioned service. Some interface labels may vary by build, so treat them as pointers and verify them against the screens in your installation.

What HostBilling Does and Where Its Scope Ends

A hosting business usually has five separate workflows: presenting a plan, accepting an order, identifying the service owner, collecting payment, and giving clients a way to view invoices or ask for help. When each workflow lives in a separate spreadsheet, inbox, or custom form, staff have to move data between them by hand. HostBilling brings these pieces together around clients, orders, services, and invoices. The official product page confirms support for hosting plans and domains, recurring and one-time invoices, online payments, tickets, a knowledge base, files, and a client portal.

The practical benefit comes from predictable states, not simply from having more buttons. Each client has a profile and history; each order has a status; each invoice has a purpose; and each service is linked to a plan and, where an integration is configured, a server operation. This makes it easier to answer routine questions without guesswork: what was ordered, what period the invoice covers, whether the account was created, which email was sent, and who is handling the ticket.

Who the System Is For

HostBilling is a natural fit for an agency or hosting provider that sells recurring services, such as shared hosting, website maintenance packages, domain services, digital work, or fixed service plans. You can create service groups, add plans to each group, publish a pricing page, accept orders, and give clients access to a portal. For services that do not require an account to be provisioned, HostBilling can still serve as a catalog, CRM, and billing system: an order becomes an invoice, while a manager tracks the service status.

The system can also help as your support workload grows. Clients can view orders, invoices, and tickets in one portal instead of searching across different email addresses. A knowledge base does not replace support, but it can reduce repeat questions when it offers specific instructions: how to pay an invoice, where to find a domain, how to open a ticket, and what details to include. The biggest benefit comes from consistent statuses and notifications, not from the number of sections in the portal.

When to Consider Another Approach

If your company issues only one or two one-time invoices each month and does not sell recurring services, setting up a full billing workflow may take more effort than the task itself. If you need rack management, IP address management, a complex virtualization environment, or highly specialized usage-based billing, first assess your infrastructure and confirm with the developer that the required modules are available. Do not assume HostBilling can replace any set of enterprise systems simply because it includes invoicing and CRM features.

Also consider who is responsible for payments and infrastructure. The product can send clients to a connected gateway and generate documents, but it does not replace the requirements of your bank, payment provider, domain registrar, control panel, or local laws. Do not store secret keys in notes, screenshots, or email templates. Give HostBilling only the administrative access required for each integration.

Five Terms to Use Consistently

This table may seem obvious until your catalog starts to include similar names. Do not give a group, plan, and server package the same name, such as Business. Agree on distinct names in advance: for example, group Shared Hosting, plan Business 10 GB, and the exact server package name expected by the control panel. This consistency matters when an automation rule has to map a selected plan to a package in cPanel, Hestia, or another control panel.

The Service Lifecycle: From Storefront to Active Service

HostBilling is easiest to understand as a chain of states, rather than as a collection of unrelated menus. It starts when a client selects a plan or domain, then moves through the cart and checkout. The system creates or links a client, records the order, and generates an invoice. Payment follows through the selected route or a manual review. Fulfillment begins only after the agreed trigger: either a supported control panel automatically creates an account, or a staff member completes the work manually. The visible outcome is an active service in the portal, an invoice with a clear status, and a record in the history.

Automation does not mean that no one needs to be involved. It means that the transitions between states follow defined rules. The fewer implicit manual decisions inside a rule, the easier it is to understand why a workflow stopped. If your business requires an order review, make that step explicit: record the intermediate status and the staff role responsible for it. If a service should be activated only after payment is confirmed, verify that condition and do not create server access ahead of time.

Input: Catalog, Order Form, and Client Details

At the start of the workflow, keep marketing copy separate from operational data. The pricing page should give clients clear benefits, limits, and billing periods. The system needs an internal code, price, currency, billing period, tax rules, required domain fields, and a link to the technical package. The same plan can be presented as a clear offer to a buyer while using precise machine-readable settings in the admin area. That is fine as long as changes to the price or package are tested with an order.

Ask for only the details you need to fulfill the agreement, issue the invoice, and provide the service. Unnecessary required fields can discourage clients from completing checkout, while missing details lead to follow-up messages after payment. Domain services may require different contact information than a standard maintenance package. Do not make every buyer fill out domain-specific fields if they are purchasing only a digital service.

The Rule: Order, Payment, and Service Provisioning

State the main rule in one sentence that any staff member can repeat: “After payment is confirmed for an order with plan X, the system creates service X and performs the specified server operation.” This leaves no guesswork about which screen a staff member must visit or who is expected to remember a password. You can verify the rule with a test order.

HostBilling’s official materials describe one-time and recurring invoices, online payments, reminders, and control panel integrations. However, check the exact status sequence, activation trigger, and available automated actions in your build and control panel module. Do not assume that creating an invoice automatically creates a hosting account. First test a separate plan and observe what happens to the order, invoice, service, and server account.

Output: Evidence That the Workflow Completed

A green confirmation message in the admin area is not enough to prove that the workflow succeeded. Check at least three things: the order and invoice have the expected statuses in HostBilling; the service and invoice appear in the client portal; and the hosting control panel contains the account, or there is a record of manual fulfillment. For a service package that does not involve hosting, the third check might be an attached file, an assigned task, or a staff note, but it should still appear in the history.

A practical launch rule: do not publish the pricing page until one test client has completed the entire workflow and you can show evidence for every state. This is cheaper and safer than manually correcting dozens of real orders later.

What to Check Before Installation and Initial Setup

HostBilling is a standalone web application, even though the task list identifies its type as a “WordPress plugin.” Do not assume that you should install it through the WordPress Plugins area. Installation depends on the package and CloudOnex documentation: HostBilling is deployed on a server and has its own admin and client areas. Before deploying it, confirm the requirements for the release you received. In a post about a major update, the developer specified a minimum PHP branch and dropped support for an older branch. Check the installation package or current support materials for the exact extensions and web server settings you need.

Infrastructure Checklist Without Risky Assumptions

1. Set up a separate test environment. For the first run, use a test subdomain, a separate database, and test credentials for your payment provider, or a safe manual payment method.
2. Make a backup. Before an update, the developer recommends backing up both the files and the database. The same practice is useful before changing the theme, integrations, or invoice rules for the first time.
3. Check HTTPS, outbound email, and DNS. An invoice or portal link with an incorrect domain or mail setup can undermine client confidence and make actions harder to verify.
4. Prepare restricted API credentials for the control panel. Do not use a global personal admin password if the panel supports a more limited token with an IP restriction.
5. Define your test data. Keep one test plan, one test client, one placeholder domain, and one amount clearly separate from real operations.
6. Assign an owner to each area: catalog, finance, servers, email copy, and support. Do not assume one administrator is silently responsible for everything.

Pay particular attention to the system time and outbound email. An incorrect time zone can change payment due dates and the date of the next invoice. An SMTP problem may not prevent an order from being created, but it can keep the client from receiving a notification and turn a working process into a stream of support requests. After installation, send a test system email to an external mailbox. Check the sender, subject, link, and message body for exposed secrets.

What to Prepare Before Opening the Admin Area

Instead of gathering settings as you go, make a short register of the details you need: company name, legal details for documents, portal domain, support email, currencies, tax rules, service list, billing periods, accepted payment methods, servers, API tokens, required control panel packages, and staff list. This is not paperwork for its own sake. Any setting you leave undecided may end up on the wrong invoice or in a manual client conversation.

Do not store the register with tokens in a shared document. Record who is responsible and where the credentials are stored securely. In the working checklist, keep only the integration name and date checked. If a staff member leaves, this will help you identify what to revoke or reissue without exposing the secret values.

Does WordPress Need to Be Connected?

The product description does not indicate that WordPress is required for HostBilling. WordPress can be your main site for landing pages, articles, and a link to the portal, while billing remains a separate service with a clear boundary. Link from your site to the HostBilling storefront with a regular link or button instead of trying to embed the admin interface in WordPress pages. This separation simplifies updates, access control, and troubleshooting: a site issue is less likely to be mistaken for an invoice issue, and a billing problem is less likely to break your public blog.

Installation, First Login, and a Safe Start

Follow the instructions in your package and the developer’s documentation for the exact deployment process. CloudOnex’s public update article describes the general approach: make a full backup of the database and files before replacing files, then open the admin area so the application can apply the required schema changes. This article is not a substitute for the installation guide, but it highlights an important point: the application maintains its own database and migrations, so it should not be treated as a collection of static PHP files.

After your first login, do not start selling publicly. First set the company name, time zone, sender address, and administrator password. Check that anonymous users cannot access the admin URL and that regular clients cannot see internal links. If your system lets you create staff accounts and roles, give each person the minimum access they need. Support staff do not need access to payment settings, and knowledge base editors do not need server keys.

Your First Hour

1. Open the admin area over a secure connection and replace any temporary credentials in your environment.
2. Enter the company details, time zone, primary language, and date format, then check the result on a draft invoice.
3. Set up outbound email and keep the test message as evidence that you checked it.
4. Create one test client profile with a separate email address.
5. Add one test payment method or enable manual payment with clear instructions. Do not connect a live key yet.
6. Create one private test plan and confirm that it has not appeared in the public catalog.

If your package includes demo data, it can help you learn the interface, but it is risky to leave in a live system. Demo clients, amounts, service names, and emails can easily end up on real invoices. Remove or clearly label them before publishing the catalog. Do not treat a demo run as a complete setup: it proves only the workflow you actually tested.

Initial Checks by Role

Open the system in two separate browser sessions. Use one as an administrator and the other as a client. As the administrator, create a draft plan and invoice. As the client, confirm that you can see only the documents you are allowed to access and cannot open someone else’s record through a direct link. Then create a test ticket and check where its notification goes. This simple test often catches an incorrect sender address, an unintended public page, or a ticket assigned to the wrong department.

End your first hour with a brief record: who logged in, which test plan was created, where the email went, which portal address you checked, and what remains unconnected. This turns setup from a collection of memories into a repeatable process.

Service Catalog: Connecting Groups, Plans, and the Pricing Page

HostBilling’s official description suggests creating custom groups, such as Shared Hosting, VPS Hosting, or WordPress Hosting, and adding plans to each group. Those plans then appear on an automatically generated pricing page. This is a useful starting point, not a complete business model. First decide which services share the same purchase flow and technical rules. A group helps visitors choose a service category; a plan defines exactly what they are ordering.

Start with a small catalog. Three clear plans that complete the test workflow are more useful than twenty cards with unconfigured emails, payments, and server mappings. For each plan, prepare a public name, short description, billing period, price, currency, internal note, tax rules, and technical mapping. If a plan does not create a server account, state that clearly: “Fulfilled manually after payment is confirmed.”

Example of a Practical Catalog for an Agency

Suppose an agency sells website maintenance and hosting. You do not need to call everything “Services.” Create a Hosting group with plans named “Starter,” “Business,” and “Agency,” and a separate Website Support group with monthly packages. Clients can immediately tell whether they are buying infrastructure or staff time. Staff know what to check when handling an order: should they run a server operation or assign a task to a manager?

Use simple public names, but do not promise anything you cannot verify. Do not say “unlimited” if technical or contractual limits apply. Do not list exact control panel specifications until they have been mapped to a server package. The most common catalog risk is that polished copy promises something different from what the system actually provisions after payment.

Review Each Setting One at a Time

Domains and Add-On Services

HostBilling lists domain availability checks and WHOIS operations, and it can offer a domain with a hosting package. That means the domain workflow needs its own test. Do not publish the domain form just because it appears in the product description. Check which registrar or route is actually connected, which TLDs are allowed, what information is required, and what happens when a domain is unavailable.

Add-on services also need a defined outcome. SSL, website migration, extra work, a dedicated IP, or maintenance should not be just a checkbox with no clear next step. Each item needs an owner and a fulfillment trigger: an automated module, manual task, email, or history entry. If you cannot define that, the service is not ready to sell.

Invoices and Payments: Do More Than Check the Button

HostBilling supports one-time and recurring invoices, quotes, and online payments. CloudOnex documentation shows how to find the list of payment gateways through Settings. When one method is active, clients can pay the invoice directly. When several are active, they can choose an available route. This is useful, but safe setup starts before you enter a key: decide which currencies and taxes are allowed, which gateway serves each market, what counts as payment confirmation, and who handles exceptions.

Start with one method and one test invoice. The Stripe help material lists fields for the publishable and secret keys, currency code, and saving settings. Never copy these values into an article, email, or screenshot. Get test credentials from your payment provider, restrict the key’s permissions, and record who owns the integration. Add a second route only after the first test succeeds. Enabling multiple gateways without a clear plan gives buyers more choices and makes reconciliation harder.

Set Up Invoices as Part of the Client Experience

Before enabling live payments, create a draft invoice for a test plan and review it as a client would. It should clearly show the company, recipient, service, billing period, amount, currency, due date, and payment method. A confusing document can generate support requests even when the integration works. If your organization collects taxes, check them on a test amount with your accountant before sending real invoices.

Do not check a recurring invoice only when it is first created. Confirm which field indicates the next period, what happens when a service is canceled, how late payment is handled, and where staff can view the history. Do not promise automatic suspension or reactivation without testing the connected server module. The cPanel integration description mentions automatic suspension and reactivation after payment, but the outcome in your installation depends on the plan mapping, module, credentials, and activation rule.

Payment Route Test Matrix

1. Create a test invoice with one clear line item and confirm that the amount matches in the admin area, portal, and email.
2. Open the invoice as a client and confirm that only the intended payment methods are available.
3. Complete an approved provider test or mark the payment manually according to your procedure.
4. Return to HostBilling and check the invoice status, payment record, order status, and the next expected action.
5. Check the client portal and notification. The status should be consistent with what staff see.
6. Remove the test records or clearly label them so they do not end up in reporting.

Do not use a colleague’s real bank card as your only test. That does not prove that refunds, notifications, statuses, or recurring invoices work, and it leaves an unnecessary financial record in the live system.

Servers and Plans: Where the Technical Work Happens

One of HostBilling’s defining features is the link between a commercial order and a hosting control panel. The official cPanel instructions start at Services -> Servers, followed by New Server. For cPanel, you enter a name, a host without a port number, a username, and an API token. After saving, use List Accounts to check the connection. It should return the server’s account list. This is a good setup pattern: verify the connection before provisioning a service.

For Hestia, CloudOnex help describes enabling the API first and adding the server’s IP address to the allowlist. Then add the server through Services -> Servers and check the connection by viewing user data. In the plan’s automation settings, select the server and verify that the package name matches the one in Hestia. An exact match for the server package name is a critical check, not a cosmetic detail. If the names differ by even one character, the catalog may sell a plan the integration cannot provision.

Set Up the Connection with Least Privilege

Use a separate account or API token for the integration if your hosting panel supports it. Grant only the required permissions, restrict the source IP, use HTTPS, and keep a record of who created the key. These steps do not secure your entire infrastructure, but they limit the impact of a leak. Do not put the token in client templates, links, ticket attachments, or staff instructions.

Before creating a real order, test the connection on a test server or isolated package. Check the DNS name, certificate, network access, and API response. If the account list does not load, do not try to work around the problem by importing in bulk or creating orders again. Stop, fix the connection, and then continue.

Map Plans to Server Packages

Keep a small mapping table outside the public catalog: commercial plan, server, exact control panel package name, activation rule, verification method, and owner. For example, “Business 10 GB” might map to a specific package on a dedicated server. If you have several servers, document any default selection. Otherwise, staff may not know where the service should be provisioned, and the client may get an unpredictable outcome.

After mapping the plan, create a test order. The cPanel instructions say that Create Account appears on the order page, where you can enter the domain, username, password, email, and plan. Do not assume the suggested values are correct: the domain should match the test, the email should belong to the test client, and the plan should use the actual package name in WHM. Confirm that the account exists in the control panel, and do not send a password to the client in an email you have not verified as secure.

Importing Existing Clients Is a Separate Project

CloudOnex describes syncing cPanel accounts: the service can match them by email address, create a missing client, hosting plan, and order. The same note states a limitation: cPanel does not store the end client’s full name, phone number, or other details, so only the email address is imported. This is a good reason not to treat the sync button as a magic migration tool.

Back up your data and test a small sample before importing. Match email addresses, existing plans, paid periods, and owners. Check that running the sync again does not create duplicates. If the old system’s data is incomplete, normalize and review it manually rather than automatically creating hundreds of records you cannot interpret.

The Client Portal, Tickets, and Knowledge Base as One Support Workflow

The HostBilling client portal is for more than viewing invoices. The official product page says clients can view and manage invoices and orders, register, purchase digital services, create tickets, read the knowledge base, and work with files. Your goal is to make this path easier than contacting support, not simply to add more menu items.

Start with the three actions visitors actually need: pay an invoice, view an active service, and open a support request. Create one test for each: a new client can see the right service; a client with an unpaid invoice knows what to do; and a client can choose a department and provide the necessary context. Do not publish ten empty knowledge base sections. One accurate article with a screenshot of your process is more useful than a page of generic promises.

Keep the Ticket Queue Organized

At a minimum, group tickets by subject: payments and invoices, technical support, domains, and sales. That does not mean you need a large number of departments. Create a department only when responsibility changes. The product instructions mention client-created tickets, tickets created on a client’s behalf from the admin area, department assignment, attachments, and email notifications. Test a ticket and check the recipient address, notification to the author, and activity history.

Create a first-response template for each important type of request. It should not include secrets, but it should ask for the right details: invoice number, domain, time of the error, a screenshot without passwords, the error message, and steps already taken. This reduces back-and-forth and makes a ticket easier to hand off to another staff member.

Use the Knowledge Base to Prevent Repeat Questions

Start with the questions support answers most often: how to pay an invoice, where to find a service, how to change a contact, how to open a ticket, and what to include when a site is unavailable. Check each article in a private browser window and while logged in. Links should point to the pages in your installation, not someone else’s demo. If the interface changes after an update, include a knowledge base review in your update plan.

Roles, Client Data, and Access Boundaries

Billing systems store information that may seem ordinary on its own but becomes sensitive when combined: email addresses, order history, amounts, domains, support conversations, and sometimes attachments. Set up staff accounts and permissions before a large import or public launch. The principle is simple: staff should have access to the information and actions they need for their role today, not every feature that might be useful someday.

Even in a small team, it helps to distinguish four roles. The system owner changes global settings, server integrations, and payment keys. Finance staff create or reconcile invoices but do not get server tokens. Support staff can view clients, services, and tickets but should not change currencies or automation rules. Knowledge base and public page editors work with content without viewing other clients’ invoices. If your build supports granular roles, reflect these boundaries in the settings. If it does not, use a clear procedure, separate accounts, and a log of critical actions.

Keep Client and Staff Access Separate

Always test the portal in a separate browser profile. An admin session can hide a problem: a page may appear accessible because a logged-in staff member can see more than a buyer should. Create two test clients with different email addresses. Create an invoice and ticket under the first, then check with the second that direct links to those records do not open. This takes only a few minutes and gives you far more confidence than reviewing the interface as an administrator.

Login links and quick client access, if you use those features, need extra care. The official page mentions generating a URL for a client to log in. Treat that URL like a temporary key: do not put it in a public knowledge base, send it to a group chat, or show it in a screenshot. Decide in advance who can generate the link and how it will be shared. If you cannot share it safely, use your regular account recovery process.

Client Fields and Data Quality

Do not make every visitor fill out a long form for some hypothetical future benefit. Required fields should let you provide the service you promised and issue accurate documents. Divide fields into three groups: information needed for the account and communication, information required for a specific order, and information needed for a legal document. For each field, ask who enters it, where it appears, who can change it, whether it needs verification, and how long it should be kept.

Email addresses matter because they are used for communication and may be the matching key during cPanel sync. In the published import note, email is specifically used to find a client, while other details may not be available from the source. Before migration, remove obvious duplicates and test addresses, and fix inconsistent spelling. This will not make the source data perfect, but it will reduce the chance of creating multiple profiles for the same person.

Attachments, Logs, and Personal Data in Support

A ticket attachment can include more than you need to solve the problem: a control panel screenshot, configuration file, invoice, or contact details. The product instructions mention attachment support, so give staff a short policy in advance: do not ask for passwords or secret keys, do not forward attachments to personal chats, delete unnecessary test files, and tell clients how to hide sensitive details. This is an operational safeguard, not a guarantee of absolute security, but it can significantly reduce everyday risk.

Activity logs help you find the cause of an issue, not monitor staff. When a client says they cannot see a service, it helps to know who changed the order, whether an email was sent, which server was selected, and whether an import ran. Keep notes on critical changes brief and factual. Do not put passwords, full tokens, or unnecessary personal information in the log.

Email, Notifications, and a Clear Communication Workflow

Communication is part of the HostBilling workflow. The system can connect invoices, payments, tickets, and the client portal, but clients rely on emails to understand what happened, what they need to do, where to find a document, and how to get help. A confusing email can undo the value of a correctly processed order. Start with a short list of essential notifications, test them in an external mailbox, and expand the templates only after that.

Essential Events to Cover

• Registration or client creation. Explain the next step securely without revealing unnecessary information.
• New invoice. State what it is for, the amount, the due date, and include a clear link to the secure portal.
• Payment confirmation. Confirm that payment was received, but do not promise the service is ready if it still needs review or manual work.
• Service activation or readiness. Explain where to find the service and how to get help if it does not match the order.
• New ticket and reply. Confirm receipt of the request and keep the client informed.

For each email, ask: what should the recipient do in the next minute? If the answer is unclear, shorten the message. Save a long list of portal features for a welcome article rather than a payment notification. The service name and billing period should match on the invoice and in the email, or support may receive a question on the first day.

Check Sending and Deliverability

Check more than whether the email was sent. Confirm that it looks as expected in a common email client: a readable subject, a recognizable sender, a correct link, no truncated URL, and text that is easy to read on a small screen. Do not use real client addresses in your tests. It is better to set up a couple of internal inboxes for the implementation team.

If an email does not arrive, do not start by rewriting the copy. First check the sending settings, sender domain, spam folder, and logs if available. After making a change, test one invoice again. Sending in bulk after a partial fix is risky: clients could receive an incorrect address or a duplicate notification.

Reminders and a Human Tone

An invoice reminder should state the facts and what to do, without blaming the client. “Your invoice is awaiting payment. Open the document here” is better than a vague warning or an unclear “urgent” message. If your policy calls for suspending service after the due date, make sure the email matches your actual process and contractual terms. Do not enable automatic service restrictions until you have tested them on a separate plan and agreed on the process with the person responsible for support.

Create a separate, neutral message for bank transfers, manual payments, or document reviews that need time to process. This can prevent clients from trying to solve the problem by paying twice. CloudOnex’s payment gateway help describes a manual bank payment option with instructions and the ability to attach proof of payment. Your company still needs to decide who reviews the file, where they record the payment, and what they tell the client afterward.

Migration and Launch Without a Painful Cutover

Moving an existing hosting business to a new system rarely takes just one step. You may have old plans, duplicate email addresses, unclear balances, active domains, and clients who do not know the portal is changing. HostBilling can help with some steps, including cPanel sync, but migration still needs checkpoints. Recognizing that early makes it less tempting to click Import on launch day.

Four Waves for a Safer Transition

1. Inventory. Export clients, plans, active services, domains, billing periods, open tickets, and integrations. Record the source and quality of each field.
2. Test sample. Select a few anonymized or test clients representing different cases: new hosting, renewal, domain, manual service, and support request. Check the import and portal.
3. Run a parallel check. Confirm that the new system shows the same owner, plan, due date, and status, and that no technical actions run unexpectedly.
4. Limited launch. Move a small, controlled group or new orders first. Monitor the outcome, then expand only after the workflow is reliable.

Do not change the catalog, currencies, email domain, payment gateways, servers, and theme all at once. If something goes wrong, you will not know which change caused it. Make the changes in stages. For example, launch the catalog without automatic account creation, then connect one payment method, then one server integration. This does not slow the launch; it makes it possible to roll back.

Tell Clients About the New Portal

A migration notice should answer four questions: what is changing, what will stay the same, what the client needs to do, and where to get help. Do not send a temporary auto-login link in a group email. Instead, direct clients to the known portal domain and offer secure account recovery if your process supports it. Before sending the notice, walk through the process as a new client, an existing client, and a client with an unpaid invoice.

For the first few days after launch, pay extra attention to tickets such as “I can’t see my service,” “I didn’t get the email,” “Payment isn’t working,” and “I can’t log in.” These phrases help you group symptoms quickly. Do not treat them as isolated incidents: if three clients report the same issue, check the shared rule instead of editing each profile by hand.

Practical Example: Selling a Plan and Creating a Test Account

Let’s walk through a specific but safe example: a small agency sells a “Business Hosting” plan with monthly maintenance. The goal is not to test every feature at once, but to verify the full workflow for one service. Use a test domain, a test server package, and a separate client email address. Do not run this test on a customer’s real domain or enable live payments before you understand every status.

Goal and Preparation

Expected outcome: a test client selects a plan; the system creates an order and invoice; after an approved payment confirmation, a linked service is created; and the hosting control panel contains an account with the right package. In the portal, the client can see the invoice and service, while staff can view the history. Before you start, prepare a test group, test plan, server with a verified API connection, package with the exact name, outbound email, and test payment method.

Step 1: Create a Group and Plan

In the admin area, open the services section and create a group that clients will see. Add a test plan with a clear billing period, amount, and internal note. In the technical automation field, select the server and enter the package name that exists in the control panel. If your build presents the fields in a different order, do not guess what they mean based on their labels. Verify the result with a connection test.

Open the storefront in a private browser window. The plan should appear in the right group, with no unrelated test items. Check the description, currency, and billing period. This step tests visibility, the catalog, and whether the plan card is clear. If you already see the wrong amount, do not continue: the error will carry over to the order and invoice.

Step 2: Check Out as a Client

Create a new test profile or use one you prepared earlier. Add the plan to the cart, enter only the required details, and complete checkout. Record the order and invoice numbers. Return to the admin area and check that the client profile shows the expected order and that it has not been assigned the wrong server or plan.

At this point, look at the process from the client’s perspective. Are the total, billing period, status, and next step clear? Is there a link to the invoice? If the form asks for unnecessary information, note it as a task, but do not skip the check. A good purchase flow should not depend on a staff member explaining every button by hand.

Step 3: Confirm the Test Payment and Record the States

Complete an approved test payment or use a manual method according to your internal procedure. Then check more than one page. Open the invoice, order, client profile, and payment history. Each should have a logical status. If the invoice is paid but the order does not change, record it as a break between payment and fulfillment. Do not hide the problem by creating the account manually.

Check the email. It should link to the correct portal address, contain no integration keys, and avoid sending the password in an unsafe form. Follow your policy if credentials need to be shared separately. This guide does not assume a specific method for providing passwords; the right method depends on your control panel, policy, and notification setup.

Step 4: Create or Check the Service

If you use cPanel, the order should offer a way to create the account after the server and plan are configured correctly. Check the domain, username, email, and package. CloudOnex documentation emphasizes that the package must match an existing Web Host Manager package. After creating the account, verify it in cPanel and check the service record in HostBilling.

If your policy does not yet allow automatic provisioning, follow the same workflow with manual fulfillment. In that case, keep a clear record of who created the service, when they did it, which details they used, and where they verified the outcome. Manual work is acceptable as a temporary step as long as you do not present it as automation.

Step 5: Check the Portal and Prepare to Roll Back

Log in as the test client. Confirm that the client can see only their invoice, order, and service. Open the support page and create a test ticket. Then prepare to roll back: unpublish the test plan, remove or label the test records according to your procedure, cancel the test account in the control panel, and revoke any temporary token you used. Rollback is part of the test because it proves you can manage the workflow, not just complete the happy path.

Verify the Setup and Monitor It Without Constant Manual Checks

After setup, the most important skill is knowing how to distinguish a working system from a polished interface. Check HostBilling across four layers: commercial, financial, technical, and client-facing. The commercial layer confirms that the service is visible and the right order was created. The financial layer checks that the invoice, payment, and billing period match. The technical layer confirms that an account exists or manual work was completed. The client-facing layer confirms that the client can access the service and receives a clear notification.

Create a short recurring review routine. Daily or on your usual work cycle, check new orders with unclear statuses, overdue invoices, unassigned tickets, and integration errors. Periodically view the portal as a client and check email delivery. The right frequency depends on order volume, but the routine matters more than the frequency: look first for records stuck between states instead of browsing the logs at random.

Check After Every Configuration Change

Every change to the catalog, price, email, payment route, server, or portal theme needs a basic check. After changing a plan name, check the plan card and invoice. After changing SMTP settings, send an email. After replacing a control panel token, run a safe connection check. After an application update, check login, the catalog, an invoice, the portal link, a test ticket, and a safe request to the server module. This habit takes less time than investigating a client complaint after an error occurs.

Keep a simple change log with the date, person, change, test, outcome, and rollback. Do not record keys, passwords, or full personal details. If you find an incorrect rule a month later, the log can help you connect it to a configuration change without relying on memory.

What Counts as Sufficient Evidence

Sufficient evidence is more than a screenshot of one page. The relevant records should agree. If the invoice is marked paid, the client can see the service, and the server account has the right package, the workflow is better verified. If one layer does not match the others, do not close the issue. Saying “the client can see it anyway” is risky: the next renewal, suspension, or support request may expose the mismatch.

Safely Customize Documents and Appearance

Your installation does not have to look the same as every other provider’s. CloudOnex’s update announcement mentions changing the color scheme through Appearance -> Theme and provides a supported override for PDF invoices: copy or rename system/overrides/invoice_pdf.sample.php to invoice_pdf.php. This distinction matters: the override is separate from the core files, so it is easier to preserve during an update.

Do not edit the application core just to change a logo, color, or invoice field. First make a copy, then use the built-in theme setting or documented override. Create one test invoice and check it in the browser and as a downloaded document, then keep a copy of the original. If a change affects required business details or tax calculations, review it with the person responsible for your documents.

A Careful Invoice Template Override

This change follows the developer’s documented override method rather than relying on an invented API. It gives your company a separate file for customizations. Do not put payment keys, untrusted code, or arbitrary request data in it.

<?php
// File: system/overrides/invoice_pdf.php
// Basis: the built-in invoice_pdf.sample.php example.
// Change only the prepared copy, and test it with a test invoice first.

// Keep the example's structure and make only approved
// branding changes or changes to required business details.
?>

After saving the file, generate a test document and check readability, amount, billing period, business details, and whether it contains any unnecessary data. To roll back, temporarily move the new file out of the overrides folder according to your safe procedure, then generate another test invoice. Do not replace the original file without a backup.

Update Without Losing Context

CloudOnex recommends backing up the database and files before an update and keeping active configuration files when replacing an archive manually. Before updating, record the current version, date, database and files, active payment methods, server integrations, document overrides, themes, and most recent test order. Do not reopen sales immediately after the update. Check login, the catalog, one invoice, the portal link, a ticket, and a safe request to the server module. If something goes wrong, follow your rollback plan instead of mixing old and new files at random.

Troubleshooting: Where the Order-to-Service Workflow Often Breaks

With many HostBilling issues, the symptom appears in one place while the cause lies earlier in the workflow. Instead of clicking the button again, ask: at which transition did the expected state change? Check the steps in order: “catalog - order - invoice - payment - service - server - portal.” The cases below are supported by the product documentation or follow directly from its integration model.

A Plan Appears in the Admin Area but Not in the Storefront

Symptom: staff can find the plan, but an anonymous visitor cannot see the group or plan card. Likely cause: the plan is in the wrong group, is unpublished, is hidden by the portal theme, or is being checked in an authenticated session with special permissions. Check: open the link in a private browser window and compare the group, visibility, currency, and display order. Fix: correct the group assignment and visibility settings, then repeat the anonymous check. Rollback: if the terms are not confirmed yet, unpublish the plan instead of leaving it in a half-finished catalog.

An Invoice Was Created, but the Client Did Not Receive an Email

Symptom: the document exists in the admin area, but the test client’s inbox is empty. Likely cause: outbound email is not configured or not delivering, the sender address is wrong, the email went to spam, or the template is inactive. Check: send a test system email to an external address and check the folders and logs available in your installation. Fix: correct SMTP settings and create another test invoice. Rollback: do not send bulk reminders until you can reproduce a successful test delivery.

The Provider Shows a Payment, but the Invoice or Order Status Did Not Change

Symptom: the payment provider reports a successful payment, but HostBilling still shows the invoice as unpaid or the order has not advanced. Likely cause: the gateway is misconfigured, test and live environments do not match, a callback is missing or inaccessible, the currency is wrong, or a staff member has not confirmed a manual payment. Check: compare the test invoice number, amount, currency, payment record, and integration log if available. Fix: correct the test key settings and try one test invoice again. Rollback: temporarily remove the problematic method from the public options so new clients do not get stuck.

The Server Is Added, but List Accounts Returns No Data

Symptom: HostBilling saves the server, but does not show the expected accounts. Likely cause: an incorrect FQDN, network access, TLS, API token, username, or permission set. The cPanel instructions specifically say to enter the host without a port number. Check: compare each setting with the control panel, check the token’s expiration and IP restriction, and do not post credentials in a ticket. Fix: create a new restricted token and safely test the account list again. Rollback: revoke the old token if you cannot confidently say where it was stored.

The Order Is Paid, but No Account Is Created

Symptom: the invoice is paid, but the service has not appeared on the server or account creation fails. Likely cause: the plan is mapped to the wrong package, no server is selected, the activation rule has not reached the required status, or the server module is not connected. Hestia help says to select a server in the automation settings and ensure that the package names match. Check: compare the exact names, open the order, confirm that the API is available, and check that the package exists in the control panel. Fix: correct one mismatch, then create a new test order instead of rerunning the same record without understanding its history. Rollback: remove any incorrectly created test account and return the order to the agreed manual process until the integration is fixed.

cPanel Sync Created Incomplete or Duplicate Clients

Symptom: the import creates records with only an email address or creates duplicate clients. Likely cause: cPanel provides only a limited set of fields, and matching is based on email. The developer notes this limitation explicitly. Check: compare a small sample of email addresses, plans, and orders before running a bulk sync. Fix: stop the bulk import, define normalization rules, and test with a small group. Rollback: restore a backup or remove only the records you have confirmed are test data, using a list you prepared in advance.

The Client Sees the Wrong Service or Cannot Open a Ticket

Symptom: the portal does not show the expected order, support is unavailable, or the test client has access they should not have. Likely cause: the client is not linked correctly to the order, permissions are wrong, the ticket department or portal is misconfigured, or the test is using an admin session instead of a real client account. Check: repeat the workflow in a separate browser profile using a test client. Fix: correct the link or access settings, clear the test cookies, and log in again. Rollback: if there is a risk of exposing someone else’s documents, temporarily restrict the portal and review permissions before continuing sales.

When HostBilling Is a Good Foundation for Your Workflow

CodeCanyon HostBilling can be a good choice if you need one manageable workflow from a hosting or digital service listing through invoicing, the client portal, support, and, when an integration is confirmed, a server action. Judge it by more than the number of pages in the demo. Check how smoothly a test order moves through the catalog, payment, service, and verification.

Start with one plan, one payment method, one test client, and one server. Once this basic workflow is repeatable, gradually add domains, a second gateway, migration, and other services. If you are ready to run this test, you can download the installation package and deploy it in an isolated environment without putting existing clients at risk.