Split payments: betalingen verdelen in een marktplaats of platform.

Wat zijn split payments precies?

Zodra je software een derde partij laat verkopen — een marktplaats, een boekingsplatform, een verhuursite, een bemiddelingsdienst — verandert er iets fundamenteels aan je betaalstroom. Er komt niet langer geld binnen dat van jou is. Er komt geld binnen dat grotendeels van iemand anders is, waar jij een deel van mag houden. Dat lijkt een boekhoudkundig verschil, maar het raakt je architectuur, je aansprakelijkheid en zelfs de vraag of je een vergunning nodig hebt.

Ik zie regelmatig platformen die dat oplossen met de simpelste variant: alles komt binnen op de bedrijfsrekening, en aan het eind van de maand gaat er een batch overboekingen uit naar de verkopers. Dat werkt precies zolang er niets misgaat. Dit artikel gaat over de betere route, en over de beslissingen die je onderweg moet nemen.

De drie manieren om geld te verdelen

Alle grote betaaldienstverleners bieden hetzelfde principe onder een andere naam: aangesloten accounts (connected accounts) per verkoper, waar de betaaldienstverlener geld naartoe routeert. Stripe beschrijft drie varianten in zijn Connect-documentatie, en dat onderscheid is bruikbaar ongeacht welke partij je uiteindelijk kiest. Het verschil zit niet in de techniek maar in wie de betaling formeel ontvangt.

Die laatste variant is voor marktplaatsen meestal de juiste. De betaling en de uitbetaling zijn dan losgekoppeld: je incasseert eerst het volledige bedrag, en beslist daarna wanneer en aan wie je doorbetaalt. Ook Mollie Connect kent dat onderscheid, met split payments voor marktplaatsen en een application fee waarmee een platform automatisch zijn eigen deel afroomt. Mollie biedt daarbij expliciet uitgestelde routering, zodat je het geld pas verdeelt op het moment dat jij dat verantwoord vindt.

De vraag die je architectuur bepaalt is niet hoe je geld splitst, maar wie er op het bankafschrift van de klant staat.

Waarom je die keuze niet later maakt

Wie de betaling ontvangt, bepaalt wie de klant aanspreekt bij een klacht, wie moet factureren, en van wiens saldo een chargeback wordt afgeschreven. Ga je later van directe betalingen naar betalingen op het platform, dan verandert niet alleen je code maar ook je algemene voorwaarden, je facturatie en je aansprakelijkheid. Kies deze variant dus vóór de eerste regel integratiecode, samen met degene die over de contracten gaat.

De vergunningsvraag: mag je geld van een ander vasthouden?

Hier gaat het bij zelfbouw het vaakst mis. Zodra je betalingen van kopers int en die doorbetaalt aan verkopers, verleen je in beginsel een betaaldienst. De Nederlandsche Bank is daar duidelijk over: elektronisch handelsplatformen die zelf betaaldiensten verlenen zijn vergunningplichtig, ongeacht of dat hun hoofdactiviteit is of een bijzaak.

PSD2 kent een uitzondering voor partijen die optreden als handelsagent voor uitsluitend de koper óf uitsluitend de verkoper. Die uitzondering is smaller dan platformen hopen: je moet daadwerkelijk namens één van beide partijen handelen en daarover een overeenkomst hebben. Veel marktplaatsen bemiddelen feitelijk voor beide kanten en vallen er dus buiten.

In de praktijk zijn er drie werkbare routes:

• De geldstroom volledig uitbesteden: je gebruikt de connected accounts van een vergunninghoudende betaaldienstverlener, zodat het geld nooit op jouw rekening staat. Voor de meeste platformen is dit de kortste weg.
• Een gespecialiseerde partij inschakelen: er zijn betaalinstellingen die zich specifiek richten op marktplaatsen en de uitbetalingen, identificatie en het houden van gelden voor je overnemen.
• Zelf een vergunning aanvragen: realistisch bij grote volumes en een eigen compliance-organisatie, niet bij een platform dat net begint.

Wat je in elk geval niet doet, is geld van verkopers op je eigen bedrijfsrekening laten staan omdat het technisch nu eenmaal het makkelijkst was. Dat is precies het scenario waar het toezicht op ziet, en het gaat bovendien mis op het moment dat jouw onderneming in zwaar weer komt: het geld van je verkopers is dan niet afgescheiden.

Het uitbetaalmoment is een risicobeslissing

Betaal je meteen bij ontvangst uit aan de verkoper, dan draag jij het volledige risico van elke terugboeking die daarna komt. Een kaartbetaling kan maanden later nog worden betwist, en dan schrijft je betaaldienstverlener het bedrag van jouw saldo af — terwijl de verkoper zijn geld al lang heeft. Dit werkte ik uit in chargebacks en storneringen: het bedrag gaat er eerst af, de beoordeling volgt later.

Verstandiger is om de uitbetaling te koppelen aan een gebeurtenis die het risico verkleint. Denk aan:

1. Levering bevestigd: pas uitbetalen als de zending is afgeleverd of de dienst is geleverd. Bij fysieke producten koppel je dat aan je verzendpartner, bij diensten aan een bevestiging van de koper.
2. Retourtermijn verstreken: zolang de wettelijke bedenktijd loopt, is de kans op terugbetaling reëel. Veel platformen betalen daarom uit ná die termijn.
3. Ingehouden reserve per verkoper: een deel van elke uitbetaling blijft staan als buffer voor toekomstige terugboekingen, vooral bij nieuwe verkopers zonder historie.
4. Uitbetaalritme in plaats van per order: periodiek uitbetalen in plaats van per transactie scheelt kosten en geeft je een natuurlijk moment om verrekeningen mee te nemen.

Elk van die keuzes is een productbeslissing, geen technische. Verkopers willen snel geld; jij wilt geen risico. Waar je die grens legt, hoort in je verkopersvoorwaarden en vervolgens één op één in je software terug te komen.

Wat je software zelf moet bijhouden

Ook als je betaaldienstverlener de geldstroom afhandelt, blijft er een flinke administratie bij jou liggen. Onderschat dat niet: het splitsen is de makkelijkste helft.

Een eigen grootboek per verkoper

Je hebt per verkoper een eigen boekhouding nodig van wat er is verdiend, ingehouden, uitbetaald en teruggedraaid. Vertrouw daarvoor niet op het dashboard van je betaaldienstverlener: dat is hun waarheid, niet die van jouw platform. Bouw een grootboek waarin elke gebeurtenis een regel is — verkoop, commissie, refund, terugdraaiing, uitbetaling — zodat het saldo van een verkoper altijd het gevolg is van gebeurtenissen die je kunt terugvinden. Dit is dezelfde discipline als bij een audit trail: een saldo dat je nergens uit kunt afleiden, is een saldo waarover je vroeg of laat ruzie krijgt.

Splitsing op orderregelniveau

Een winkelmandje met producten van drie verkopers is niet één betaling maar drie deelbedragen plus verzendkosten plus jouw commissie. Bewaar de verdeling zoals die op het moment van bestellen gold, inclusief het commissiepercentage dat toen van toepassing was. Wijzig je later je tarieven, dan moeten oude orders hun oude verdeling houden.

Refunds die de splitsing volgen

Een gedeeltelijke terugbetaling moet de oorspronkelijke verdeling volgen: het deel van de verkoper gaat terug, jouw commissie meestal ook, en bij een chargeback moet je een eerdere uitbetaling kunnen terugdraaien. Kan de verkoper dat niet dragen, dan ontstaat er een negatief saldo dat je moet verrekenen met toekomstige verkopen. Leg vooraf vast wat er gebeurt als een verkoper met een negatief saldo vertrekt.

Webhooks, en dan idempotent

Alle statuswijzigingen — betaling geslaagd, uitbetaling onderweg, dispute geopend, onboarding afgerond — komen binnen als webhook. Verifieer de handtekening en verwerk elke gebeurtenis idempotent. In een platform met splitsingen is een dubbel verwerkte melding niet alleen een dubbele regel, maar een dubbele uitbetaling.

Onboarding als blokkade, niet als formaliteit

Een verkoper mag pas geld ontvangen als zijn identificatie rond is. Betaaldienstverleners geven die status door, en jouw platform moet daarop handelen: verkopen toestaan maar uitbetalingen blokkeren, en de verkoper zelf laten zien wat er nog ontbreekt. Zonder dat scherm belt hij jou.

Fiscaal en administratief: DAC7 en facturatie

Twee verplichtingen worden bij het bouwen structureel vergeten.

De eerste is DAC7. Platformen die bemiddelen bij de verkoop van goederen, persoonlijke diensten, verhuur van onroerend goed of verhuur van vervoermiddelen moeten gegevens over hun verkopers verzamelen, verifiëren en jaarlijks aanleveren bij de Belastingdienst, die ze uitwisselt met andere EU-lidstaten. Dat betekent concreet: je moet fiscale gegevens van verkopers uitvragen bij onboarding, ze koppelen aan de gerealiseerde omzet per kwartaal, en er een export van kunnen maken. Achteraf reconstrueren wie in januari wat verdiende, is aanzienlijk lastiger dan het meteen goed vastleggen.

De tweede is facturatie. Wie factureert wie? Bij directe betalingen factureert de verkoper aan de koper, en jij factureert je commissie aan de verkoper. Bij betalingen die via jouw platform lopen, kan het zijn dat jij aan de koper factureert en de verkoper aan jou. Veel marktplaatsen kiezen voor self-billing: het platform maakt de factuur namens de verkoper, met diens toestemming. Wat je ook kiest, het moet consistent zijn met je btw-behandeling en met de verdeling die je software hanteert. Een platform waar de geldstroom en de facturenstroom niet dezelfde route volgen, sluit nooit aan.

Valkuilen die ik het vaakst zie

• Uitbetalen bij betaling: het geld is weg voordat het risico voorbij is. Koppel uitbetaling aan levering of aan het verstrijken van je retourtermijn.
• Geen negatieve saldi voorzien: een terugboeking bij een verkoper zonder omzet levert een schuld op. Zonder verrekenlogica wordt dat handwerk.
• Verzendkosten en kortingen buiten de splitsing: juist die twee posten bepalen wie hoeveel krijgt. Neem ze expliciet mee in de verdeling per orderregel.
• Het dashboard van de betaaldienstverlener als administratie gebruiken: je hebt een eigen grootboek nodig dat ook klopt als je ooit van partij wisselt.
• Vergunningsvraag pas bij de eerste omzet stellen: de constructie waarin geld op jouw rekening staat, is achteraf het duurst om te herzien.
• Eén commissiemodel hardcoderen: vroeg of laat wil je afwijkende tarieven per verkoper, categorie of periode. Maak het een instelling met een geldigheidsdatum.

Mijn kijk op split payments

Het technische deel van split payments valt mee. De API-aanroepen zijn overzichtelijk, de documentatie van de grote partijen is goed, en een eerste werkende splitsing bouw je sneller dan je denkt. Wat mij betreft zit het echte werk in de vragen eromheen: wie is de verkoper richting de klant, wanneer is geld definitief, en wat gebeurt er als iemand halverwege afhaakt.

Precies daar zie ik platformen vastlopen. Niet omdat de betaling niet gesplitst wordt, maar omdat er drie maanden later een verkoper belt die zegt dat zijn saldo niet klopt, en niemand kan reconstrueren waarom. Een marktplaats is in de kern een administratiesysteem met een winkel eromheen. Bouw je die administratie als bijzaak, dan is dat de bijzaak waar je klantenservice de rest van het jaar mee bezig is.

Mijn advies aan iedereen die een platform begint: begin bij het grootboek en de uitbetaalregels, niet bij de checkout. En regel de vergunningsvraag voordat je gaat bouwen, niet nadat je eerste verkopers zijn aangesloten. Het is een van de weinige onderwerpen waarbij een verkeerde start je dwingt om zowel je software als je contracten opnieuw te doen.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen platformen en marktplaatsen waarin de geldstroom vanaf het ontwerp klopt: splitsing per orderregel, een eigen grootboek per verkoper, geverifieerde en idempotente webhooks, uitbetaalregels die aan levering hangen en een DAC7-export die je zonder handwerk aanlevert. Of dat nu draait op Stripe, Mollie of een gespecialiseerde betaalinstelling maakt voor het patroon eronder weinig uit.

Denk je na over een bestelportaal, een marktplaats of een verticaal platform waarin derden verkopen? Neem contact op voor een vrijblijvend gesprek over de opzet.

Bronnen: De Nederlandsche Bank (dnb.nl), Belastingdienst (belastingdienst.nl), Stripe Docs en Mollie Documentation.