Het kernprobleem
Je klanten klagen. Geld verdwijnt als een spook in de nacht, en support zit tot over je oren in tickets. De tweerichtingsmethode van Trustly, bedoeld als de heilige graal van realtime betalingen, blijkt een lekke boot.
Wat is de tweerichtingsmethode?
Trustly claimt: “bank-naar-bank, direct, zonder tussenpersonen.” In de praktijk betekent het een API-koppeling die zowel stortingen als opnames in één stroom laat verlopen. Simpel, toch? Niet wanneer de backend-logica van jouw platform niet synchroon loopt met de Trustly-endpoint.
Waarom het misgaat
Ten eerste: race-conditions. Terwijl een speler €50 inzet, stuurt Trustly al een bevestiging van “gelukt”, maar jouw database heeft de transactie nog niet gecommit. Het resultaat? Dubbele credits, of nog erger, een lege portemonnee.
Ten tweede: fallback-mechanismen die je zelf niet geconfigureerd hebt. Trustly stuurt een “reversal” wanneer de verbinding wegvalt, maar je systeem negeert die melding. De geldstroom wordt een zwarte gat.
De knelpunten in je implementatie
Je hebt een monolithisch systeem. Trustly’s webhook-calls komen binnen, en jouw legacy-code probeert ze te verwerken met een simpele IF-statement. Dat is alsof je een raceauto probeert te sturen met een houten stuurwiel.
En die beveiligingslagen – of beter gezegd, het gebrek daaraan – zorgen ervoor dat fraudepatronen makkelijk door de mazen van het net glippen. Trustly biedt een “fraud-score”, maar jij negeert die score omdat “het vertraagt”. Fout.
Hoe je het kunt fixen
Hier is de deal: verplaats de betalingslogica naar een event-driven microservice. Laat elk inkomend Trustly-event een queue-bericht worden, en verwerk het asynchroon met een transaction-manager die ACID-garanties biedt.
Implementeer een retry-mechanisme. Als een webhook faalt, zet het bericht terug in de queue met exponentiële back-off. Zo voorkom je dat een enkele glitch je hele flow platlegt.
En ja, je moet de fraud-score serieus nemen. Zet een drempelwaarde en blokkeer automatisch elke transactie die boven die drempel uitkomt. Het kost je een paar seconden, maar bespaart je miljoenen later.
Praktisch voorbeeld
Stel, een speler drukt op “Storten €100”. Trustly stuurt een POST-request met een unieke transaction-ID. Jouw service plaatst dit ID in een Redis-queue, start een database-transactie, en wacht op bevestiging. Zodra de DB-commit slaagt, publiceer je een “success” event terug naar Trustly. Als de DB faalt, stuur je een “reversal” request. Simpel, robuust, en je elimineert die race-condition.
Check de integratie van Sofortüberweisung wat gebeurd voor een vergelijkbare flow. Je ziet hoe een correcte tweerichtingsmethode er uit moet zien.
Actiepunt
Pak die webhook-handler nu, zet ‘m in een queue, en voeg een transaction-manager toe – dan stopt het drama meteen.