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.
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.
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.
Ze verschillen sterk in wat je moet bouwen.
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.
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.
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.
Vijf dingen die je in het ontwerp meteen goed kunt zetten.
Wat je nodig hebt om te testen of mensen willen betalen, is minder dan een compleet afrekensysteem.
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.
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.
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.
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.
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.
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.
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.
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.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.