Betalingen in je eigen platform met Mollie

Wil je in je eigen platform betalingen ontvangen, dan laat je het betalen zelf over aan een betaaldienst zoals Mollie. De klant rekent af op een pagina van Mollie, bijvoorbeeld met iDEAL, en jouw platform krijgt nooit bankgegevens te zien. Wat jouw platform wel moet regelen, is betrouwbaar vaststellen dat er betaald is. Dat gebeurt niet via de klant, maar via een bericht van Mollie aan je server, de webhook, waarna je programma de status zelf bij Mollie navraagt. Betalen is een van de bouwstenen van een eigen platform; de rest staat in Zelf een app of platform bouwen zonder programmeerervaring.

De route van een betaling

Een voorbeeld. Jeroen is installateur. Klanten kunnen op zijn site een onderhoudsbeurt voor hun cv-ketel inplannen en betalen daarbij meteen een aanbetaling. Achter de knop om te betalen gebeurt dan het volgende:

1. Het platform van Jeroen meldt de betaling aan bij Mollie, met het bedrag, een omschrijving, de pagina waar de klant na afloop moet uitkomen en het adres van de webhook. Die webhook is een vaste plek op zijn eigen platform, zoals /mollie/webhook, waar Mollie wijzigingen naartoe meldt.
2. Mollie antwoordt met een betaalnummer dat begint met tr_, en met een link naar de betaalpagina. Het platform koppelt dat nummer aan de afspraak en stuurt de klant door.
3. De klant rekent af bij Mollie, buiten het platform om.
4. Mollie roept de webhook aan met alleen het betaalnummer. Het platform vraagt daarop bij Mollie de actuele status op. Pas als die paid is, zet het de afspraak op betaald en mailt het de bevestiging.
5. De klant komt terug op de site van Jeroen, en die pagina toont wat er op dat moment in de database staat.

Zo beschrijft Mollie het ook in de uitleg over het ontvangen van betalingen. Mollie waarschuwt daar dat de webhook soms later binnenkomt dan de klant terugkeert. Laat de terugkeerpagina in dat geval melden dat de betaling nog wordt verwerkt, en na een paar seconden zelf opnieuw kijken.

Waarom de terugkeer van de klant niets bewijst

Het ligt voor de hand om een klant die terugkomt op je site als betaald te beschouwen. Toch gaat dat mis. De terugkeerpagina heeft gewoon een adres, en wie dat adres kent, kan het openen zonder te betalen. Andersom kan iemand netjes betalen en daarna zijn browser sluiten, zodat hij nooit terugkomt. In het ene geval geef je iets weg, in het andere mist een betalende klant zijn bevestiging.

De webhook heeft dat probleem niet, want die loopt van de server van Mollie naar de jouwe. Mollie geeft daarin bewust alleen het betaalnummer door, zonder de status. In de documentatie over webhooks legt Mollie uit waarom: omdat de status er niet in staat, kan een vervalst bericht nooit leiden tot een verwerkte bestelling zonder betaling. Je programma haalt de status immers zelf op. Kent je programma een binnenkomend nummer niet, dan antwoordt het toch met de gewone bevestiging van ontvangst, de code 200. Dat raadt Mollie aan, zodat een buitenstaander er niets wijzer van wordt.

Wat er onderweg mis kan gaan

Mollie wacht vijftien seconden op die bevestiging van ontvangst. Komt die niet, dan probeert Mollie het later opnieuw, tot tien keer in totaal, verspreid over zo’n 26 uur. Je platform moet er dus tegen kunnen dat hetzelfde bericht meer dan eens binnenkomt. Bij een herhaling mag er niets nieuws gebeuren: geen extra mail en geen tweede afspraak.

Een betaling kan ook zonder geld eindigen. De klant breekt af (canceled), de betaling mislukt (failed), of de klant doet niets en de betaling vervalt (expired). Bij iDEAL gebeurt dat laatste na vijftien minuten, volgens het overzicht van betaalstatussen. Jeroen houdt het gekozen tijdvak vast zolang de klant aan het betalen is. Komt een van die statussen binnen, dan maakt zijn platform het tijdvak weer vrij. Mollie raadt daarbij af om zelf uit te rekenen wanneer een betaling verloopt: wacht op de webhook en vraag de status op.

Twee dingen hebben met bereikbaarheid te maken. Mollie moet je webhook vanaf internet kunnen bereiken, en een adres met localhost wordt niet geaccepteerd. Je platform moet dus al op een eigen adres met https staan voordat je betalingen kunt proberen. En de webhook mag niet achter je inlogscherm zitten, want Mollie logt niet in. Dat is geen risico, juist omdat je programma de status altijd zelf navraagt.

Testen voordat het om echt geld gaat

Mollie geeft je per website twee API-sleutels. Een API-sleutel is een soort wachtwoord waarmee je programma zich bij Mollie bekendmaakt. De sleutel die begint met test_ gebruik je tijdens het bouwen, die met live_ voor echte betalingen. Wat je met de testsleutel doet, blijft volledig gescheiden van je echte gegevens. Bij het betalen kom je dan op een testpagina, waar je zelf aanklikt hoe de betaling afloopt. Voor de rest gedraagt Mollie zich in testmodus hetzelfde, ook bij de webhook. Dat staat in de uitleg over testen.

Probeer in testmodus niet alleen een betaling die slaagt, maar juist ook de afloop die misgaat, zoals een mislukte en een afgebroken betaling. Kijk na elke poging naar de status in je beheerscherm en naar je mailbox. Klopt alles, dan wissel je alleen de testsleutel voor de live-sleutel en herstart je je platform, zodat het de nieuwe sleutel gebruikt. Een eerste echte betaling van een klein bedrag, die je daarna via Mollie terugboekt, is een goede laatste controle. Voor echte betalingen moet Mollie je account wel eerst controleren en je betaalmethodes activeren; testen kan meteen.

Bewaar de sleutel in een apart bestand, meestal .env, dat niet in je code en niet in git staat, en plak hem nooit in een gesprek met Claude. Mollie toont een nieuwe sleutel om veiligheidsredenen alleen bij het aanmaken, dus kopieer hem direct naar je .env. Is een sleutel uitgelekt, maak dan een nieuwe en verwijder de oude. Mollie staat een tweede sleutel per website toe, zodat je zonder onderbreking kunt overstappen; dat staat bij Mollie over API-sleutels. Waarom dit zo zwaar weegt, lees je in Wachtwoorden en API-sleutels in je code.

Wat er verder bij hoort

Verkoop je aan consumenten, dan moet je site aan een aantal regels voldoen, van je bedrijfsgegevens tot de bedenktijd die een klant vaak heeft. Welke gegevens er op je site moeten staan, lees je in Wat er wettelijk op je bedrijfswebsite moet staan. Dit is geen juridisch advies. Algemene voorwaarden laat je daarom niet door Claude bedenken: die laat je opstellen of nakijken door iemand die er verstand van heeft.

Bewaar bij elke betaling verder niet meer dan nodig. Het betaalnummer van Mollie is genoeg om alles terug te vinden, want de rest staat bij Mollie. Hoe je dat nummer netjes bij de afspraak vastlegt, staat in Een database voor beginners.

Ga je betalen inbouwen, vraag Claude dan eerst om zijn aanpak, met een officiële bibliotheek van Mollie, en leg die naast de route hierboven. Kijk vooral of een betaling pas na de webhook en een eigen controle op betaald gaat, en of een herhaald bericht niets dubbel doet. Pas dan laat je het bouwen, en pas als alle testgevallen kloppen, gaat de live-sleutel erin. In de leerlijn Platformen van het online programma doorloop je zo’n testbetaling stap voor stap.