Decoding WHMCS Modules: The Practical Guide

If you run a hosting business, you've probably got a stack of paid WHMCS modules: registrars, provisioners, billing integrations, custom reports. Most ship IonCube-encoded. Here's how to get the source back when you need it.

Why WHMCS is its own thing

WHMCS is the default billing and client-management platform for hosting providers, and its plugin ecosystem is large and very commercial. Single modules routinely cost $50 to $500, and nearly all of them ship as IonCube-encoded PHP to protect the vendor's business.

That's fine right up until:

• the vendor disappears, which happens a lot with smaller developers;
• the module breaks after a WHMCS core update and the vendor is slow to patch it;
• you need to change how it behaves for a specific client;
• you're moving off a vendor's ecosystem and need your business logic out;
• you want to audit a module for security before it goes near production.

Where WHMCS modules live

A typical install keeps encoded modules under:

/modules/addons/[addon-name]/
/modules/servers/[server-module]/
/modules/registrars/[registrar-module]/
/modules/gateways/[payment-gateway]/
/modules/reports/[report]/

Each folder usually holds a few .php files. Some are plain (config, hooks) and some are IonCube-encoded (the actual logic).

Work out the encoding

Before you decode, check what you're holding. Use our free IonCube version detector, or open a file in a hex editor and look at the first line:

• <?php // followed by a hex-ish tag means IonCube.
• A header mentioning SourceGuardian means SourceGuardian.
• Plain PHP source means there's nothing to decode.

Decode the files

Upload each encoded file to our IonCube decoder. Eligible files get a free preview; protection-dependent files return guidance. For bulk:

cd /path/to/whmcs/modules
ioncube-decode batch . -j 8

Or through the API with any account:

for f in modules/**/*.php; do
  curl -H "Authorization: Bearer $KEY" \
       -F "file=@$f" \
       https://api.decodephp.io/v1/decode > "$f.decoded.json"
done

What decoded modules look like

Once they're decoded, WHMCS modules follow a predictable shape:

• A config array at the top of the file, declaring the module name, settings and version.
• A _ConfigOptions() function that defines the fields shown in the admin UI.
• Action hooks like _CreateAccount, _SuspendAccount and _TerminateAccount for server modules, or _capture and _refund for payment gateways.
• License integration, usually a call to the vendor's licensing API. Check it against your agreement before you change how it deploys.

Customizing safely

With the source in hand, the usual changes are:

• Relabel things by editing the _ConfigOptions() array.
• Add custom fields by extending _ConfigOptions() and using them in the action hooks.
• Change API calls if the module talks to a third party, so you can adjust the endpoint or request shape.
• Add logging with WHMCS's logModuleCall() wherever you want visibility.
• Mind the licensing. Confirm what the module is allowed to do, and keep your changes inside your license or vendor agreement.

Redeploy

Once it's modified, you've got three options:

1. Ship plain PHP. After authorization, review, linting, and testing, replace the encoded file with your recovered and edited version.
2. Re-encode with IonCube. Do this if you want the protection back, for example before sharing or selling your customized version.
3. Fork it. Commit the source to a private git repo, version it properly, deploy through CI.

A note on the legal side

Authorization and reverse-engineering rules vary by license and jurisdiction. Use DecodePHP only for files you own, are authorized to analyze, or are otherwise legally permitted to recover, and get qualified advice if you are unsure.

Next steps

Start with our online IonCube decoder. Upload one module file, look at the preview, and see whether the approach fits your stack.