Waarom koppelen aan MultiSafepay?
Kort antwoord
MultiSafepay is een Nederlandse betaaldienstverlener (PSP). Een MultiSafepay-koppeling laat je klanten in je eigen webshop of maatwerksoftware betalen met iDEAL, creditcard, Bancontact, SEPA-incasso, PayPal of achteraf betalen — via één API. Je maakt de betaling aan vanuit je software, ontvangt de definitieve status via een geverifieerde notification en koppelt de order door naar je administratie.
MultiSafepay is een betaaldienstverlener uit Amsterdam die betalingen verwerkt voor webshops en maatwerksoftware. Het bedrijf hoort tot de grotere spelers op de Nederlandse markt en bedient volgens eigen opgave meer dan zestienduizend ondernemers. Sinds 2024 maakt MultiSafepay deel uit van Ant International (Antom), wat het internationale betaalaanbod verder verbreedt.
De kernbelofte van elke PSP geldt ook hier: waar je zonder betaaldienstverlener met elke bank en kaartmaatschappij apart zou moeten integreren, geeft één koppeling met MultiSafepay toegang tot een breed pakket betaalmethoden. In dit artikel loop ik door hoe die koppeling werkt, hoe je hem veilig bouwt en welke valkuilen we in de praktijk het vaakst tegenkomen.
MultiSafepay naast Mollie, Buckaroo en Adyen
MultiSafepay staat naast providers als Mollie, Buckaroo en Adyen. Het zijn allemaal Nederlandse PSP's, maar ze verschillen in schaal en focus:
- Mollie — bekend om de eenvoudige integratie, populair bij kleinere webshops.
- Adyen — enterprise-schaal, sterk bij internationale en high-volume handel met eigen acquiring.
- Buckaroo — een compleet Nederlands pakket met sterke lokale betaalmethoden en creditmanagement.
- MultiSafepay — een breed methodenpakket met een op maat te configureren checkout, vaak gekozen door webshops die naast de Nederlandse basismethoden ook wallets en achteraf betalen willen aanbieden.
Er is geen objectief beste keuze; het hangt af van je volume, je gewenste betaalmethoden en je markt. Wat voor alle vier geldt: de kwaliteit van je koppeling zit niet in het starten van een betaling, maar in het betrouwbaar verwerken van de status.
Wat kun je koppelen met de MultiSafepay API?
De koppeling loopt via de MultiSafepay API, een JSON-gebaseerde REST-API. De onderdelen die we het vaakst bouwen:
- Order aanmaken — Een betaling starten vanuit je eigen software met bedrag, valuta, ordernummer en de gewenste betaalmethode. De klant rekent af en keert terug naar je site.
- Betaalmethoden — In één koppeling bied je iDEAL, Bancontact, creditcard (met 3D Secure 2), SEPA-incasso, wallets als PayPal, Apple Pay en Google Pay, en achteraf betalen via Klarna, in3, Riverty en Billink. Laat je het gateway-veld leeg, dan toont MultiSafepay alle methoden die voor je account actief zijn.
- Refunds — Een betaling geheel of gedeeltelijk terugbetalen vanuit je software, zonder handmatig in te loggen op een dashboard.
- Notifications — De definitieve uitkomst van een betaling binnenkrijgen via een servermelding en koppelen aan de juiste order of factuur.
Wil je liever niet zelf een checkout bouwen, dan biedt MultiSafepay een gehoste betaalpagina en een FastCheckout. Bouw je een echte maatwerkflow, dan werk je rechtstreeks met de Orders API — dat geeft de meeste controle over hoe de betaling in je proces landt.
Authenticatie: één API-key, geen OAuth2
Anders dan veel CRM- of boekhoudkoppelingen werkt MultiSafepay niet met OAuth2. Voor server-naar-server-communicatie gebruik je een API-key die aan je site is gekoppeld. Die sleutel stuur je mee met elke aanvraag; de server accepteert de aanvraag alleen als de sleutel klopt en bij de aangesproken omgeving hoort.
Dat heeft één belangrijk gevolg voor je bouw: die api_key hoort veilig in je serveromgeving — in een environment-variabele of secrets manager, nooit in je frontend of in je broncode. Test- en productieomgeving hebben bovendien elk hun eigen sleutel, dus scheid je configuratie strikt.
Een API-key in je frontend is geen koppeling maar een lek. Alles wat een betaling kan starten of terugboeken, hoort achter je server te blijven.
MultiSafepay heeft daarnaast een gescheiden testomgeving met een eigen sleutel, los van productie. Bouw je koppeling met omgevingsspecifieke configuratie vanaf dag één, dan voorkom je de klassieke fout dat een testbetaling per ongeluk in productie belandt of andersom.
Notifications verwerken: de webhook is leidend
De uitkomst van een betaling haal je niet betrouwbaar uit de browser van de klant — die kan het tabblad sluiten of de verbinding kan wegvallen. MultiSafepay stuurt daarom een notification naar de notification_url die je hebt ingesteld, met de notification_method op POST. In die melding zit de volledige, bijgewerkte orderstatus, plus in de request-URL het transactionid (je eigen ordernummer) en een tijdstempel.
Het grote voordeel van de POST-notification is dat je de status meteen in de payload meekrijgt en niet apart hoeft terug te vragen bij de API. Maar dan moet je die melding wél verifiëren. Elke POST bevat een Auth-header met een HMAC-handtekening. Je verifieert die zo:
- Decodeer de Auth-header — de waarde is Base64-gecodeerd.
- Splits op de dubbele punt — je krijgt een tijdstempel en de meegestuurde handtekening.
- Bereken zelf de handtekening — een HMAC-SHA512 over de combinatie van tijdstempel en de ruwe payload, met je API-key als sleutel.
- Vergelijk — komt jouw berekening overeen, dan is de melding authentiek; zo niet, dan negeer je hem.
Twee principes zijn daarbij essentieel:
- De notification is de bron van waarheid, niet de redirect — De terugkeer naar je site na het afrekenen is een hint. Pas de geverifieerde notification bevestigt de definitieve status. Reken orders dus af op de notification, niet op de redirect.
- Verwerk de notification idempotent — Een melding kan opnieuw worden afgeleverd. Je endpoint moet dat aankunnen: een dubbel ontvangen melding mag nooit leiden tot een dubbele order, dubbele factuur of dubbele e-mail. Hoe je dat netjes oplost, lees je in ons artikel over idempotentie.
Een betaalkoppeling staat of valt bij de afhandeling van de notification. De betaling starten is het makkelijke deel — de status verifiëren en precies één keer verwerken is waar het echte werk zit.
Doorkoppelen naar je administratie
Een betaling verwerken is niet klaar zodra het geld binnen is. Voor een sluitende boekhouding wil je dat elke transactie zichzelf terugvindt in je administratie. MultiSafepay houdt transactiekosten in en bundelt uitbetalingen, net als elke PSP. Om je boeking kloppend te houden, letter je die uitbetalingen automatisch af tegen je orders — hetzelfde principe als bij het koppelen van je webshop aan je boekhoudpakket.
Bij een maatwerkkoppeling betekent dat: de notification verifiëren, de order op betaald zetten, een factuur genereren en de betaling doorzetten naar je boekhouding — allemaal automatisch, zonder dat iemand handmatig hoeft over te typen. Dat is precies de winst van een eigen koppeling boven een kant-en-klare plug-in: je bepaalt zelf hoe de betaling in je proces landt.
Veelgemaakte fouten bij MultiSafepay-koppelingen
Op basis van de betaalkoppelingen die we bouwen, zijn dit de valkuilen die we het vaakst tegenkomen:
- Vertrouwen op de redirect — De terugkeer naar je site is geen bewijs van een geslaagde betaling; de geverifieerde notification is de bron van waarheid.
- De Auth-handtekening niet controleren — Zonder verificatie vertrouw je elk bericht dat op je notification_url binnenkomt, ook een vervalst bericht.
- De notification niet idempotent verwerken — Een opnieuw afgeleverde melding leidt dan tot dubbele orders of dubbele boekingen.
- De API-key op de verkeerde plek — Een sleutel in je frontend of broncode is publiek; hij hoort in je serveromgeving.
- Test en productie door elkaar — Elke omgeving heeft een eigen sleutel. Strikt scheiden voorkomt vervelende verrassingen bij livegang.
Mijn kijk op MultiSafepay in maatwerk
Een PSP koppelen voelt vaak als een opgelost probleem — er is documentatie, er zijn plug-ins, hoe moeilijk kan het zijn? Het starten van een betaling is inderdaad niet het moeilijke deel. Waar het misgaat, is aan de achterkant: de notification die twee keer binnenkomt, de betaling die als geslaagd wordt geteld op basis van de redirect, de uitbetaling die niet klopt met de order in de boekhouding.
Wat ik bedrijven meegeef: beoordeel een betaalkoppeling niet op de happy path. Dat een geslaagde iDEAL-betaling netjes doorkomt, zegt weinig. Het verschil zit in de randgevallen — een dubbele notification, een geannuleerde betaling, een refund die deels terugkomt. Een koppeling die die gevallen serieus neemt, loopt maandenlang ongemerkt goed. Een die dat niet doet, moet elke maand handmatig recht worden getrokken.
MultiSafepay is voor de Nederlandse markt een prima keuze, zeker als je naast de basismethoden ook wallets en achteraf betalen wilt aanbieden. Maar de waarde van de koppeling zit in hoe zorgvuldig je de statusverwerking bouwt, niet in het merk op de betaalknop.
— Jasper
Zo helpt Coding Agency hierbij
Wij bouwen betaalkoppelingen die meer doen dan een betaling starten: met idempotente verwerking, verificatie van de Auth-handtekening op inkomende notifications, een nette refundflow en — waar gewenst — doorkoppeling naar je boekhouding. Of je nu MultiSafepay naast Buckaroo of Mollie wilt aanbieden of een eigen checkout in je maatwerksoftware bouwt, we denken graag mee over de juiste aanpak.
Benieuwd of MultiSafepay bij jouw situatie past, of hoe een koppeling er voor jou uitziet? Neem contact op voor een vrijblijvend gesprek.
Bron: MultiSafepay Docs — Webhook & API integration (docs.multisafepay.com).
