Betalingen inbouwen in je MVP

Betalen is het onderdeel waarvan founders denken dat het het moeilijkst is, terwijl het meestal meevalt. Het echte werk zit niet in de betaling zelf maar in wat er daarna gebeurt: bijhouden wie wat betaald heeft, omgaan met mislukte incasso's en het geld op de juiste plek krijgen als er meer dan twee partijen zijn.

Terug naar OneDayBuild
01/06

Wat je inkoopt en wat je bouwt

De scheidslijn ligt bij het moment dat het geld binnen is.

Een betaaldienstverlener regelt het betaalscherm, de aansluiting op iDEAL en kaartschema's, de fraudecontrole en het uitbetalen naar je rekening. Dat koop je in, en zelf bouwen is er geen alternatief voor: kaartgegevens verwerken brengt eisen met zich mee waar je niet aan wilt beginnen.

Wat jij bouwt is alles daaromheen. Weten welke bestelling bij welke betaling hoort, wat er gebeurt als iemand halverwege afhaakt, hoe je een openstaande factuur toont en wat de app doet als een betaling een dag later alsnog binnenkomt. Dat is administratie, en daar gaan de meeste uren in zitten.

De belangrijkste technische keuze is dat je nooit vertrouwt op de terugkeer van de gebruiker naar je app. Iemand sluit zijn browser, en toch is er betaald. De betaling is pas een feit als de betaaldienst het je via een webhook meldt.

02/06

Drie soorten betalen

Ze verschillen sterk in wat je moet bouwen.

Eenmalig afrekenen

Een bedrag, een keer, klaar. Met een hosted checkout is dit in een dagdeel werkend te krijgen. Je houdt zelf bij welke bestelling betaald is en wat er gebeurt bij een mislukte poging.

Abonnementen

Terugkerende incasso met opzeggen, pauzeren, upgraden en proefperiodes. De incasso zelf levert de dienst; het bijhouden van wie wat mag op welk moment is jouw werk en dat is meer dan het lijkt.

Uitbetalen aan derden

Bij een marktplaats gaat het geld naar de aanbieder en houd jij een deel in. Dat vraagt om een constructie waarbij jij het geld niet zelf beheert, en dat is de duurste van de drie om goed te doen.

03/06

Waar het in de praktijk misgaat

Vijf dingen die je in het ontwerp meteen goed kunt zetten.

  • Vertrouwen op de terugkeerpagina. De gebruiker komt niet altijd terug. Verwerk de status uitsluitend op basis van de melding die de betaaldienst je stuurt, en zorg dat dezelfde melding twee keer verwerken geen dubbele bestelling oplevert.
  • Het bedrag aan de voorkant bepalen. Wat de browser meestuurt kan aangepast worden. Reken het bedrag altijd opnieuw uit op de server voordat je de betaling aanmaakt.
  • Geen enkele mislukking afhandelen. Incasso's mislukken, kaarten verlopen. Zonder een plan voor herinneren, opnieuw proberen en uiteindelijk blokkeren, ontstaan er stilletjes gratis gebruikers.
  • Btw pas achteraf bedenken. Verkoop je aan consumenten in andere EU-landen, dan speelt het btw-tarief van hun land. Dat is later inbouwen veel vervelender dan het bij de eerste versie meenemen.
  • Terugbetalen vergeten. Een knop om terug te betalen lijkt luxe tot je hem nodig hebt en het handmatig in het portaal van je betaaldienst moet doen, zonder dat je eigen app het weet.
04/06

In een eerste versie

Wat je nodig hebt om te testen of mensen willen betalen, is minder dan een compleet afrekensysteem.

Wel meteen
  • Een hosted checkout, zodat je zelf geen betaalgegevens aanraakt.
  • Een webhook die de betaling bevestigt, ook als de gebruiker wegklikt.
  • Een overzicht in je app van wie wat betaald heeft.
  • Bedragen die op de server worden berekend.
Kan wachten
  • Een eigen factuurlayout met je huisstijl erop.
  • Meerdere betaalmethoden naast iDEAL en kaart.
  • Automatische aanmaningen en incassoschema's.
  • Uitbetalen aan derden, tenzij dat de kern van je idee is.
05/06

Wat we op een bouwdag halen

Een werkende betaling met echte statussen is haalbaar; een compleet abonnementsmodel niet.

Een eenmalige betaling met een hosted checkout, een webhook en een zichtbare status in je app krijgen we op een dag werkend, inclusief een testbetaling die je zelf kunt doen. Dat is genoeg om aan een klant of investeerder te laten zien dat de kassa rinkelt.

Abonnementen kunnen ook, in eenvoudige vorm: één plan, aanmelden en opzeggen. Wat er niet in past is het volledige gedrag rondom upgrades, proefperiodes, verlopen kaarten en terugbetalingen. Dat is geen dagwerk en het is ook zelden wat je wilt valideren.

Uitbetalen aan derden houden we bewust buiten een bouwdag. De constructie waarbij jij geld van anderen doorgeeft, vraagt om afspraken met je betaaldienst en soms om meer dan dat. Wel kunnen we het in de demo zichtbaar maken, zodat het model uit te leggen is.

06/06

Veelgestelde vragen

Mag ik zelf creditcardgegevens opslaan?

Doe dat niet. Zodra je kaartgegevens aanraakt, gelden er zware eisen aan je systemen en processen. Met een hosted checkout of een veld dat door je betaaldienst wordt geleverd, komen die gegevens nooit in jouw systeem terecht en blijft die last bij de partij die er gespecialiseerd in is.

Wat is een webhook en waarom is die belangrijk?

Een bericht dat de betaaldienst naar jouw app stuurt zodra de status van een betaling verandert. Dat is de enige betrouwbare bron: de gebruiker kan zijn browser sluiten voordat hij terugkeert, terwijl er wel betaald is. Zorg dat je hetzelfde bericht twee keer kunt ontvangen zonder dat er iets dubbel gebeurt.

Heb ik voor een prototype een echte betaalaccount nodig?

Voor een demo niet: betaaldiensten hebben een testmodus waarin je de hele stroom kunt doorlopen zonder geld. Wil je echt geld ontvangen, dan hoort daar een aanmelding met bedrijfsgegevens bij en die goedkeuring duurt even. Begin daar dus op tijd mee als je van plan bent live te gaan.

Hoe zit het met btw als ik aan het buitenland verkoop?

Bij verkoop aan consumenten in andere EU-landen speelt het tarief van het land van de klant, met een drempelregeling voor kleine omzetten. Sommige betaaldiensten en factuurtools rekenen dat voor je uit. Het is een boekhoudkundige vraag die je met je accountant afstemt voordat je de app inricht, want achteraf aanpassen is vervelend.

Wat kost een betaaldienst?

Meestal een bedrag per transactie plus een percentage, met verschillen per betaalmethode. Tarieven veranderen en verschillen per aanbieder en per volume, dus vergelijk ze op het moment dat je kiest. Belangrijker dan het tarief is meestal of de methoden die jouw klanten gebruiken ondersteund worden.

Wat als mijn platform geld doorbetaalt aan aanbieders?

Dan zit je in een ander regime dan gewoon afrekenen. Geld van anderen onder je beheer houden raakt aan financieel toezicht. Betaaldiensten bieden hiervoor constructies waarbij zij de geldstroom houden en jij alleen de verdeling bepaalt. Regel dat vóór je bouwt, want het bepaalt het ontwerp.

Wil je zien of mensen daadwerkelijk afrekenen?

In een bouwdag zetten we een werkende betaalstroom neer met echte statussen, zodat je het aan een klant kunt laten zien in plaats van beschrijven.