If you run a game hosting operation, manual provisioning is the ceiling on your growth. Every server a customer purchases requires you to log into Pterodactyl, create an account, allocate resources, and create the server. At 5 customers per month that is manageable. At 50, it becomes a part-time job. At 200, it is impossible.
Automated billing and provisioning solves this by connecting a payment and client management system directly to Pterodactyl's API. A customer pays through a checkout page. The system verifies the payment. A server gets created, credentials get emailed, and the customer is online, without any human involvement in the process.
This guide covers the two main platforms for this: WHMCS and WemX.
The System Architecture
Three components need to communicate:
- Billing platform (WHMCS or WemX): Takes orders, processes payments, manages subscriptions, sends invoices, handles renewals, suspends for non-payment
- Pterodactyl Panel: Manages the actual server containers through its application API
- Payment gateway (Stripe, PayPal, etc.): Handles the financial transaction and notifies the billing platform
The billing platform sits between the customer and Pterodactyl. It is the source of truth for what the customer purchased and whether they have paid. Pterodactyl is the executor that creates and manages the infrastructure.
Option 1: WHMCS With the Pterodactyl Module
WHMCS is the industry-standard billing platform for hosting companies. It handles client management, invoicing, domain management, support tickets, and product provisioning through a module system.
The Pterodactyl module for WHMCS is maintained by the community and available on GitHub. Installation requires:
- A running WHMCS installation (requires a license)
- A Pterodactyl Panel with the application API key generated
- The Pterodactyl WHMCS module installed in the WHMCS modules directory
Setting up the Pterodactyl API key:
In your Pterodactyl admin panel, go to Application API. Create a new key with these permissions:
- Locations: Read
- Nodes: Read
- Servers: Read, Write, Delete
- Users: Read, Write
- Eggs: Read
- Nests: Read
Copy the generated key. You configure this in WHMCS when setting up the server product.
Creating a product in WHMCS:
- Go to System Settings > Products/Services > Create a New Product
- Set the module to "Pterodactyl"
- In the module settings, configure:
- Panel URL
- API Key
- Nest ID (the Nests group your Eggs are in)
- Egg ID (the specific Egg for this product)
- Docker Image
- CPU, RAM, Disk allocations
- Node or location to deploy to
When a customer orders and pays, WHMCS calls the Pterodactyl API to create the server automatically. The customer receives an email with their panel credentials and server details.
Option 2: WemX
WemX is a newer, open-source alternative to WHMCS built specifically for game hosting resellers. It has native Pterodactyl integration without requiring a separate module.
Advantages over WHMCS:
- No license cost (open source)
- Built-in Pterodactyl server creation interface
- Discord OAuth login support
- Modern frontend with a focus on gaming audiences
WemX installs on a standard LAMP or LEMP stack and connects to Pterodactyl through the same application API.
# Install WemX (follow the official documentation at wemx.net)
cd /var/www
composer create-project wemx/wemx panel
cd panel
cp .env.example .env
php artisan key:generate
# Configure your .env with database and Pterodactyl API credentials
php artisan migrate --seed
For smaller operations or new hosting businesses that want to avoid WHMCS licensing costs, WemX is a practical choice.
Configuring Automated Suspension and Termination
The billing integration must handle the complete customer lifecycle:
On payment: Server is created or unsuspended automatically.
On overdue invoice: After a grace period you define (typically 3 to 7 days), the billing system sends a suspend command to Pterodactyl via API. The server stops accepting player connections but the data is preserved.
On termination: After a further period (typically 14 days of non-payment), the billing system sends a deletion command. The server and all its data are removed permanently.
In WHMCS, configure these under Automation Settings in the admin area. Set the days before suspension and termination to match your terms of service.
Configuring Resource Limits Per Plan
Each product you sell maps to specific resource allocations in Pterodactyl. Define these clearly per plan tier. Example plan structure:
| Plan | RAM | CPU | Disk | Players | |---|---|---|---|---| | Starter | 2 GB | 100% | 10 GB | 10 | | Standard | 4 GB | 200% | 20 GB | 25 | | Advanced | 8 GB | 300% | 40 GB | 60 | | Pro | 16 GB | 400% | 80 GB | 120 |
In Pterodactyl, CPU percentages represent cores. 100% equals one full core. A server with 200% CPU allocation uses up to two cores concurrently.
These limits are enforced at the container level by Docker. A customer on the Starter plan cannot burst above 2 GB RAM even if the physical node has free memory. This is what allows multiple customers to share the same physical node predictably.
Handling Upgrades and Downgrades
Customers who want to upgrade mid-cycle need the billing system to:
- Calculate a prorated credit for the remaining time on the current plan
- Switch the product and charge for the new plan
- Update the resource limits on the existing Pterodactyl server without recreating it
WHMCS handles proration automatically. The Pterodactyl module calls the panel's server update API endpoint to modify RAM, CPU, and disk allocations without deleting and recreating the server. The customer's files and configurations stay intact.
Custom Plugin and Egg Selection Per Plan
Advanced setups let customers choose their Egg (game type) during checkout. Implement this through WHMCS product add-ons or custom fields that pass the Egg ID to the provisioning module.
A customer buying a Minecraft plan selects Java Edition or Bedrock Edition at checkout. The billing system passes the corresponding Egg ID to Pterodactyl during provisioning. No manual intervention needed regardless of what the customer chooses.
Testing Before Going Live
Before accepting real customer payments:
- Set up a test product in WHMCS with a €0.00 price
- Place an order as a test customer
- Verify the server appears in Pterodactyl with correct resource allocations
- Manually trigger a suspension from the WHMCS admin and verify the server suspends in Pterodactyl
- Manually trigger a termination and verify deletion
Only go live after all three lifecycle events work correctly in your test environment.
Once this system is running, the operational overhead per new customer drops to near zero. Customer buys, server gets created, customer gets credentials. You spend time improving the service rather than clicking through admin panels manually for every order.