Betalingswebhooks: modtag bekræftelser uden dobbelt levering

Vælg de forretningshandlinger, der skal udløses

Skriv først den handling, virksomheden ønsker: frigiv en ordre, opdatér en intern oversigt eller markér noget til undersøgelse. Find derefter de dokumenterede hændelser, der kan understøtte handlingen. Det er lettere at gennemgå en lille, bevidst liste end at lade alle indgående beskeder udløse generel logik. Forestil dig en ordre, der allerede er sendt, da en gentaget betalingsbekræftelse ankommer. Hændelsen må stadig registreres korrekt, men den må ikke starte endnu en levering. Adskil derfor registreringen af betalingsoplysningen fra beslutningen om at udføre virksomhedens næste opgave, og giv begge trin en tydelig identitet.

Signerede betalingsbeskeder

Kontrollér meddelelsen før indholdet bruges

En offentligt tilgængelig webhook-adresse kan modtage andet end de forventede beskeder. Modtageren skal følge den konkrete integrations metode til signaturkontrol og håndtering af beskedindhold. Stripe beskriver kontrol af egne webhook-signaturer; brug den dokumentation for Stripe og OrsunPays dokumentation for OrsunPays hændelser. Signaturformater og hemmeligheder er ikke udskiftelige. Hold hemmeligheden på serveren, og sørg for, at en udskiftning ikke sker tilfældigt under en fejlsøgning. En besked, som ikke kan verificeres, må ikke ændre en ordre til betalt. Gem kun de oplysninger, der er nødvendige for at undersøge fejlen, og beskyt adgang til dem.

Udviklerværktøjer

Lav varig registrering af behandlede hændelser

Et felt i hukommelsen er sjældent tilstrækkeligt til at huske, om en hændelse allerede er behandlet. Applikationen kan genstartes, og flere processer kan modtage arbejde samtidigt. Aftal en varig måde at registrere hændelsesidentiteten og den tilknyttede ordre på. Brug derefter en kontrolleret overgang, så to parallelle behandlinger ikke begge mener, at de skal sende varen. Den præcise implementering afhænger af systemets datamodel. Det centrale krav er, at gentagelse er sikker. Gennemgå både samme hændelse leveret igen og forskellige hændelser, som beskriver den samme endelige betalingsstatus. Begge kan være normale input til en robust ordreproces.

Forvent forsinkelse og undersøg ukendte udfald

Byg ikke hele forløbet på, at kunden og serveren får besked på samme tidspunkt. Kunden kan se en returadresse før den interne behandling er færdig, og en midlertidig fejl kan forsinke registreringen. Vis en passende afventende besked, og undgå at love, at der aldrig kommer forsinkelser. Hvis ordren bliver stående uden en forventet bekræftelse, bør drift kunne finde den oprindelige betalingsreference og undersøge den aktuelle status. Start ikke automatisk en ny betaling som løsning. Et ukendt udfald kræver afklaring af den eksisterende operation, før virksomheden beder kunden om endnu et forsøg.

Gør genbehandling til en kontrolleret handling

En genlevering løser kun problemet, hvis modtageren nu kan behandle beskeden korrekt. Find derfor årsagen før gentagelsen: forkert adresse, midlertidig utilgængelighed, signaturfejl eller en fejl i egen forretningslogik kræver forskellige handlinger. Notér hvilken hændelse der genbehandles, hvem der igangsætter det, og hvilket resultat der forventes. OrsunPays leveringshistorik kan hjælpe undersøgelsen, og tilgængelige kontrolhandlinger afhænger af rettigheder. Forsøg på genlevering er begrænsede. Sørg for en manuel procedure, hvis automatiske forsøg er brugt, og kontrollér til sidst selve ordren i stedet for kun at konstatere, at en HTTP-anmodning blev accepteret.

Aflever et driftskort sammen med integrationen

Et kort driftskort bør beskrive referencefelter, ansvarlige og de handlinger, som er sikre ved dubletter eller manglende beskeder. Gennemgå det med en medarbejder, der ikke skrev koden. Medarbejderen skal kunne finde en betaling, se seneste verificerede status og afgøre, om ordren allerede er opfyldt. OrsunPay tilbyder signerede betalingshændelser og leveringshistorik som tekniske værktøjer. De er ikke en erstatning for udbyderens afregningsoplysninger eller virksomhedens bogføring. Ved at holde ordrebeslutning, hændelsesbehandling og afregning adskilt kan teamet undersøge problemer uden at forveksle en leveret besked med penge, der allerede er bogført på bankkontoen.

Kilder

• Stripe Webhooks
• Stripe API: idempotent requests