Betalingen veilig verifiëren

Zelfs een echt, ondertekend evenement moet je vergelijken met wat je verwacht. Controleer of het bedrag en de valuta overeenkomen met wat de bestelling had moeten kosten.

Als een bestelling van $9 een betaling van $0.50 meldt, wijs je die af. De handtekening bewijst dat het bericht van de aanbieder komt; de bedragcontrole bewijst dat de klant heeft betaald wat verschuldigd is.

Aanbieders leveren webhooks ten minste één keer af, dus dubbele leveringen zijn normaal. Als je verwerker tegoeden toekent of een abonnement verlengt, kan het tweemaal verwerken van hetzelfde evenement echte schade veroorzaken.

Sla elke verwerkte evenement-ID op en sla herhalingen over. Zorg dat je verwerker een willekeurig aantal keer veilig voor hetzelfde evenement kan worden uitgevoerd.

Verificatie betekent dat je het record van de aanbieder vergelijkt met je eigen record. Haal het gezaghebbende object op — de betaalintentie of het abonnement — en vergelijk de status ervan met wat je verwacht voordat je actie onderneemt.

Door de gegevens opnieuw op te halen via de API van de aanbieder in de verwerker, verklein je het verschil tussen een mogelijk verouderd evenement en de actuele werkelijkheid.

Aanbieders verwachten snel een 2xx-antwoord; anders proberen ze het opnieuw, waardoor dubbele leveringen ontstaan. Bevestig de ontvangst meteen en voer zwaar werk daarna asynchroon uit.

Het patroon: controleer de handtekening, zet het evenement in de wachtrij en geef 200 terug. Een achtergrondwerker voert de levering uit. Zo blijft het eindpunt betrouwbaar bij hoge belasting en tijdens trage bewerkingen.

API-sleutels, webhookgeheimen en ondertekeningssleutels zijn inloggegevens. Als je ze hardcodeert in de broncode of naar de client meestuurt, wacht er een beveiligingslek om te gebeuren.

Sla ze op in omgevingsvariabelen of een geheimenbeheerder. De geheime sleutel mag alleen op je server staan; de client krijgt de publiceerbare sleutel, die veilig openbaar kan zijn.

Geldstromen lopen ook terug. Een terugbetaling of een geschil over een afschrijving moet de toegang intrekken of de toegangsrechten aanpassen, aangestuurd door webhookevenementen zoals charge.refunded en charge.dispute.created.

Als je alleen de betaling afhandelt en de terugboeking negeert, houdt een klant die geld heeft teruggekregen gratis toegang tot betaalde functies. Verbind de terugkerende evenementen net zo zorgvuldig als de heenweg.

Wanneer er geld bij betrokken is, heb je een onveranderlijk spoor nodig. Leg elke ontvangen webhook, elke beslissing over productlevering en elke wijziging van toegangsrechten vast met tijdstempels en ID's.

Dit controlelogboek is je verdediging bij een geschil en je snelste hulpmiddel bij het opsporen van fouten wanneer een klant zegt: "Ik heb betaald, maar heb geen toegang". Leg nooit onbewerkte kaartgegevens vast, alleen verwijzingen.

Wanneer verificatie mislukt — door een onjuiste handtekening, een niet-overeenkomend bedrag of een onbekende bestelling — is de veilige standaardinstelling toegang weigeren en jezelf waarschuwen, niet het voordeel van de twijfel geven.

Een betaalsysteem moet gesloten falen. Een vals-negatieve uitkomst ergert één klant die je handmatig kunt helpen; een vals-positieve uitkomst geeft je product weg of nodigt uit tot fraude.

Controleer voordat je live gaat de hele keten: handtekening geverifieerd, bedrag en valuta komen overeen, evenement idempotent verwerkt, object van de aanbieder vergeleken, geheimen in de omgeving, terugbetalingen afgehandeld en fouten leiden tot gesloten falen.

Vraag je AI-assistent om de integratie aan de hand van deze lijst te controleren. Elk ontbrekend item is een deur waar een aanvaller of fout doorheen kan lopen.

Veilige verificatie betekent dat je alleen de ondertekende signalen van de aanbieder aanvaardt. Controleer de handtekening van elke webhook, controleer daarna het bedrag en de valuta, verwerk evenementen idempotent en vergelijk ze met het actuele object van de aanbieder voordat je toegang verleent.

Bewaar geheimen in omgevingsvariabelen, reageer snel en verwerk asynchroon, handel terugbetalingen en geschillen af door toegang in te trekken, leg een controlespoor vast en laat het systeem altijd gesloten falen. Doorloop de volledige checklist voordat je live gaat.