Maarten
WHMCS developer
WHMCS · Hosting · Cloud · SaaS
WHMCS developer
WHMCS developer inhuren voor provisioning op je eigen platform, registrar-modules voor extensies zonder kant-en-klare module, eigen betaalmodules, action-hooks en boekhoudkoppelingen die aansluiten: freelance, met 25 jaar ervaring, vanuit Nijmegen en remote door heel Nederland.
Eén ervaren freelancer
WHMCS developer inhuren voor modules en hooks
Een audit van modules, hooks en cron-taken, gevolgd door een aanpak per onderdeel: provisioning, domeinen, betalingen of boekhouding. Maatwerk via de officiële module-structuur, zodat een update minder snel iets breekt. Vooraf is er een gesprek nodig om te weten wat er speelt, niet andersom.
- Provisioning- en hook-audit
- Registrar-, gateway- en addon-modules
- Geen aanpassingen aan de WHMCS-kern
- Direct contact, geen tussenlagen
Waarom een WHMCS developer inhuren loont voor je hostingbedrijf
WHMCS regelt voor veel hosting- en cloudbedrijven de basis van de klantadministratie: bestellingen, domeinen, facturen, het klantportaal en support. Voor een klassiek hostingpakket op een gangbaar control panel werkt dat standaard prima. Zodra er een eigen platform draait, er domeinen worden aangeboden waarvoor geen kant-en-klare registrar-module bestaat, of er met incasso's en mandaten wordt gewerkt, ontstaat er handwerk. Iemand zet dan accounts met de hand klaar, zet een betaalde order handmatig door of corrigeert een factuur achteraf. Daar zit het werk van een WHMCS developer: de modules en hooks bouwen die precies dat stuk handwerk overnemen.
Een freelance WHMCS developer inhuren betekent, in de praktijk, iemand die PHP, de module-structuur van WHMCS en de systemen eromheen kent: cloud-API's, control panels, registrars, betaalproviders en boekhoudpakketten. Vanuit Nijmegen wordt er gewerkt voor opdrachtgevers door heel Nederland, meestal op afstand. Vijfentwintig jaar ervaring met webapplicaties en koppelingen betekent vooral: weten dat een koppeling niet af is wanneer de eerste aanroep slaagt, maar pas wanneer ook een time-out, een dubbele betaling of een half afgeronde provisioning netjes wordt opgevangen en zichtbaar wordt voor wie het moet oplossen.
Elk traject begint met een audit: welke modules en hooks draaien er, waar in de order-flow zit nog handwerk, welke cron-taken falen zonder dat iemand het merkt, en welke aanpassingen zijn ooit rechtstreeks in de kern gemaakt? Op basis daarvan ontstaat een aanpak per onderdeel: een provisioning-module tegen de API van het eigen platform, een registrar-module voor een extensie die nog handwerk kost, een gateway-module voor een betaalprovider, of een handvol action-hooks op momenten als een betaalde factuur of een geaccepteerde order. Maatwerk gebeurt via de officiële module- en hook-structuur, nooit door de kern aan te passen, zodat een WHMCS-update minder snel iets breekt.
Voor wie dit werkt, loopt uiteen: een hostingprovider met een eigen platform naast cPanel of Plesk, een cloud- of VPS-aanbieder die upgrades met pro-rata facturatie wil automatiseren, een SaaS-bedrijf dat abonnementen en licenties via WHMCS uitgeeft, of een internetprovider die met SEPA-incasso en mandaten werkt. In alle gevallen gaat het om dezelfde behoefte: facturatie en levering die automatisch op elkaar aansluiten, zodat het team zich bezighoudt met klanten in plaats van met het overtypen van gegevens tussen systemen.
Wat een WHMCS-installatie precies nodig heeft, is zonder de setup gezien lastig te zeggen. Daarom begint het meestal met een kennismakingsgesprek: een half uur om te horen waar nu handwerk of onzekerheid zit, gevolgd door een eerlijk beeld van wat er nodig is en in welke volgorde het zinvol is. Geen verplichting, en geen verkooppraatje over een nieuw billingsysteem als gerichte uitbreiding van WHMCS volstaat.
Gebouwd voor
Klaar voor een WHMCS-installatie die het werk uit handen neemt?
Wat een WHMCS developer oplevert
Zelden is een ander billingsysteem de oplossing; meestal levert een gerichte module of hook op het onderdeel met het meeste handwerk al het meeste op, zonder de bestaande installatie om te gooien. Een paar voorbeelden van wat er dan concreet verandert.
-
Provisioning die vanzelf loopt
Een betaalde order maakt via de API van het eigen platform direct een dienst aan, inclusief suspenderen, upgraden en opzeggen. Mislukt een aanroep, dan volgt een melding en kan de actie opnieuw worden gestart, in plaats van een order die ongemerkt op "pending" blijft staan.
-
Domeinen voor elke extensie
Een eigen registrar-module via EPP of de REST-API van een registry, met registratie, transfers, contactwijzigingen, nameservers en DNSSEC, in dezelfde beheeromgeving als de standaardmodules.
-
Minder gemiste betalingen
Een hook op een mislukte betaling zet een eigen herinneringsschema in gang, met nette mails, een nieuwe incassopoging op een logisch moment en pas daarna suspensie, in plaats van een onbetaalde factuur die niemand oppakt.
-
Een boekhouding die aansluit
Facturen, betalingen en creditnota's per regel gesynchroniseerd met Exact, AFAS, Twinfield of Moneybird, met een logboek, zodat de maandafsluiting geen puzzel meer is.
-
Een klantportaal in de eigen huisstijl
Eigen Smarty-templates, extra pagina's en single sign-on naar het control panel of de eigen app, zodat het portaal aanvoelt als het eigen product in plaats van als een standaard WHMCS-omgeving.
-
Advies over uitbreiden, opruimen of migreren
De bestaande WHMCS-installatie uitbreiden met een module of hook, eerst opruimen, of toch migreren naar een andere opzet: een blik op de modules, de hooks en de cron-taken maakt meestal al duidelijk welke route het meeste oplevert.
Benieuwd waar in je WHMCS-flow nog handwerk zit?
WHMCS-provisioning van betaling tot werkende dienst
Een provisioning-module is het hart van een geautomatiseerde hostingomgeving. WHMCS roept op vaste momenten functies aan zoals CreateAccount, SuspendAccount, UnsuspendAccount, TerminateAccount en ChangePackage; de module vertaalt die naar aanroepen op de API van het eigen platform, een cloudprovider of een control panel. Zolang het platform een API heeft, of desnoods een beveiligde command-line, is dat te koppelen.
Het verschil tussen een module die werkt en een module die blijft werken, zit in de randgevallen. Wat gebeurt er als het platform een time-out geeft terwijl de server wel is aangemaakt? Wordt een tweede poging dan een tweede server? Door elke actie herhaalbaar te maken zonder dubbele gevolgen, alles via de module-log van WHMCS vast te leggen en mislukte acties zichtbaar te maken voor support, blijft de flow betrouwbaar, ook op drukke momenten.
Rond de module horen meestal een paar action-hooks: op een betaalde factuur de provisioning starten, na het aanmaken de klant een welkomstmail met een inloglink sturen, en bij een upgrade het verschil pro rata berekenen. Samen vormen ze de keten van betaling tot werkende dienst, zonder dat iemand ertussen hoeft te klikken.
WHMCS-klantportaal en koppelingen op maat
Wat de klant van WHMCS ziet, is het klantportaal. Met eigen Smarty-templates, extra pagina's en single sign-on naar het control panel of de eigen applicatie voelt dat portaal als een onderdeel van het eigen product. Voor resellers kan één installatie meerdere portalen bedienen, elk met een eigen huisstijl, eigen prijzen en eigen mailtemplates.
Achter het portaal zitten de koppelingen die de rest van de organisatie voeden: de boekhouding, het ticketsysteem, monitoring of een CRM. WHMCS heeft zowel een interne als een externe API, en welke van de twee past, hangt af van waar de logica het best kan wonen. Een synchronisatie met de boekhouding draait bijvoorbeeld vaak als geplande taak binnen WHMCS, terwijl een externe applicatie beter via de externe API gegevens ophaalt.
In beide gevallen geldt dezelfde regel als bij de modules: alles via de ondersteunde structuur, met logging en een duidelijke eigenaar per gegeven. Dan blijft het portaal na een WHMCS-update gewoon werken, en kan een andere developer het werk later zonder archeologie overnemen.
Twijfel tussen een eigen module of een bestaande uitbreiding? Een half uur meedenken helpt vaak al.
WHMCS-werk dat regelmatig terugkomt
Van een provisioning-module voor een eigen cloudplatform tot een koppeling met de boekhouding: onderstaand het werk dat het vaakst terugkomt, telkens toegesneden op de installatie die er al staat. Alles wordt eerst gebouwd en getest op een aparte test-installatie van WHMCS, met de sandbox-omgevingen van de gekoppelde partijen, en pas daarna in productie gezet.
Provisioning-modules
Aanmaken, suspenderen, upgraden en opzeggen tegen de API van het eigen platform, een cloudprovider of een control panel, met foutafhandeling en statussynchronisatie.
Registrar-modules
Eigen koppelingen via EPP of REST voor extensies waarvoor geen kant-en-klare module bestaat, inclusief transfers, contactwijzigingen en DNSSEC.
Gateway-modules
Mollie, Adyen, MultiSafepay, Stripe of een andere betaalprovider, inclusief terugkerende betalingen en SEPA-mandaten.
Action-hooks
Eigen logica op momenten als een betaalde factuur, een geaccepteerde order, een mislukte betaling of de dagelijkse cron, herhaalbaar en gelogd.
Addon-modules en admin-tooling
Eigen beheerpagina's voor support, finance of resellers, binnen de WHMCS-omgeving en met de bestaande rechtenstructuur.
Boekhoud- en API-koppelingen
Exact, AFAS, Twinfield of Moneybird, plus ticketing, monitoring en CRM via de interne of externe WHMCS-API.
Veelgestelde vragen
Een aantal vragen dat regelmatig terugkomt bij het inhuren van een WHMCS developer, van modules en updates tot migraties. Staat je eigen vraag er niet bij, stel 'm gewoon in het kennismakingsgesprek.
Pas je de WHMCS-kern aan?
Nee. Maatwerk zit in modules en action-hooks, zoals beschreven in de WHMCS developer-documentatie. Daardoor blijven updates beheersbaar: een nieuwe WHMCS-versie kan de kern vervangen zonder dat eigen aanpassingen daarbij verloren gaan of stuklopen, en de officiële support van WHMCS blijft gewoon van toepassing. Bestaande installaties waar in het verleden wel in de kern is aangepast, komen dat probleem meestal pas tegen bij de eerstvolgende update; die aanpassingen worden bij een audit in kaart gebracht en waar mogelijk verplaatst naar een module of action-hook. Dat is soms meer werk dan de oorspronkelijke aanpassing, maar voorkomt dat elke toekomstige update weer handmatig werk oplevert of, erger, een storing die pas na de update aan het licht komt.
Kun je een provisioning-module bouwen voor mijn eigen platform?
Meestal wel. Zolang het platform een API heeft (REST, SOAP of een beveiligde command-line), kan een server-module de standaardfuncties van een WHMCS provisioning-module doorzetten, zoals aanmaken, suspenderen, upgraden en opzeggen, inclusief foutafhandeling en statussynchronisatie.
Bouw je registrar-modules voor extensies zonder bestaande module?
Ja. Voor extensies met een eigen EPP-server of REST-API ontstaat een registrar-module met registratie, transfers, verlengingen, contactwijzigingen, nameservers en DNSSEC, met dezelfde beheerervaring als de standaardmodules.
Hoe ga je om met WHMCS-updates?
Eigen modules worden bij een nieuwe versie eerst op een test-installatie gedraaid, meldingen over verouderde functies worden opgelost, en pas daarna gaat de update naar productie. Omdat alles in modules en hooks zit, is dat doorgaans overzichtelijk werk.
Welke betaalproviders kun je koppelen?
Mollie, Adyen, MultiSafepay, Stripe, Buckaroo of een andere provider met een API, inclusief terugkerende betalingen, SEPA-mandaten en een eigen herinneringsschema bovenop de standaardherinneringen van WHMCS.
Kan het klantportaal in de eigen huisstijl?
Ja, met eigen Smarty-templates, extra pagina's en single sign-on naar het control panel of de eigen app. Voor resellers kan één installatie meerdere portalen bedienen, elk met een eigen huisstijl.
Doe je ook migraties naar WHMCS?
Ja. Klanten, diensten, facturen en mandaten gaan mee, eerst op een testomgeving, daarna gefaseerd, zodat er geen dubbele facturen of vergeten verlengingen ontstaan.
Wat kost een WHMCS-traject?
Dat hangt af van de omvang: een uurtarief of een vaste prijs per fase. Een enkele action-hook of een gateway-module voor een betaalprovider is meestal in een beperkt aantal dagen te bouwen; een provisioning-module voor een eigen platform of een boekhoudkoppeling met foutafhandeling en logging vraagt meer tijd. Na een eerste audit van de bestaande modules, hooks en cron-taken ontstaat een concreet beeld van de uren of de vaste prijs, waarna je zelf beslist of en hoe je verder gaat, zonder verplichting vooraf.
Kan een ander later verder met de code?
De code volgt de officiële module-conventies van WHMCS, staat vanaf het begin in een Git-repository waar je toegang toe hebt en is gedocumenteerd. De rechten op het maatwerk gaan over na volledige betaling, zoals in de algemene voorwaarden staat. Daarna kan een andere PHP developer het werk op elk moment overnemen, en dat is ook de bedoeling.
WHMCS-installatie die meer moet doen?
Een half uur bellen om de installatie, de modules en het handwerk door te nemen, en welke uitbreiding als eerste het meeste oplevert. Geen verplichting, en ook geen kant-en-klaar advies voordat er is meegekeken naar de setup zelf.
