Maarten
Mollie developer
Mollie API · Checkout · Abonnementen · Webhooks
Mollie developer
Mollie developer inhuren voor maatwerk dat verder gaat dan de standaard plug-in: abonnementen met mandaten, betalen op factuur voor zakelijke klanten, webhooks die geen order laten liggen en refunds en uitbetalingen die kloppen in de boekhouding. Freelance, met 25 jaar ervaring, vanuit Nijmegen en remote door heel Nederland.
Eerder gebouwd voor Beat Batten en Autovisie.
Eén ervaren freelancer
Mollie developer voor je checkout en abonnementen
Een blik op de huidige Mollie-inrichting, de webhook-verwerking en het handwerk na een betaling, gevolgd door een aanpak die past: uitbreiden naast de plug-in of direct bouwen op de Mollie API. Alles eerst in testmodus. Vooraf is er een gesprek nodig om te weten wat er speelt, niet andersom.
- Checkout en betaalmethoden per land
- Abonnementen, mandaten en SEPA-incasso
- Refunds en settlements in de boekhouding
- Direct contact, geen tussenlagen
Voorbeelden van opgeleverd werk
Een website die geld ophalen eenvoudiger maakt
Een WordPress-website op basis van de bestaande branding, met een praktische manier van doneren.
Het autoplatform voor een toonaangevend automerk
Website, abonnementsmodel en een prettige redactieomgeving, ontwikkeld op WordPress.
Mollie developer inhuren voor meer dan de standaard plug-in
Mollie aansluiten op een webshop is meestal eenvoudig: de officiële plug-in voor WooCommerce, Magento of Shopware installeren, een API-sleutel invullen en de gewenste betaalmethoden aanzetten in het Mollie-dashboard. Voor een gewone consumentencheckout is dat vaak ook genoeg. Het wordt anders zodra een betaling meer moet doen dan een order op betaald zetten: abonnementen met terugkerende incasso's, zakelijke klanten die op factuur willen betalen, refunds die ook in de boekhouding moeten landen, of uitbetalingen die met de juiste orders moeten worden afgestemd. Daar begint het werk van een Mollie developer: niet bij het installeren, maar bij alles wat de plug-in niet voor je regelt.
Een freelance Mollie developer inhuren betekent, in de praktijk, iemand die zowel de Mollie API als de webshop en de administratie eromheen kent. De Payments API voor losse betalingen, Customers en Mandates voor terugkerende betalingen, de Subscriptions API voor vaste abonnementen, Refunds en Settlements, en de webhooks die alles bij elkaar houden. Vanuit Nijmegen wordt er gewerkt voor opdrachtgevers door heel Nederland, meestal op afstand. Vijfentwintig jaar ervaring met webshops en betaalkoppelingen betekent vooral: weten dat de meeste betaalproblemen niet bij Mollie zelf ontstaan, maar in de verwerking erna, op het moment dat een statuswijziging niet op de juiste plek aankomt.
Elk traject begint met een blik op de huidige inrichting: welke plug-in of eigen code draait er, hoe worden webhooks verwerkt, welke betaalmethoden staan aan en welke stappen na een betaling kosten nog handwerk? Op basis daarvan ontstaat een aanpak die past. Soms volstaat het om de officiële plug-in te laten staan en er een eigen module naast te zetten voor één ontbrekend onderdeel, zoals betalen op factuur of een afwijkende abonnementslogica. Soms is een directe integratie op de Mollie API de betere route, bijvoorbeeld bij een headless shop, een eigen platform of een SaaS-product waarin klanten maandelijks betalen. Alles wordt eerst in de testmodus van Mollie gebouwd en doorgelopen, inclusief mislukte betalingen en refunds.
Voor wie dit werkt, loopt uiteen: een webshop die naast losse verkoop ook abonnementen of herhaalbestellingen wil aanbieden, een groothandel die zakelijke klanten andere betaalopties wil geven dan consumenten, een platform dat via Mollie Connect betalingen namens andere partijen verwerkt, of een organisatie die refunds en uitbetalingen niet langer met de hand wil afstemmen. In alle gevallen gaat het om dezelfde behoefte: betalingen die kloppen, van het moment dat de klant op betalen klikt tot de regel in de administratie, met een developer die aanspreekbaar is zonder account manager ertussen.
Wat een Mollie-integratie precies nodig heeft, is zonder de huidige opzet gezien lastig te zeggen. Daarom begint het meestal met een kennismakingsgesprek: een half uur om te horen waar betalingen nu haperen of handwerk kosten, gevolgd door een eerlijk beeld van wat er nodig is en welke vervolgstappen logisch zijn. Geen verplichting, en ook geen voorstel om alles opnieuw te bouwen als een uitbreiding op de bestaande plug-in volstaat.
Gebouwd voor
Klaar voor Mollie-betalingen die tot in de boekhouding kloppen?
Wat een Mollie developer oplevert
Zelden is een compleet nieuwe betaalintegratie de oplossing; meestal levert een gerichte ingreep op het onderdeel met de meeste wrijving al het meeste op, terwijl de bestaande checkout gewoon blijft werken. Een paar voorbeelden van wat er dan concreet verandert.
-
Betaalde orders die ook op betaald staan
Een webhook-verwerking die bij elke melding de actuele status bij Mollie ophaalt, dubbele meldingen herkent en elk event logt, zodat een betaalde order niet op "in afwachting" blijft hangen en de voorraad niet onnodig vastzit.
-
Abonnementen die doorlopen
Mandaten die worden bewaakt, mislukte incasso's die een eigen vervolgstap krijgen en klanten die tijdig een link ontvangen om hun betaalgegevens bij te werken, in plaats van een abonnement dat ongemerkt stopt.
-
Betaalmethoden die passen bij land en bedrag
iDEAL bovenaan voor Nederlandse klanten, Bancontact voor België en achteraf betalen alleen waar het zinvol is, op basis van wat de Methods API voor die bestelling beschikbaar maakt.
-
Refunds in één handeling
Een terugbetaling vanuit het eigen beheer die tegelijk de refund bij Mollie aanmaakt, de orderstatus bijwerkt en een creditnota klaarzet in de boekhouding, zonder drie systemen langs te gaan.
-
Uitbetalingen die aansluiten op de administratie
Settlements van Mollie gekoppeld aan de onderliggende orders, met transactiekosten en terugboekingen apart zichtbaar, zodat de afstemming in Exact Online of Moneybird geen puzzel meer is.
-
Advies over plug-in, module of directe API
De officiële Mollie-plug-in uitbreiden, een eigen module ernaast zetten of rechtstreeks op de Mollie API bouwen: een blik op de huidige inrichting en het betaalvolume maakt meestal al duidelijk welke route bij de situatie past.
Benieuwd wat een blik op je Mollie-inrichting oplevert?
Mollie-betalingen met zo min mogelijk drempels
Voor het goede doel Beat Batten is een WordPress-website gebouwd op basis van de bestaande branding, met een praktische manier van doneren die het ophalen van geld eenvoudiger maakt, ook voor wie via de telefoon een gift wil doen. Deze case staat hier niet als Mollie-project, maar vanwege de vraag die elke betaalintegratie deelt: hoe weinig stappen kunnen er zitten tussen de wens om te betalen en een afgeronde betaling?
Bij een Mollie-checkout komt die vraag terug in concrete keuzes. Wordt de klant doorgestuurd naar de betaalpagina van Mollie, of worden de kaartvelden via Mollie Components in de eigen checkout getoond? Welke betaalmethode staat standaard geselecteerd, en verschilt dat per land of per apparaat? Op een telefoon is Apple Pay of iDEAL vaak sneller dan een creditcard intypen; op een zakelijke bestelling past een betaling op factuur meestal beter.
Een laagdrempelige betaling betekent ook dat er na het betalen niets misgaat. De klant komt terug op een bevestigingspagina die de juiste status toont, ook als de webhook net iets eerder of later binnenkomt dan de klant zelf. Die volgorde goed afhandelen is onzichtbaar werk, maar het is precies waar klachten over "wel betaald, geen bevestiging" vandaan komen.
Mollie voor abonnementen en terugkerende betalingen
Voor Autovisie, onderdeel van Telegraaf Mediagroep, is een WordPress-platform ontwikkeld inclusief abonnementenmodel en een redactieomgeving. Ook dat is geen Mollie-case, wel precies het soort functionaliteit waar een Mollie-integratie voor abonnementen op aansluit: lezers die toegang krijgen op basis van een lopend abonnement, en een account dat klopt met wat er is betaald.
Bij Mollie loopt een abonnement via een vaste volgorde. Een eerste betaling, vaak met iDEAL, legt een mandaat vast bij een Mollie-klant. Op dat mandaat volgen de terugkerende betalingen, via de Subscriptions API met een vast bedrag en interval, of door de eigen software zelf herhaalbetalingen te laten aanmaken wanneer het bedrag per periode verschilt. Welke van de twee past, hangt af van hoe voorspelbaar het abonnement is.
Het meeste werk zit in wat er gebeurt als het niet goed gaat. Een incasso die wordt gestorneerd, een creditcard die verloopt, een klant die wil upgraden halverwege een periode: elk van die situaties vraagt om een duidelijke regel en een koppeling met de toegangsrechten. Zonder die regels lopen abonnementen stilletjes af, of houden klanten juist toegang terwijl er niet meer wordt betaald.
Twijfel tussen de plug-in uitbreiden of direct op de API bouwen? Een half uur meedenken helpt vaak al.
Mollie-werk dat regelmatig terugkomt
Van een eigen checkout met Mollie Components tot een koppeling tussen settlements en de boekhouding: onderstaand het werk dat het vaakst terugkomt, telkens toegesneden op de shop of het platform dat er al staat. Alles wordt eerst in de testmodus van Mollie gebouwd en doorgelopen voordat het live gaat.
Eigen checkout met Mollie Components
Kaartvelden in de eigen checkout en eigen huisstijl, terwijl de kaartgegevens rechtstreeks naar Mollie gaan en de eigen server niet raken.
Abonnementen en mandaten
Customers, Mandates en Subscriptions correct ingericht, met variabele bedragen, planwijzigingen en een vervolg bij mislukte incasso's.
Webhook-verwerking
Meldingen die de status altijd opnieuw bij Mollie ophalen, dubbele verwerking voorkomen en per event worden gelogd, met de mogelijkheid een melding opnieuw te verwerken.
Refunds en chargebacks
Volledige en gedeeltelijke terugbetalingen vanuit het eigen beheer, en terugboekingen die zichtbaar worden in de order in plaats van alleen in het Mollie-dashboard.
Settlements en boekhouding
Uitbetalingen van Mollie per order afgestemd, met kosten en terugboekingen apart, en doorgezet naar Exact Online, Moneybird of een ander boekhoudpakket.
Mollie Connect voor platforms
Voor marktplaatsen en SaaS: Mollie-accounts van klanten koppelen via OAuth en betalingen namens hen verwerken, met eigen platformkosten per transactie.
- Mollie
- Mollie API
- Betaalmethoden
- Adyen
- MultiSafepay
- Webshop
- WooCommerce
- Magento
- Shopware
- PHP
- Exact Online
- Moneybird
- n8n
Veelgestelde vragen
Een aantal vragen dat regelmatig terugkomt bij het inhuren van een Mollie developer, van de plug-in en abonnementen tot webhooks en de boekhouding. Staat je eigen vraag er niet bij, stel 'm gewoon in het kennismakingsgesprek.
Werk je met de officiële Mollie-plug-in of bouw je alles zelf?
Beide komt voor. Voor de meeste webshops is de officiële plug-in een prima basis, die wordt uitgebreid met wat ontbreekt: betalen op factuur, een eigen abonnementslogica of een koppeling met de boekhouding. Bij een headless shop, een eigen platform of een SaaS-product wordt er direct op de Mollie API gebouwd.
Wat is het verschil tussen de Payments API en de Subscriptions API?
De Payments API is voor losse betalingen. Voor terugkerende betalingen legt een eerste betaling een mandaat vast bij een klant, waarna de Subscriptions API of de eigen software de vervolgbetalingen aanmaakt. De Mollie-documentatie over terugkerende betalingen beschrijft die volgorde; bij een echt abonnement zijn beide API's nodig.
Welke webshopplatformen koppel je met Mollie?
WooCommerce, Magento en Shopware het vaakst, daarnaast headless shops en eigen platformen. Draait er iets anders, dan is het meestal ook te koppelen; dat wordt in het eerste gesprek duidelijk.
Hoe voorkom je dat een betaalde order blijft hangen?
Met een webhook-verwerking die bij elke melding de actuele status bij Mollie ophaalt in plaats van de melding blind te vertrouwen, die dubbele meldingen herkent en die elk event logt. Gaat er toch iets mis, dan is in het logboek terug te zien waarom, en kan de melding opnieuw worden verwerkt.
Hoe zit het met PCI-compliance bij kaartbetalingen?
Met Mollie Components of de betaalpagina van Mollie gaan kaartgegevens rechtstreeks naar Mollie en komen ze niet op de eigen server terecht. Dat houdt de eigen verantwoordelijkheid voor PCI-compliance zo klein mogelijk, omdat de webshop zelf nooit een volledig kaartnummer of een cvc-code verwerkt of opslaat. Bij Mollie Components blijven de kaartvelden wel in de eigen huisstijl zichtbaar, terwijl de gegevens onder de motorkap direct naar Mollie worden verstuurd; bij de betaalpagina van Mollie stapt de klant kort over naar een pagina van Mollie zelf. Welke van de twee past, hangt af van hoe belangrijk een naadloze checkout is versus een iets eenvoudigere technische opzet. Voor terugkerende betalingen geldt hetzelfde principe: een mandaat wordt vastgelegd bij Mollie, en de webshop bewaart alleen een verwijzing daarnaar, nooit de onderliggende kaart- of rekeninggegevens zelf.
Koppel je ook andere betaalproviders?
Ja, ook Adyen, MultiSafepay en Stripe. Soms is een combinatie logisch, bijvoorbeeld een tweede provider voor een specifieke markt. Dat wordt alleen voorgesteld als er een concrete reden voor is, niet als standaard.
Kun je overstappen van een andere betaalprovider naar Mollie begeleiden?
Ja. Voor losse betalingen is dat vooral een kwestie van de checkout omzetten en testen. Bij lopende abonnementen is meer voorbereiding nodig, omdat mandaten niet altijd mee kunnen en klanten soms opnieuw een eerste betaling moeten doen. Dat wordt vooraf per situatie uitgezocht.
Wat kost een Mollie-integratie?
Dat hangt af van de omvang: een uurtarief of een vaste prijs per fase. Een prijsindicatie zonder de huidige situatie te kennen is weinig waard, dus de eerste stap is altijd een gesprek: een half uur waarin de huidige Mollie-inrichting, het aantal betaalmethoden en de complexiteit van abonnementen of facturatie aan bod komen. Gaat het om een uitbreiding op de bestaande plug-in, dan is dat vaak in een paar dagen te bouwen en te testen. Een directe koppeling op de Mollie API, met eigen checkout-velden, mandaten en settlements in de boekhouding, vraagt meer tijd, zeker als er meerdere betaalmethoden en landen bij komen. Na dat gesprek en een blik op de huidige inrichting ontstaat een concreet beeld van de uren of de vaste prijs, waarna je zelf beslist of en hoe je verder gaat, zonder verplichting vooraf.
Krijg ik de code in eigen beheer?
Toegang tot de code is er vanaf het begin, via een Git-repository, en de koppeling werkt met de officiële Mollie API zonder verborgen afhankelijkheden. De rechten op het maatwerk gaan over na volledige betaling, zoals in de algemene voorwaarden staat. Daarna kan een andere developer het werk op elk moment overnemen.
Mollie-integratie die meer moet?
Een half uur bellen om de checkout, de abonnementen en het handwerk na een betaling door te nemen, en of uitbreiden of opnieuw opzetten de logische route is. Geen verplichting, en ook geen kant-en-klaar advies voordat er is meegekeken naar de huidige inrichting.
