WHMCS Configurable Options: Dynamic Pricing & Customization

Configurable Options are the WHMCS feature that lets a single product become five products without creating five products. Used right, they let customers pick exactly what they need at checkout — extra disk, more email accounts, different OS — with the price updating live.

This is the practical guide to configurable options without the gotchas.

What configurable options are (and aren't)

A configurable option is an attribute of a product that the customer picks at order time. Examples:

• Number of seats (per-seat pricing).
• Storage size (5/10/25/100 GB tiers).
• OS selection (Ubuntu / Debian / CentOS).
• Extra IPs (quantity-based).
• Add-ons (backup service yes/no, monitoring yes/no).

They're NOT for:

• Fundamentally different products (use separate WHMCS products instead).
• One-time upsells (use addons).
• Anything that requires complex business logic (model in code, not configurable options).

The option types WHMCS supports

Step 1 — Create a configurable option group

1. Setup → Products/Services → Configurable Options → Create Group.
2. Name the group: "VPS Options" or "Hosting Extras".
3. Assign products that should see this group (a single group can attach to multiple products).

Step 2 — Add the options

For each option:

1. Add Option.
2. Option name: customer-facing label.
3. Option type: Dropdown / Radio / Yes/No / Quantity.
4. For Dropdown/Radio: add sub-options ("Ubuntu 22.04", "Debian 12", etc.) with optional price modifiers per billing cycle.
5. For Quantity: set price per unit, minimum, maximum.

The price modifier is what makes this powerful: each sub-option can add to the base product price.

Step 3 — A real example: VPS configuration

Product: "VPS Linux" at $20/month base.

Configurable Option Group: "VPS Customization":

• Option 1 — Region (Dropdown):
  • US East — $0
  • US West — $0
  • Europe — $0
  • Asia — +$5/month (premium region)
• Option 2 — OS (Dropdown):
  • Ubuntu 22.04 LTS — $0
  • Debian 12 — $0
  • AlmaLinux 9 — $0
  • Windows Server — +$15/month (licensing)
• Option 3 — Extra IPs (Quantity, $2 per unit, min 0 max 5).
• Option 4 — Daily Backups (Yes/No, +$3/month if Yes).

Customer in Europe picks Ubuntu, 2 extra IPs, backups → $20 + $0 + $0 + $4 + $3 = $27/month. Live calculation on the order form.

Step 4 — Make the provisioning module use them

The selected options are passed to your provisioning module via $params['configoptions']:

function mymodule_CreateAccount(array $params)
{
    $region = $params['configoptions']['Region'] ?? 'us-east';
    $os     = $params['configoptions']['OS'] ?? 'ubuntu-22.04';
    $extraIps = (int) ($params['configoptions']['Extra IPs'] ?? 0);
    $backup = ($params['configoptions']['Daily Backups'] ?? 'No') === 'Yes';

    // Pass to your platform API
    $api->createVps([
        'region'       => $region,
        'os'           => $os,
        'extra_ips'    => $extraIps,
        'enable_backup' => $backup,
        // ...
    ]);

    return 'success';
}

The keys in configoptions are the option names you set in WHMCS. Match them exactly.

Step 5 — Handle option changes after order

Customers can change configurable options after the initial order (e.g., add more seats). WHMCS handles the billing — prorates correctly. Your module needs to handle the actual change via ChangePackage:

function mymodule_ChangePackage(array $params)
{
    // Same logic as CreateAccount, but reconfiguring the existing instance
    $region = $params['configoptions']['Region'];
    $extraIps = (int) $params['configoptions']['Extra IPs'];

    // For changes that the platform doesn't support live (region change),
    // either reject or schedule for next renewal.
    if ($region !== $params['originalconfigoptions']['Region']) {
        return 'Region changes require new VPS provisioning. Contact support.';
    }

    // Live-update what's safe to change
    $api->updateVps([
        'extra_ips' => $extraIps,
        'enable_backup' => (...),
    ]);

    return 'success';
}

Step 6 — Display customization

The default WHMCS order form shows options as a basic table. Customize configureproduct.tpl in your order form template for better UX:

• Group related options visually.
• Show price impact next to each option as customer selects.
• Pre-select sensible defaults (the most common OS, etc.).
• Mobile-friendly layout (large tap targets, single-column).

How to verify configurable options work

1. Go through the order form. Change each option. Confirm the price updates correctly.
2. Place the order. Look at the invoice — line items should reflect base + options.
3. In WHMCS admin → the service page → options panel. Change an option. Confirm:
   • WHMCS prorates correctly.
   • An invoice is generated for the upgrade.
   • Your ChangePackage runs after payment.

Common pitfalls

"Option price not applying." The option's price field is empty — WHMCS treats blank as $0. Use 0 explicitly if no charge.

"Customer can't change options after order." Check product config: Setup → Products → edit → Other tab → Allow Upgrades / Downgrades.

"Quantity option always shows 1." The "Quantity" type needs a min/max set. Default min is 0; some flows show 1.

"ChangePackage doesn't fire." The module's ChangePackage function is missing or named wrong. Check the function signature.

My take — when to use options vs products

If two variants share >80% of behavior (same panel, same support, same SLA): configurable options.

If they're operationally different (one needs special routing, different support team, different fulfillment): separate products.

The mistake I see: trying to model genuinely-different products as one product with options. The first time you need a custom workflow per variant, the configurable-options approach breaks.

Going further

• WHMCS configurable options docs
• Provisioning module guide — wiring options to your platform.

I design and build configurable-option setups for WHMCS — pricing models, provisioning integration, upgrade flows. Tell me about your product and I'll send a quote in 24 hours.