Hé — ik zag je bericht vanochtend, de screenshot van iemand die "hoe betaal ik je hiervoor" vraagt in de supportinbox van je app. Oprechte felicitaties. Dat is het moment waarop een side-project stopt met een demo te zijn. Het is ook het moment waarop honderd kleine beslissingen die je hebt kunnen uitstellen, allemaal op dezelfde dinsdag opduiken. Je vroeg me om je gewoon te vertellen wat je moet doen. Dat ga ik doen, maar ik wil je eerst door de reden heen leiden, want die "waarom" is wat voorkomt dat je me over drie maanden opnieuw moet vragen wanneer het Lemon Squeezy is in plaats van Stripe, of abonnementen in plaats van eenmalig.
De beslissing die je eigenlijk neemt
Je noemde dit "welke betalingsprovider moet ik gebruiken", maar dat zijn eigenlijk twee beslissingen die op elkaar gestapeld zijn. Ten eerste: wil je de merchant of record zijn, of wil je dat iemand anders dat is? Ten tweede: wat is je factureringsvorm — eenmalige aankoop, abonnement, of gebruiksgebaseerd? Als je de eerste verkeerd hebt, ben je over zes maanden een weekend kwijt aan het registreren voor btw in een land waar je nog nooit bent geweest. Als je de tweede verkeerd hebt, is het een vervelende migratie, geen juridische, dus dat is de minder angstaanjagende van de twee.
Merchant of record zijn betekent dat jij degene bent die het product juridisch verkoopt. Jij int het geld, jij bent verantwoordelijk voor het uitzoeken van omzetbelasting en btw in elk rechtsgebied waar je klanten wonen, en jij dient de aangiftes in. Stripe berekent die belasting graag voor je (Stripe Tax), maar berekenen is niet hetzelfde als afdragen — je moet je nog steeds registreren en aangifte doen in elke plaats waar je een drempel overschrijdt. Een merchant-of-record-dienst zoals Lemon Squeezy of Paddle neemt dat hele probleem van je over: zij zijn juridisch de verkoper, zij innen en dragen overal belasting af, en zij keren jou het netto uit. Daarvoor lever je een deel van je marge in.
| Optie | Wie is de verkoper | Gebruikelijk tarief | Belastingafhandeling | Geschikt voor |
|---|---|---|---|---|
| Stripe (direct) | Jij | ~2,9% + $0,30/transactie, +0,5% voor Stripe Tax | Jij registreert en dient aangifte in, Stripe berekent alleen | Je verwacht door te groeien naar meer dan een paar duizend per maand en wilt op lange termijn lagere kosten |
| Lemon Squeezy | Lemon Squeezy | ~5% + $0,50/transactie | Volledig geregeld, zij zijn de verkoper van record | Solo-bouwer, eerste product, wil helemaal niet aan belasting denken |
| Paddle | Paddle | ~5% + kosten variëren per regio | Volledig geregeld, meer gericht op enterprise | SaaS met abonnementen en enige facturatiebehoeften |
| PayPal | Jij | ~3,5-4,5%, kopersvriendelijke geschillenafhandeling | Jij regelt het zelf | Klanten die specifiek PayPal vertrouwen, geen standaardkeuze |
Voor waar je nu staat — één klant, een eenvoudig product, nog geen idee of dit een bedrijf wordt — zou ik je naar Lemon Squeezy of Paddle wijzen in plaats van rechtstreeks Stripe. De extra twee procentpunten aan kosten zijn een goedkope verzekering tegen het per ongeluk worden van een belastingaangever in een staat waar je nooit een voet hebt gezet. Je kunt later altijd migreren naar directe Stripe, zodra het volume de overstap rechtvaardigt en je de maag hebt voor het papierwerk. Niemand migreert voor de lol tussen betalingsproviders, maar het is een oplosbare dinsdag, geen oplosbaar jaar.
Ik heb deze fout zelf gemaakt bij een eerder project — rechtstreeks naar Stripe gegaan omdat "iedereen Stripe gebruikt", een paar honderd dollar per maand geïnd van een handjevol Europese klanten, en achttien maanden later een heel beleefde maar heel verwarrende e-mail gekregen over btw-MOSS-registratie. Het kostte me een middag van een boekhouder en veertig minuten pure paniek googelen naar "ben ik Nederland geld verschuldigd". Niet catastrofaal. Ook volledig te vermijden.
Voordat je de live keys aanraakt
Wat je ook kiest, zet het niet als eerste in productiemodus. Elk van deze providers heeft een test-/sandboxmodus met nepkaartnummers die specifieke uitkomsten triggeren — geslaagde betaling, geweigerde kaart, vereist 3D Secure, onvoldoende saldo. Doorloop ze allemaal voordat je een echte key aanraakt. De faalpaden zijn degene die je in de eerste week echt tegenkomt, en ze zijn veel minder leuk om live te debuggen met de kaart van een echt persoon eraan gekoppeld.
Wees in je bouwchat expliciet dat je dit gefaseerd wilt: vraag eerst om de integratie aangesloten op testmodus, met een duidelijk zichtbare banner of vlag zodat niemand — inclusief jijzelf in de toekomst — per ongeluk een echte kaart belast tijdens het testen. Zet dan een tweede, bewuste stap waarin je live keys inwisselt. Twee prompts, geen een, ook al zou het sneller zijn om gewoon "voeg betalingen toe" te zeggen en het de modus te laten raden. De wrijving is het punt.
Je moet ook beslissen wat er gebeurt als een webhook afgaat terwijl je server plat ligt, traag is, of het event twee keer aankomt. Dit is geen hypothese — het gebeurt betrouwbaar in de eerste week. De events die je minimaal moet afhandelen:
checkout.session.completed(of het equivalent) — verleen toegang, dit is het moment waarop de klant klant wordtinvoice.payment_failed— bepaal bij abonnementen nu al of dat een directe uitsluiting of een respijtperiode wordt, want "directe uitsluiting" is een echt slechte eerste indruk voor een kaart die net een tijdelijke hobbel hadcustomer.subscription.deleted— iemand heeft opgezegd, trek toegang in aan het einde van de periode, niet meteen, tenzij je voorwaarden anders bepalen- Een terugbetalingsevent — beslis één keer, op papier voor jezelf, wat je terugbetalingsbeleid daadwerkelijk is, voordat het eerste terugbetalingsverzoek je dwingt het live te beslissen
Idempotentie is hier belangrijker dan bijna overal elders in je app. Als een webhook twee keer aankomt — en dat zal gebeuren, providers doen retries bij elke niet-200-respons — mag je geen toegang twee keer verlenen of, erger, interne status dubbel in rekening brengen. Sla het event-ID op en controleer of je het niet eerder hebt verwerkt voordat je erop reageert.
De prijsvraag die je vermijdt
Je noemde in je bericht dat je niet zeker wist of je $9/maand moest vragen of eenmalig $49. Ik denk niet dat een van beide fout is, maar merk op wat je eigenlijk vermijdt: het gesprek met de klant over wat de terugkerende waarde is. Een eenmalige prijs is makkelijker om ja tegen te zeggen en makkelijker voor jou om te bouwen (geen dunning, geen afhandeling van mislukte verlengingen, geen opzegflow). Een abonnement is een gok dat je het product genoeg blijft verbeteren zodat mensen niet weglopen — dat is een echte verplichting, niet zomaar een vinkje op een prijspagina. Als je niet zeker weet of je hier over zes maanden nog actief aan werkt, is een eenmalige prijs het eerlijkere aanbod. Je kunt later altijd een abonnementstier toevoegen zodra er iets doorlopends is om je op te abonneren.
Nog één ding, en dan laat ik je verder gaan: zet een echt terugbetalings- en opzeggingsbeleid op de pagina voordat je de eerste dollar int, ook al zijn het maar drie zinnen. Niet omdat iemand je gaat aanklagen voor een betaling van $9, maar omdat het opschrijven je dwingt het daadwerkelijk te beslissen, en "ik zoek het wel uit als iemand ernaar vraagt" is hoe je uiteindelijk midden in een boze e-mail een beleidsbeslissing neemt in plaats van op een rustige middag.
Ga eerst de sandbox aansluiten. Sms me zodra je er een nepgeweigerde kaart doorheen hebt gehaald — dat is de versie van "het werkt" die er echt toe doet.
