--- title: "Split payments: betalingen verdelen in een marktplaats of platform | Coding Agency" description: "Split payments uitgelegd: de drie manieren om geld te verdelen tussen verkopers, de vergunningsvraag onder PSD2, het uitbetaalmoment en wat je software zelf moet bijhouden." url: https://coding.agency/kennisbank/split-payments-marktplaats-platform source: Coding Agency (https://coding.agency) language: nl --- Betalingen 10 min leestijd # Split payments: betalingen verdelen in een marktplaats of platform. Split payments uitgelegd: de drie manieren om geld te verdelen tussen verkopers, de vergunningsvraag onder PSD2, het uitbetaalmoment en wat je software zelf moet bijhouden. [ Jasper Koers ](https://coding.agency/over/jasper-koers) · 10 aug. 2026 ## In het kort - Split payments verdeelt een klantbetaling over verkopers en platform, zonder dat jij geld van anderen op je eigen rekening parkeert - De drie geldstromen verschillen vooral in wie op het bankafschrift staat en wie het chargebackrisico draagt - Geld van derden vasthouden raakt PSD2: beleg de geldstroom bij een vergunninghoudende betaaldienstverlener of onderzoek de vergunningsplicht - Het uitbetaalmoment is een risicobeslissing, geen technisch detail: betaal uit na levering, niet bij betaling - Je platform heeft een eigen grootboek per verkoper nodig, plus DAC7-gegevens en een sluitende facturatiestroom ## Wat zijn split payments precies? Kort antwoord Split payments is het verdelen van een enkele klantbetaling over meerdere ontvangers: de verkoper of verkopers en het platform zelf. Je betaaldienstverlener routeert de bedragen direct naar aparte saldi en houdt jouw commissie in, zodat jij geen geld van anderen hoeft vast te houden op je eigen bankrekening. 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](https://docs.stripe.com/connect/charges), 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. | Variant | Wie ontvangt de betaling | Wie draagt refunds en chargebacks | Past bij | | Directe betaling | De verkoper; jouw platform houdt een fee in | De verkoper | SaaS waarbij de klant de verkoper kent en jij alleen de tooling levert | | Betaling met doorstorting | Jouw platform, met directe doorstorting naar een verkoper | Het platform | Marktplaatsen met een eigen merk, waarbij de klant bij jou koopt | | Gescheiden betaling en uitbetaling | Jouw platform, met losse uitbetalingen achteraf | Het platform | Een winkelmandje met producten van meerdere verkopers | 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](https://docs.mollie.com/docs/connect-overview) 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](https://docs.mollie.com/docs/connect-marketplaces-split-payments-with-delayed-routing), 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](https://www.dnb.nl/voor-de-sector/open-boek-toezicht/wet-regelgeving/psd2/elektronische-handelsplatformen-e-commerce-platforms-psd2/), 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](https://coding.agency/kennisbank/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](https://coding.agency/kennisbank/audit-trail-in-software): 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](https://coding.agency/kennisbank/idempotency-bij-api-koppelingen). 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](https://www.belastingdienst.nl/wps/wcm/connect/nl/ondernemers/content/informatie-voor-platformexploitanten-dac7), 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](https://coding.agency/kennisbank/stripe-integratie-saas), [Mollie](https://coding.agency/kennisbank/mollie-betalingen-webshop) of een gespecialiseerde betaalinstelling maakt voor het patroon eronder weinig uit. Denk je na over een [bestelportaal](https://coding.agency/kennisbank/b2b-e-commerce-bestelportaal), een marktplaats of een [verticaal platform](https://coding.agency/kennisbank/vertical-saas) waarin derden verkopen? Neem [contact](https://coding.agency/contact) op voor een vrijblijvend gesprek over de opzet. Bronnen: [De Nederlandsche Bank (dnb.nl)](https://www.dnb.nl/voor-de-sector/open-boek-toezicht/wet-regelgeving/psd2/elektronische-handelsplatformen-e-commerce-platforms-psd2/), [Belastingdienst (belastingdienst.nl)](https://www.belastingdienst.nl/wps/wcm/connect/nl/ondernemers/content/informatie-voor-platformexploitanten-dac7), [Stripe Docs](https://docs.stripe.com/connect/charges) en [Mollie Documentation](https://docs.mollie.com/docs/connect-overview). ## Veelgestelde vragen Split payments is het verdelen van een enkele klantbetaling over meerdere ontvangers: een of meer verkopers en het platform zelf. De betaaldienstverlener routeert de bedragen naar aparte saldi, zodat het platform geen geld van anderen op de eigen rekening hoeft te parkeren. Mogelijk wel. Houd je zelf geld van derden vast en betaal je dat door, dan verleen je volgens PSD2 een betaaldienst en is een vergunning van De Nederlandsche Bank in beeld. Dat voorkom je meestal door de geldstroom volledig bij een vergunninghoudende betaaldienstverlener te beleggen. Beide laten je betalingen splitsen over aangesloten accounts en een eigen fee inhouden. Stripe Connect onderscheidt drie betaalvormen met verschillende geldstromen en aansprakelijkheid; Mollie Connect kent split payments voor marktplaatsen en een application fee voor platformen. De keuze hangt af van wie de klant ziet als verkoper en wie het chargebackrisico draagt. Niet automatisch bij betaling. Een kaartbetaling kan maanden later nog worden teruggeboekt, en dan haal je het geld niet meer bij de verkoper vandaan. Koppel de uitbetaling aan een gebeurtenis die het risico verkleint, zoals levering of het verstrijken van je retourtermijn. Bemiddel je in de verkoop van goederen, diensten, verhuur of vervoer, dan val je waarschijnlijk onder de DAC7-rapportageplicht voor platformexploitanten. Je moet dan gegevens van je verkopers verzamelen, verifieren en jaarlijks aanleveren bij de Belastingdienst. Gerelateerde expertise — API & Koppelingen **API-koppeling laten maken?** Wij bouwen betrouwbare integraties met monitoring, retry-logica en vaste prijs per koppeling. Vanaf € 1.000. [ Bekijk onze aanpak ](https://coding.agency/expertises/api-koppeling-laten-maken) [ Gratis prijsindicatie ](https://coding.agency/prijsindicatie) Onderwerpen Split payments Marktplaats Platform Stripe Mollie PSD2 Betalingen DAC7 ## Gerelateerde artikelen [ 29 jul. 2026 Betalingen ### Chargebacks en storneringen: terugboekingen opvangen in je software Chargebacks, disputes en SEPA-storneringen uitgelegd: termijnen per betaalmethode, wat je software moet vastleggen en hoe je terugboekingen... ](https://coding.agency/kennisbank/chargebacks-en-storneringen) [ 13 feb. 2026 Betalingen ### Stripe integratie laten maken: complete gids voor SaaS Stripe integratie voor abonnementen, trial periods, metered billing en proration. Stap-voor-stap gids voor SaaS-platforms — Checkout, Elemen... ](https://coding.agency/kennisbank/stripe-integratie-saas) [ 14 feb. 2026 Architectuur ### Idempotency bij API-koppelingen Waarom dubbele webhooks, retries en netwerkstoringen je data niet mogen vervuilen. Over idempotency keys, deduplicatie en robuuste integrati... ](https://coding.agency/kennisbank/idempotency-bij-api-koppelingen) ## Hulp nodig? Vragen over dit onderwerp? Laten we het erover hebben. [ Neem contact op ](https://coding.agency/contact) --- *Bron: [Coding Agency](https://coding.agency/kennisbank/split-payments-marktplaats-platform)*