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. Free preview first, then spend credits from a pack. For bulk:

cd /path/to/whmcs/modules
find . -name "*.php" | while read f; do
  ioncube-decode "$f" -o "$f.decoded.php"
done

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. Swap the encoded file for your decoded and edited version. Works straight away.
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

In most jurisdictions, decoding modules you've bought for your own operational use falls under reverse-engineering-for-interoperability provisions. Decoding to redistribute does not. We only decode files you own or are authorized to decode.

Next steps

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