Stripe en Mollie zijn allebei kandidaten voor een Nederlandse website, webshop of platform. De zinvolle vergelijking gaat over jouw betaalstroom: een losse bestelling, terugkerende kosten of betalingen voor meerdere verkopers. Kies niet alleen op de betaalpagina, maar ook op abonnementwijzigingen, terugbetalingen, foutafhandeling en aansluiting op de administratie.
Een bestaande, goed onderhouden koppeling met je webshop of boekhoudpakket kan de doorslag geven. Bij maatwerk moet je diezelfde werking zelf laten aantonen. Hieronder staat een besliskader; het is geen benchmark, tariefvergelijking of beschrijving van een uitgevoerde klantimplementatie.
Welke producten vergelijk je eigenlijk?
| Betaalstroom | Stripe | Mollie |
|---|---|---|
| Eenmalige bestelling | Checkout biedt onder meer een gehoste betaalpagina en ingesloten varianten. | De Payments API maakt een betaling met een checkoutlink aan. |
| Terugkerende betaling | Billing en Subscriptions modelleren abonnementen en bijbehorende facturatie. | Recurring Payments omvatten klantmandaten, losse vervolgincasso’s en periodieke abonnementen. |
| Platform met andere verkopers | Connect is de productlijn voor platformbetalingen. | Connect kent verschillende inrichtingen voor platforms en marketplaces. |
Die productnamen zijn geen bewijs dat iedere gewenste functie in jouw account beschikbaar is. Schrijf per kandidaat de vereiste landen, valuta, betaalmethoden, verkopersstructuur en gebruikte plug-in of API-versie op. Laat daarna precies die combinatie zien in een testomgeving. “Mollie voor Nederland, Stripe voor alles daarbuiten” is daarvoor te grof.
Let ook op actuele checkoutwijzigingen. Stripe beschrijft de overgang naar iDEAL | Wero; de geraadpleegde Mollie-documentatie gebruikt iDEAL. Controleer de inrichting bij de gekozen provider en hardcode niet op basis van een oude tutorial een eigen bankenlijst of een veronderstelde migratiedatum.
Een geslaagde checkout is nog geen betrouwbare orderverwerking
Neem een fictief opleidingsplatform dat één toegangsbewijs verkoopt. De koper rekent af en sluit meteen het tabblad. Die koper moet toegang krijgen, ook als de bedankpagina nooit opent. Omgekeerd mag iemand geen toegang krijgen door zelf de succes-URL te bezoeken.
Het ontwerp begint op de server: controleer de bestelling, bepaal het toegestane product en bedrag en bewaar een eigen orderreferentie. Maak vervolgens de providerbetaling aan. De Stripe-API voor Checkout Sessions is zo’n serveraanroep, geen plek om een geheime sleutel in browsercode te gebruiken. Vertrouw ook geen prijs die de browser ongecontroleerd meestuurt.
Houd daarna drie afzonderlijke toestanden bij: de betaling, het leveren van toegang en de financiële afstemming. Een bevestigde betaling kan samengaan met een vastgelopen accountaanmaak. De interface moet dan “betaald, toegang wordt verwerkt” kunnen tonen in plaats van opnieuw afrekenen aan te bieden. Stripe beschrijft bij fulfillment waarom alleen de terugkeerpagina onvoldoende is en waarom dezelfde verwerking ook bij gelijktijdige aanroepen maar één keer mag plaatsvinden.
Tarieven
Wat kost het?
Het begint bij . Wat jij betaalt hangt af van je situatie.
Controleer webhooks volgens het juiste contract
Een webhook wijst je server op een gebeurtenis. Welke verificatie nodig is, verschilt per provider en webhookversie. Leg die keuze vast per endpoint, voordat het bericht een order of abonnement mag wijzigen.
- Stripe: verifieer de
Stripe-Signaturemet de officiële library en het juiste endpointsecret, over de ongewijzigde requestbody. Stripe waarschuwt dat vooraf aanpassen of opnieuw serialiseren van de body die controle kan breken. Zie de webhookdocumentatie. - Klassieke Mollie-paymentwebhook: behandel het meegestuurde ID als aanleiding om de actuele betaling via de geauthenticeerde Mollie-API op te halen. Een aangeleverd statusveld is geen betalingsbewijs. Dit is het contract van de klassieke webhooks.
- Mollie Next-gen: controleer de
X-Mollie-Signaturemet het afgesproken signing secret en de ongewijzigde body, bij voorkeur via een ondersteunde officiële library. Het Next-gen-contract gebruikt HMAC; de best practices vereisen bij handmatige verificatie ook een timingveilige vergelijking.
Laat een endpoint voor ondertekende berichten niet terugvallen op het klassieke contract wanneer een handtekening ontbreekt. Controleer vóór implementatie welke eventtypen en versie daadwerkelijk beschikbaar en ingesteld zijn. Houd klassieke en nieuwe endpoints zo nodig gescheiden.
Verificatie van de afzender is bovendien niet de hele controle. Koppel de betaling aan de opgeslagen order, het juiste provideraccount en de juiste test- of liveomgeving. Vergelijk bedrag en valuta met de verwachte bestelling. Geef een onbekend of afwijkend record een controle-uitkomst, geen automatische toegang.
Voor het beschreven Stripe Checkout-pad haalt de server de Checkout Session bij Stripe op en beoordeelt de actuele payment_status. Een geldige signature of een voltooid checkoutscherm bewijst niet dat de betaling is geslaagd: een asynchrone betaling kan nog lopen en later slagen of mislukken. In dit voorbeeld vereist betaalde toegang de status paid, naast de overige leveringscontroles. Zolang betaling loopt of is mislukt, wordt die toegang niet vrijgegeven. Gratis toegang of een proefperiode krijgt een aparte regel en wordt niet als betaald geregistreerd. Zie Stripes controle van betaalstatus en vertraagde betalingen.
Dubbele berichten en een verdwenen antwoord horen bij het ontwerp
Stel dat de provider een betaling heeft aangemaakt, maar het antwoord je server niet bereikt. Een time-out vertelt niet of de betaling bestaat. Bewaar daarom de bedoelde bewerking en een stabiele idempotency key vóór de API-aanroep. Herhaal dezelfde bewerking niet met een nieuwe sleutel omdat het eerste antwoord ontbreekt.
De provider bewaart zo’n sleutel niet onbeperkt. Volgens Stripe kunnen sleutels na minimaal 24 uur worden opgeruimd; ook een eerder opgeslagen foutantwoord kan opnieuw terugkomen. Mollie beschrijft een cache van één uur en koppelt die aan de gebruikte credential. Een verlopen termijn of gewisselde credential maakt een oude onzekere betaling dus geen veilige nieuwe schrijfactie. Zoek eerst de bestaande verwerking terug; laat onopgeloste twijfel beoordelen.
Los daarvan heb je interne bescherming nodig. Bewaar een ontvangen gebeurtenis duurzaam en gebruik een unieke databasegrens voor de zakelijke actie, bijvoorbeeld één toekenning per order en toegangstype. Alleen eerst kijken of een record bestaat en het daarna invoegen is bij twee gelijktijdige verzoeken onvoldoende. Een achtergrondtaak kan de toekenning vervolgens gecontroleerd uitvoeren. Bevestig een webhook pas nadat de ontvangst of afhandeling veilig is vastgelegd.
Stripe meldt expliciet dat events dubbel of in een andere volgorde kunnen aankomen. Laat een later ontvangen oud bericht daarom niet blind een nieuwere zakelijke toestand overschrijven. Bewaar naast event-ID’s ook de relatie met betaling, order en uitgevoerde actie. Een periodieke vergelijking met de provider maakt ontbrekende verwerking zichtbaar.
Test een abonnement voorbij de eerste betaling
Voor het fictieve opleidingsplatform wordt de keuze lastiger zodra toegang maandelijks wordt verlengd. Werk vooraf uit wat er gebeurt bij een mislukte verlenging, opzegging, prijswijziging en gedeeltelijke terugbetaling. Bepaal wie de abonnementsstatus beheert en welke gebeurtenis het recht op toegang verandert.
Een eerste iDEAL-betaling is niet hetzelfde als een willekeurig herbruikbare incassomachtiging. Mollie beschrijft een first-payment- en mandaatproces, gevolgd door toegestane vervolgbetalingen. Die documentatie beschrijft ook providerafhankelijke herhaalpogingen en beëindiging bij bepaalde fouten. Bouw dus geen eigen incassoretry boven op providerretries zonder één duidelijke regie. Stripe beschrijft eveneens verschillende abonnements- en betaaltoestanden; “abonnement bestaat” betekent niet voor elke toepassing “huidige termijn voldaan”.
Vergelijk bij een platform met externe opleiders daarnaast wie de klantrelatie en de betaling beheert, hoe verkopers worden aangesloten, wie terugbetalingen uitvoert en hoe bedragen worden verdeeld. Dat vraagt een specifieke Connect-inrichting, niet alleen een extra veld met een verkoper-ID.
Liever even bellen?
Laat je terugbellen
Eén telefoontje is vaak sneller dan drie mailtjes. Je hoort binnen een werkdag van ons.
Laat deze situaties aantoonbaar werken
Gebruik onderstaande criteria als opdracht voor een geïsoleerde integratietest met synthetische orders en testbetalingen. Dit zijn voorgestelde controles, geen in dit artikel uitgevoerde providertests.
| Test | Verwachte uitkomst |
|---|---|
| Koper sluit het tabblad na betaling | De gecontroleerde serververwerking kent eenmaal toegang toe, zonder bezoek aan de bedankpagina. |
| Checkout is voltooid, maar de asynchrone betaling loopt nog | Een geldige signature levert nog geen betaalde toegang op. De server controleert de actuele sessiestatus; pas na een geslaagde betaling en de overige controles volgt vrijgave. Latere mislukking geeft geen toegang. |
| Dezelfde gebeurtenis komt gelijktijdig binnen | Eén zakelijke toekenning; geen tweede bevestiging door een parallelle verwerker. |
| Een verplicht ondertekend bericht is gewijzigd of mist zijn signature | Geen betaal- of toegangsverandering. Geen terugval op een zwakkere verificatieroute. |
| Een ID verwijst naar een andere order, omgeving of een afwijkend bedrag | Geen vrijgave van de huidige bestelling; een terugvindbare controle-uitkomst zonder geheime gegevens. |
| API-antwoord valt weg na het aanmaken van de betaling | De bestaande bewerking wordt herkend of gereconcilieerd; geen blinde tweede betaling na sleutelverloop. |
| Accountaanmaak faalt nadat de betaling is bevestigd | De betaling blijft herkenbaar. Een herstelbare taak en een verantwoordelijke zijn zichtbaar; opnieuw betalen is niet nodig. |
| Een oud event komt na een terugbetaling binnen | De afgesproken toegangstoestand blijft correct; de terugbetaling wordt niet ongedaan gemaakt door berichtvolgorde. |
| Verlenging mislukt of een mandaat vervalt | De afgesproken herinnering, toegang en eventuele retry volgen één regeling, zonder dubbele incasso’s. |
Vergelijk de kosten inclusief verwerking en beheer
Maak een vergelijking met je eigen verwachte betaalmix: aantallen, gemiddelde bedragen, gebruikte valuta, abonnementen, terugbetalingen en eventuele platformvergoedingen. Vul de actuele tarieven en contractvoorwaarden bij beide providers in. Zonder dat profiel is “goedkoper” geen bruikbare conclusie; daarom staan hier geen losse transactietarieven.
Neem ook implementatie, plug-inonderhoud, monitoring en het oplossen van uitzonderingen mee. Laat de administratieve aansluiting zien met herkenbare order- en betaalreferenties: hoe worden kosten, terugbetalingen en gegroepeerde uitbetalingen verklaard? Een betaalde order en een bankontvangst zijn verschillende registraties. Spreek de financiële verwerking af met degene die de administratie beheert.
Kies op de volledige proef, niet op de eerste demo
Kan een onderhouden standaardkoppeling alle benodigde situaties afhandelen? Dan is die eenvoud een sterk argument. Zijn afwijkende abonnementregels, meerdere verkopers of maatwerktoegang doorslaggevend? Vergelijk dan juist die moeilijke route bij beide providers. De kandidaat die daar aantoonbaar past, is waardevoller dan een algemene winnaar op een vergelijkingslijst.
Wil je de betaalstroom laten aansluiten op je platform en administratie? Bekijk integraties met bestaande software en de werkstroom rond facturatie. Voor de bredere gegevensoverdracht is er de gids over API-integraties tussen systemen.
