There is no honest flat price for a custom WHMCS module. The cost follows six things you can write down before anyone quotes: the module type, how good the provider's API documentation is, how many admin and client-area screens you need, the currency, tax and refund edge cases, the testing you want, and the upgrade work. Describe those and you can get a real quote.
Last reviewed 9 October 2026. Disclosure: I sell custom WHMCS module development, so I am not a neutral source. I have 13+ years of experience and have built 200+ custom WHMCS modules. This post has no price list on purpose. A number without your scope would be a guess, and I would rather you could see what moves the number.
What decides the cost of a custom WHMCS module?
Six drivers decide it, and the module type is only one of them. Two jobs of the same type can differ a lot once the other five are counted. This table is what any developer, me included, is weighing when they read your brief.
| Driver | Why it changes the cost | What to have ready |
|---|---|---|
| Module type | Each type has its own set of functions that WHMCS calls, so a payment gateway and a small hook are very different jobs. | The type, or a plain description of what should happen. |
| Quality of the third-party API docs | Clear documentation with a sandbox lets the developer build and test quickly. Missing endpoints, vague error messages or no test environment mean trial and error, and that time has to be paid for somewhere. | A link to the docs, sandbox credentials, and a contact at the provider if you have one. |
| Admin and client-area screens | Every settings page, button, table and form needs layout, validation and permission checks. A module with no screens is cheaper than one with a dashboard. | A list of screens and who sees each one: staff or customer. |
| Multi-currency, tax and refund edge cases | The normal case is quick to build. Partial refunds, duplicate notifications, currency conversion, tax-inclusive prices and failed renewals are where most of the logic goes. | Which currencies, tax rules and refund policy you use. |
| Testing and staging | A staging copy, test orders, test payments, renewals and suspensions, and a written test record take real time. Skipping them does not remove the cost; it moves it to your live billing. | Whether you can provide a staging copy, and who signs off the result. |
| Upgrade-compatibility work | Keeping everything inside module and hook folders, with no core edits, and checking it against your WHMCS and PHP versions is what lets it survive upgrades. | Your WHMCS and PHP versions, and how soon you usually upgrade. |
How does the module type change the scope?
Each module type is a different contract with WHMCS, and the size of that contract is the first thing I look at.
- Provisioning (server) module. Lives in
modules/servers/. WHMCS calls functions such asCreateAccount,SuspendAccount,UnsuspendAccountandTerminateAccountwhen an order is paid, an invoice goes unpaid or a customer cancels. Scope grows with each extra action, with plan changes, and with buttons in the client area. - Payment gateway. Lives in
modules/gateways/, with a callback file inmodules/gateways/callback/that receives the provider's payment notifications. It touches money, so refunds, duplicate notifications and currency handling are part of the job, not extras. - Registrar module. Lives in
modules/registrars/. It registers, transfers and renews domains, manages nameservers and syncs expiry dates. Registrars differ in contact rules and TLD-specific requirements, which is where the surprises are. - Addon module. Lives in
modules/addons/. It adds its own admin pages and client-area pages and often its own database tables. Scope is mostly screens, reports and permissions. - Hook-only change. A PHP file in
includes/hooks/that reacts to an event and has no settings screen. Usually the smallest job, until it needs a settings page; then it is really an addon. My WHMCS hooks guide explains where that line sits.
Should you ask for a fixed quote or an hourly rate?
Ask for a fixed quote when the scope is written down, and for hourly work when it is not. My rate is $55-$65 per hour, or a fixed quote per scope, and I use each in different situations.
| Question | Fixed quote | Hourly |
|---|---|---|
| Fits when | Scope and acceptance test are written, and the provider's API is documented. | The API is unclear, the scope will change as you learn, or you need small changes over time. |
| Who carries an overrun | Usually the developer, inside the agreed scope; changes to scope are re-quoted. | You. |
| What to watch | Anything not written down becomes a change request. A very low fixed price may simply leave things out. | No cap. Ask for an estimate, regular progress reports and a review point. |
A common middle path is a short, separately paid discovery step to read the API and write the scope, followed by a fixed quote for the build. An hourly rate is not the cost of the module. It tells you what an hour costs, not how many hours the job needs, so compare quotes by what each one includes, not by the rate. Two quotes at the same rate can describe very different amounts of work.
How do you prepare to get an accurate WHMCS module quote?
Send a one-page brief that answers the questions below. A developer who has these answers can quote in a day; without them, every quote is a range with a large margin.
- Your WHMCS version, PHP version and control panel.
- The provider or service you are connecting, with a link to its API documentation and a sandbox or test account.
- What should happen at each step: order, payment, renewal, suspension, cancellation, refund.
- The screens you need, and who uses each: staff in the admin area or customers in the client area.
- Currencies, tax rules and your refund policy, including partial refunds.
- Any custom code, hooks or a custom theme already on the installation.
- Whether you can provide a staging copy, and who tests and approves the result.
- How you will know it is finished: the checks you will run before you accept it.
- Who will maintain it after launch.
What red flags should you look for in a WHMCS module quote?
- No staging copy mentioned. The module will be tested on your live billing.
- "Small changes to WHMCS files." A change to core files can be overwritten by the next update or can block it. Work belongs in modules, hooks and a theme copy.
- No handover documentation in the deliverables. You will be unable to maintain it or pass it to someone else.
- Vague scope. "Full integration with provider X" with no list of functions, screens or edge cases means the scope will be argued about later.
- No acceptance test. If nobody can say when it is done, nobody can say when it is late.
- A quote with no questions. If the developer never asked about your version, the provider's docs or your currencies, the number is not based on your job.
- Full payment up front on a large job with no milestones or review points.
For checking the person, not just the quote, see how to hire a WHMCS developer.
What does a WHMCS module cost after launch?
A module is not a one-off purchase. Two things change under it and cannot be avoided, so budget a small amount of time for them rather than a percentage I cannot honestly give you.
- WHMCS upgrades. New WHMCS releases can change PHP requirements, templates or internal behaviour. The module should be tested on a staging copy of your installation before you upgrade the live one.
- Provider API changes. Providers retire old API versions, change how authentication works or add required fields. A module that worked for a year can stop on the day a provider switches something off. Reading the provider's change notices is part of owning an integration.
Server changes matter too, such as a new PHP version on the host. Delivery from me includes two weeks of post-delivery support. Anything after that window is new work, quoted separately as a small fixed amount or at the hourly rate. If you would rather not track this yourself, see WHMCS support and maintenance.
How do I quote a custom module?
I start with a free scoping call of about 30 minutes, then send a quote within one business day. The quote lists the functions, screens and edge cases it covers, so you can see what is in and what is out.
The build happens in a staging copy, not on production. You get a daily progress update, written handover documentation at the end and the two weeks of post-delivery support mentioned above. If the scope is unclear, I will say so and suggest a smaller first phase, or hourly work for the unclear part, instead of guessing a price.
What is the next step?
Write the one-page brief from the checklist and send it to two or three developers. If you want my version of that conversation, the scope, process and limits are on the WHMCS custom module development page, and the hiring side is on hire a WHMCS developer. The scoping call is free.
