Decoding WHMCS Modules: The Practical Guide

If you run a hosting business, you probably own a stack of paid WHMCS modules — registrars, provisioners, billing integrations, custom reports. Most ship IonCube-encoded. When you need the source, here’s how.

Why WHMCS is special

WHMCS is the dominant billing and client management platform for hosting providers. Its plugin ecosystem is large and deeply commercial — single modules commonly cost $50–$500. Nearly all of them ship as IonCube-encoded PHP to protect the vendor’s business model.

That works fine until:

• The vendor disappears (common with smaller module developers).
• The module breaks after a WHMCS core update and the vendor is slow to fix.
• You need to customize behavior for a specific client.
• You’re migrating off a vendor’s ecosystem and need to extract your business logic.
• You need to audit a module before deploying to production (security).

Where WHMCS modules live

A typical WHMCS install has encoded modules in:

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

Each directory typically contains one or more .php files, some plain (config, hooks) and some IonCube-encoded (the actual logic).

Identify the encoding

Before decoding, check what you’re dealing with. Use our free IonCube version detector or open a file manually in a hex editor:

• First line is <?php // followed by a hex-ish tag → IonCube.
• Header mentions SourceGuardian → SourceGuardian.
• Plain PHP source → no decoding needed.

Decode the files

Upload each encoded file to our IonCube decoder. Free preview first, then use 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 via 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

Common module patterns

Once decoded, WHMCS modules follow predictable structures:

• Config array — top of the file, declares module name, settings, version.
• _ConfigOptions() function — defines the fields shown in the admin UI.
• Action hooks — _CreateAccount, _SuspendAccount, _TerminateAccount for server modules; _capture, _refund for payment gateways.
• License integration — often a call to the vendor’s licensing API. Review it against your agreement before changing deployment behavior.

Customize safely

Once you have decoded source, common customizations:

• Change label text — update the _ConfigOptions() array.
• Add custom fields — extend _ConfigOptions() and reference them in action hooks.
• Modify API calls — if the module talks to a third-party API, you can now modify the endpoint or request structure.
• Add logging — insert WHMCS’s logModuleCall() where you want visibility.
• Document licensing behavior — confirm what the module is allowed to do before deployment and keep changes within your license or vendor agreement.

Re-deploy

After modification, you have three options:

1. Deploy as plain PHP — replace the encoded file with your decoded + modified version. Works out of the box.
2. Re-encode with IonCube — if you want to keep protection (e.g., before selling or sharing your customized version).
3. Fork it — commit the source to a private git repo, version it properly, deploy via CI.

Legal note

Decoding modules you’ve purchased for your own operational use is generally covered under reverse-engineering-for-interoperability provisions in most jurisdictions. Decoding for redistribution is not. We only decode files you own or are authorized to decode.

Next steps

Start with our online IonCube decoder. Upload one module file, preview the output, and see if the approach works for your stack.