FileMaker Mollie integrationonline paymentsAPI connectionwebhooksrecurring paymentssubscription billingFileMaker Data API
Hoe verbind je FileMaker met Mollie

Hoe verbind je FileMaker met Mollie

Jeroen·

Een praktische handleiding voor het koppelen van FileMaker met Mollie voor online betalingen, facturen en abonnementen — inclusief webhooks, API-sleutels en veelgemaakte fouten.

U hebt klanten die een factuur online willen betalen met iDEAL, een creditcard of een abonnement — maar uw FileMaker-systeem kan alleen een PDF afdrukken en verzenden via e-mail. Iemand moet dan handmatig de bankrekening controleren, de betaling met de juiste factuur vergelijken en het record met de hand bijwerken. Als dit bekend in de oren klinkt, bent u niet alleen: het is een van de meest voorkomende hiaten in op maat gebouwde bedrijfssystemen die zijn gegroeid rond offertes, bestellingen en facturering, maar nooit zijn ontworpen voor onlinebetaling.

Dit artikel gaat stap voor stap na hoe u FileMaker aan Mollie koppelt, hoe de betalingsstroom in de praktijk eruitziet, en welke fouten de meeste eerste integraties doen struikelen.

Wat is Mollie, en waarom verbinden FileMaker-gebruikers zich ermee?

Mollie is een Europese betaaldienstaanbieder (PSP) waarmee bedrijven iDEAL, creditcard, Bancontact, PayPal, SEPA-automatische incasso, Apple Pay en verschillende andere betaalmethoden kunnen accepteren via een enkele API. Het is populair bij Nederlandse en Belgische mkb-bedrijven omdat het gemakkelijk in te stellen is, transparante prijzen heeft en — kritiek voor bouwers van maatwerksoftware — een schone, goed gedocumenteerde REST API heeft.

FileMaker heeft op zichzelf geen eigen betalingsgateway. Dus wanneer een bedrijf wil dat klanten een factuur, aanbetaling of abonnement direct vanuit een FileMaker-gegenereerd document of portaal kunnen betalen, is Mollie een van de meest praktische bruggen: het is een API-first service, die natuurlijk aansluit op FileMaker's Insert from URL en curl mogelijkheden.

Typische scenario's waarbij Loggix dit soort connectoren heeft gebouwd:

  • Een groothandelaar wil dat klanten online een aanbetaling doen voordat een bestelling wordt geproduceerd.
  • Een ledenorganisatie moet periodieke abonnementbetalingen automatisch innen, met FileMaker als ledenbestand.
  • Een dienstenbedrijf verstuurt facturen vanuit FileMaker en wil een "Nu betalen" link in de PDF of e-mail ingebed hebben.
  • Een e-commerce backend gebouwd in FileMaker heeft realtime betalingsstatus nodig zonder dat personeel een bankafschrift controleert.

Hoe werkt de FileMaker-naar-Mollie betalingsstroom eigenlijk?

Op technisch niveau is het een request-response cyclus plus een asynchrone webhook. Het helpt om het in vier stappen te zien:

  1. FileMaker maakt een betaalaanvraag. Uw script roept de Mollie API (POST /payments) aan met het bedrag, beschrijving en redirect URL — je vertelt Mollie eigenlijk "een klant moet €249,00 betalen voor factuur INV-1042."
  2. Mollie geeft een checkout URL terug. FileMaker slaat deze URL op en kan deze weergeven als een klikbare link in een portaal, insluiten in een PDF of via e-mail verzenden.
  3. De klant betaalt. Ze worden naar Mollie's gehoste checkout pagina gebracht, kiezen iDEAL, kaart of een ander middel, en voltooien de betaling buiten FileMaker — wat eigenlijk een voordeel is, geen beperking: het betekent dat uw FileMaker-systeem nooit kaartgegevens of bankgegevens aanraakt, dus PCI-DSS reikwijdte blijft buiten uw oplossing.
  4. Mollie stelt FileMaker op de hoogte via webhook. Zodra de betalingsstatus verandert (betaald, mislukt, verlopen of terugbetaald), stuurt Mollie een callback naar een webhook URL die u hebt geregistreerd. Dit is wat de factuuraanstelling in FileMaker eigenlijk bijwerkt — niet de browseromleiding van de klant, die gemakkelijk vervalst of onderbroken kan worden.
FileMaker stuurt een betaalaanvraag naar Mollie, klant betaalt, webhook geeft status terug

Dit laatste punt is een van de meest misverstane delen van deze integratie, dus het is de moeite waard het te herhalen: markeer een factuur nooit als betaald op basis van alleen de redirect URL. Een klant kan het browsertabblad sluiten na betaling, of voordat het betaalt, en toch uw "dank u" pagina bereiken. De webhook is de enige bron van waarheid.

Wat hebt u nodig voordat u begint met het bouwen van de connector?

  • Een Mollie account met minstens één actief profiel (testmodus is prima om mee te beginnen).
  • API sleutels — Mollie geeft u een live sleutel en een testsleutel. Bouw en test altijd eerst tegen de testsleutel; testbetalingen simuleren elke mogelijke status (betaald, mislukt, verlopen, geannuleerd) zonder echt geld te verplaatsen.
  • Een openbaar bereikbaar webhook endpoint. FileMaker Server moet de webhook oproep ergens ontvangen. Dit gebeurt meestal via de FileMaker Data API gecombineerd met een klein scriptonderdeel dat wordt blootgesteld via een PHP- of Node.js-listener, of rechtstreeks als u FileMaker Server uitvoert met een aangepast web-eindpunt dat een server-side script activeert via de FileMaker Admin API of een gepland script dat Mollie's statusendpoint als fallback poll.
  • Een veldstructuur om betalingsstatus bij te houden: minstens een Mollie betaal-ID, status, bedrag, methode en laatst bijgewerkt tijdstempel per factuur- of orderrecord.
  • HTTPS overal. Mollie stuurt geen webhooks naar gewone HTTP-eindpunten, en u wilt dit ook niet.

Stap voor stap: hoe bouwt u de verbinding in FileMaker?

  1. Maak een Mollie API-sleutel in het Mollie dashboard onder Developers > API keys. Sla de test- en live sleutels op als FileMaker-beveiligde variabelen of in een speciale instellingentabel — codeer ze nooit hardcoded in scripts.
  2. Bouw een script dat een betaling aanmaakt. Gebruik Insert from URL met cURL opties om naar https://api.mollie.com/v2/payments te posten, verzendend JSON met amount, description, redirectUrl en webhookUrl.
  3. Parse het JSON-antwoord met JSONGetElement om de betaal-id en checkoutUrl te extraheren, en sla beide op het factuurrecord op.
  4. Presenteer de checkout link aan de klant — als een knop in een klantportaal, een QR-code of een hyperlink in de gemailde PDF factuur.
  5. Bouw de webhook ontvanger. Omdat FileMaker Server niet standaard op een open webpoort kan luisteren, gebruiken de meeste implementaties een klein middleware-script (PHP, Node.js of een FileMaker Data API oproep geactiveerd door een lichtgewicht webserver) dat Mollie's POST oproep ontvangt en onmiddellijk terugbelt naar FileMaker — via de Data API of door naar een wachtrij tabel te schrijven die een server-side script elke minuut controleert.
  6. Bij webhook ontvangst, roep GET /payments/{id} aan om de gezaghebbende status rechtstreeks van Mollie op te halen — vertrouw nooit op de payload van de webhook oproep zelf, omdat dit alleen aangeeft "iets is veranderd," niet wat.
  7. Update het FileMaker record met de nieuwe status en activeer eventuele downstream logica: het markeren van een bestelling als "gereed voor productie," het verzenden van een betalingsbevestigings-e-mail, of het vrijgeven van een abonnementlicentie.
  8. Log alles. Sla de raw API-antwoorden (minstens tijdelijk) op in een logtabel. Wanneer een klant belt en vraagt "waarom is mijn betaling niet geregistreerd," is dit logboek wat u een middag gissen bespaart.

Wat zit er in periodieke betalingen en abonnementen?

Mollie ondersteunt periodieke betalingen via zijn Subscriptions API, wat een eerste betaling met machtiging vereist, bijv. een SEPA-automatische incasso of kaartbetaling waarbij de klant toekomstige ladingen expliciet goedkeurt. Zodra die machtiging bestaat, kan FileMaker Mollie activeren om de klant volgens een schema automatisch in rekening te brengen — maandelijkse ledencontributie, driemaandelijkse servicecontracten of betalingsplannen — zonder dat de klant elke keer betalingsgegevens opnieuw invoert.

De praktische valkuil hier: machtigingen kunnen worden ingetrokken of verlopen, en kaarten kunnen worden afgewezen bij verlenging. Bouw uw FileMaker logica om een mislukte periodieke aankoop elegant af te handelen — een dunning e-mailsequentie en een automatische poging na een paar dagen werken veel beter dan stilletjes mislukken en hopen dat iemand het uitstaande saldo opmerkt.

Wat gaat er meestal mis in deze integraties?

  • De redirect als bevestiging behandelen. Hierboven behandeld, maar het is de enige meest voorkomende bug die Loggix in eerste pogingen van deze connector ziet.
  • Test vs. live sleutel mismatches vergeten. Een betaling die met een testsleutel is aangemaakt, zal nooit verschijnen bij controle met de live sleutel, en omgekeerd — dit ziet eruit als "de webhook wordt niet verzonden" maar is eigenlijk een sleutelmismatch.
  • Geen fallback polling. Webhooks arriveren soms niet (netwerkstotteringen, serverdowntime). Een nachtelijk script dat de status van elke betaling die nog steeds als "open" is gemarkeerd na 24 uur controleert, vangt deze stilletjes gemiste updates.
  • Valuta- en bedragformatering. Mollie verwacht bedragen als tekenreeksen met twee decimalen (bijv. "10.00", niet 10). Een verrassend aantal mislukte API-oproepen gaat terug naar dit ene opmaakdetail.
  • Webhook-herhalingen negeren. Mollie zal een webhook oproep opnieuw proberen als uw eindpunt niet correct reageert. Zorg ervoor dat uw ontvangende script altijd een HTTP 200 geeft, zelfs als het de werkelijke verwerking voor later in de wachtrij plaatst — anders kunt u eindigen met het meerdere malen verwerken van dezelfde betalingsupdate.

FileMaker, Klai en FmBetterforms — waar passen zij in?

Naast de kernverbinding van de Mollie API verschijnen een paar tools algemeen rond dit soort build:

  • FileMaker zelf verwerkt de bedrijfslogica — factuurrecords, orderstatus, klantgegevens — en is waar de betalingsstatus uiteindelijk moet leven, zodat personeel en rapporten erop kunnen reageren.
  • Klai en vergelijkbare AI-ondersteunde ontwikkelingshulpmiddelen worden steeds vaker gebruikt om het schrijven en debuggen van de JSON-parsering en cURL-scripting te versnellen die dit soort API-integratie vereist, wat vroeger een van de meer vervelende onderdelen was van het handmatig bouwen van een Mollie-connector.
  • FmBetterforms is relevant wanneer u de klantgerichte kant van deze stroom — de factuur, orderformulier of betaalaanvraag — wilt laten eruitzien als een moderne, mobiel vriendschappelijke webpagina in plaats van een native FileMaker layout. Omdat de klant nooit het FileMaker-interface nodig heeft (ze worden omgeleid naar Mollie's eigen checkout pagina), is FmBetterforms nuttiger voor het omringende klantportaal: weergave van facturengeschiedenis, uitstaande saldi en betalingslinks in een schoon webweergave gebouwd bovenop dezelfde FileMaker-gegevens.

Checklist: is uw Mollie-connector productieklaar?

  • Testsleutel en live sleutel worden afzonderlijk opgeslagen en nooit gemengd
  • Webhook status wordt alleen vertrouwd na een GET /payments/{id} bevestigingsoproep
  • Een fallback polling script controleert dagelijks verouderde "open" betalingen
  • Bedragen worden opgemaakt als tekenreeksen met twee decimalen
  • Webhook ontvanger geeft altijd HTTP 200 snel terug
  • Betalingslogboeken worden minstens een paar maanden bewaard voor ondersteunings-/audit doeleinden
  • Mislukkingen bij periodieke betaling activeren een dunning proces, geen stilte
  • Klantgerichte checkout links worden op mobiel getest, niet alleen op desktop

Veelgestelde vragen

Heeft FileMaker een plug-in nodig om met Mollie verbinding te maken? Nee. Mollie's REST API werkt prima met FileMaker's ingebouwde Insert from URL en JSON functies (beschikbaar sinds FileMaker 16/17). Een plug-in kan dingen vereenvoudigen, maar het is niet vereist.

Kan FileMaker Server direct webhooks ontvangen? Niet standaard — FileMaker Server is geen algemene webserver. De meeste implementaties leiden de webhook via een klein middleware-laag (een lichtgewicht script op een webserver, of de FileMaker Data API) die FileMaker vervolgens bijwerkt.

Is Mollie PCI-DSS compliant, en dekt dit mijn FileMaker-systeem? Mollie is volledig PCI-DSS compliant voor de betalingspagina zelf. Omdat de klant betalingsgegevens invoert op Mollie's gehoste pagina, niet binnen FileMaker, blijft uw FileMaker-systeem over het algemeen buiten PCI-bereik — een van de praktische voordelen van deze architectuur.

Hoe lang duurt het bouwen van een typische FileMaker–Mollie integratie? Een eenmalige betalingsstroom (betaling aanmaken, omleiden, webhook update) is meestal een kwestie van dagen voor een ervaren FileMaker-ontwikkelaar. Periodieke abonnementen, retry logica en een gepolijst klantportaal kosten meer tijd — plan in voor een paar weken als u het productie-gehard wilt hebben.

Als uw FileMaker-systeem nog steeds afhankelijk is van handmatige bankchecks om te bevestigen wie heeft betaald, is dit precies het soort hiaat dat Loggix aangepaste connectoren voor bouwt — naast breder werk aan FileMaker verbinden met moderne applicaties en services. Of u nu een eenvoudige eenmalige betalingslink, een volledige periodieke facturingsstroom, een AI-ondersteund script om de ontwikkeling te versnellen, of een modern klantgericht portaal gebouwd met tools als FmBetterforms nodig hebt, het loont zich de juiste benadering in kaart te brengen voordat u API-oproepen gaat schrijven — en dat is een gesprek waar Loggix graag aan meedoet.