Een dubbele betaalwebhook hoort voor dezelfde geverifieerde transactie één bedoelde leveringshandeling op te leveren. Controleer bij PayRequest payment.succeeded eerst de handtekening over de oorspronkelijke body en gebruik daarna transactie-ID data.id in een duurzame verwerkingssleutel. Een herhaalde melding mag geen extra levering of servicetegoed maken.
Dit is een ontwerp- en acceptatiechecklist voor ontwikkelaars met een eigen leveringssysteem. Een databaserecord garandeert op zichzelf geen precies-eenmaalhandeling in een extern systeem.
Controleer het echte webhookcontract
De PayRequest-webhookdocumentatie beschrijft HTTPS POST, X-PayRequest-Signature en HMAC-SHA256 over de oorspronkelijke requestbody. Gebruik een serversecret en tijdveilige vergelijking. Controleer formaat en lengte van de header: sommige vergelijkingsfuncties weigeren ongelijke lengtes. Bewaar de oorspronkelijke bytes voordat JSON wordt verwerkt.
Bij payment.succeeded is data.id het transactie-ID. De gepubliceerde betaalpayload documenteert geen apart event-ID op het hoogste niveau. Kopieer dus geen event.id-aanpak van een andere provider zonder controle. Houd secrets uit browsercode en log niet onnodig volledige klantgegevens.
Identificeer de betaling, niet de link
Een voorbeeldsleutel is integration-account / payment.succeeded / data.id. Neem accountscope op wanneer meerdere zakelijke accounts dezelfde ontvanger gebruiken. Dit is een eigen ontwerp, geen ingebouwd PayRequest-veld.
Een payment_link_id kan bij meerdere geldige betalingen horen. E-mail, bedrag en omschrijving zijn evenmin goede unieke sleutels: dezelfde klant kan tweemaal kopen. Dezelfde data.id vraagt herhalingsverwerking; een nieuwe data.id op dezelfde link is een nieuwe betaling.
Koppel de transactie via een gecontroleerde integratiereferentie aan een echte order of aanspraak. Een succesmelding bepaalt niet vanzelf pakket, periode of hoeveelheid. Zet onbekende referenties apart voor beoordeling.
Vergelijk bedrag en valuta met de bedoelde order voordat je levering toestaat. Onverwachte waarden vragen beoordeling in plaats van automatische levering.
Sla duurzaam op vóór bevestiging
Gebruik een unieke databaseconstraint en één atomaire transactie voor de geaccepteerde betaling en één wachtende leveringstaak. Een duurzame outbox scheidt ontvangst van langzaam werk. Bevestig succesvol na duurzame acceptatie; een bekende herhaling maakt geen nieuwe taak.
PayRequest accepteert 2xx. De docs noemen vijf pogingen voor depositwebhooks, maar voor betalingen alleen het bestaande queuebeleid zonder aantal. Gebruik het depositschema niet als betaalretrybeleid of bewaartermijn voor deduplicatie.
Crashes blijven mogelijk: een externe levering kan slagen voordat de worker voltooiing opslaat. Gebruik ondersteunde downstream-idempotentie of verifieer het externe resultaat vóór opnieuw leveren. Het lokale register garandeert geen precies-eenmaaluitkomst tussen systemen.
Voer deze originele replaymatrix uit
Test in een geïsoleerde ontvanger met fictieve, ondertekende gegevens en zonder echte levering. Onderteken fixtures met een testsecret; een gewijzigde body vraagt een nieuwe handtekening. Dit zijn voorgestelde tests, geen productieaccounttests.
| Test | Invoer | Vereiste uitkomst |
|---|---|---|
| Herhaling | Dezelfde transactie tweemaal | Eén betaling en één taak |
| Gelijktijdigheid | Twee geldige kopieën tegelijk | Unieke constraint voorkomt twee taken |
| Tweede aankoop | Zelfde link, nieuw transactie-ID | Twee betalingen en taken |
| Vervalsing | Gewijzigde body, oude handtekening | Afwijzing vóór levering |
| Workeronderbreking | Crash na duurzame taakopslag | Wachtend werk herstelbaar |
Test ook onbekende referenties en ongeldige handtekeninglengtes. Tel opgeslagen records en externe handelingen apart. HTTP 200 bevestigt ontvangst, geen afgeronde levering.
Stem geld en levering afzonderlijk af
Bewaar transactie-ID, accountscope, verwerkingsstatus, taak-ID en externe resultaatreferentie. Onderzoek betaalde transacties met wachtende levering via dezelfde gecontroleerde route, zonder handmatige tweede levering buiten het register.
Begin met de PayRequest API-documentatie. Bekijk Betalingen matchen voor financiële afstemming; betaling en levering zijn afzonderlijke records.
Redactionele toelichting: AI hielp bij artikel en cover. Contract gecontroleerd op 4 oktober 2026. Sleutel, matrix en architectuur zijn originele aanbevelingen, geen productie-integratietest of leveringsgarantie.
