Betalningswebhook: verifiera händelser och undvik dubbel leverans

Definiera åtgärden före händelselistan

Beskriv en konkret uppgift och koppla den till rätt dokumenterade händelse. En liten och medvetet vald lista är enklare att drifta än en mottagare som försöker reagera på allt. Föreställ dig en order som redan skickats när samma betalningsbekräftelse levereras igen. Meddelandet kan vara giltigt, men företaget ska inte skicka en extra vara. Separera därför registrering av betalningsuppgiften från själva orderåtgärden. Ge båda stegen tydliga identiteter. Support behöver kunna se vad som mottagits, vad som behandlats och vad verksamheten faktiskt har gjort. Det minskar risken att en teknisk omleverans förväxlas med ett nytt köp eller en ny uppgift till lagret.

Signerade betalningsmeddelanden

Verifiera enligt den aktuella integrationens kontrakt

En publik webhook-adress kan ta emot andra förfrågningar än dem företaget väntar sig. Behandla innehållet som obekräftat tills den dokumenterade kontrollen är klar. Följ rätt metod för signatur och meddelandeformat. Stripe beskriver egna webhook-signaturer; den kontrakten ska inte antas vara densamma som OrsunPays händelser. Hemligheter för kontrollen ska stanna på servern och ha en tydlig ägare. Ett meddelande som inte kan verifieras får inte ändra ordern till betald. Gör samtidigt felet möjligt att undersöka utan att samla onödiga kunduppgifter i loggar. Vid byte av nyckel ska teamet kontrollera miljö och aktiv konfiguration enligt en planerad rutin.

Utvecklarverktyg

Gör upprepad behandling säker över tid

Samma händelse kan nå mottagaren igen, och flera processer kan behandla arbete samtidigt. En markering som bara ligger i minnet ger inte alltid tillräckligt skydd mot dubbla åtgärder. Använd varaktiga relationer mellan händelse, betalning och order. Beslutet att utföra nästa steg behöver vara kontrollerat så att två parallella behandlingar inte båda startar leveransen. Undersök också olika händelser som beskriver samma slutresultat. Det är inte enbart identiska meddelanden som kan leda till dubbelarbete. Dokumentera hur systemet agerar när ordern redan har korrekt status. En upprepning ska vara säker och samtidigt lämna en begriplig spårning för dem som granskar ärendet senare.

Förbered försenade eller saknade uppdateringar

Kundens retursida och serverhändelsen kan komma vid olika tidpunkter. Visa en lämplig väntestatus när resultatet inte är klart och be inte kunden betala igen enbart därför. Om ordern saknar en förväntad uppdatering behöver drift hitta betalningsreferensen och kontrollera aktuell status. Undersök om problemet gäller betalningen, leveransen av meddelandet eller behandlingen i det egna systemet. Dessa delar kräver olika åtgärder. En accepterad HTTP-förfrågan betyder inte nödvändigtvis att orderarbetet är slutfört. Följ därför hela vägen till affärsresultatet. Ange vilken uppgift som senast var verifierad, så att nästa medarbetare kan fortsätta utredningen från samma grund i stället för att börja om.

Återleverera först när orsaken är förstådd

En ny leverans hjälper inte om samma fel fortfarande blockerar mottagaren. Kontrollera adress, tillgänglighet, signaturhantering och den interna logiken innan händelsen behandlas på nytt. Notera vilken händelse det gäller, vem som initierar åtgärden och vilket resultat som förväntas. OrsunPays leveranshistorik kan stödja undersökningen; tillgängliga kontroller beror på behörigheter. Automatiska återförsök är begränsade. Det behövs därför en manuell rutin när de har använts. Kontrollera efteråt att rätt orderstatus uppnåtts, inte bara att servern svarat utan fel. Samma rutin måste tåla att någon senare granskar ärendet och behöver skilja den ursprungliga betalningen från de tekniska försöken att leverera dess besked.

Överlämna en driftguide som går att använda

Driftguiden bör beskriva referenser, ägarskap och tillåtna åtgärder vid upprepningar eller saknade meddelanden. Låt en person som inte skrev integrationen hitta en order med hjälp av guiden. Personen ska kunna se senaste verifierade status och om leverans redan är utförd. OrsunPay tillhandahåller signerade betalningshändelser och leveranshistorik som tekniska verktyg. De ersätter inte leverantörens avräkningsuppgifter eller företagets redovisning. Håll dessa syften separata i rapporter och instruktioner. Då kan teamet undersöka en försenad händelse utan att förväxla en teknisk kvittens med en banköverföring, och utan att skapa en ny debitering när problemet egentligen gäller orderuppdateringen efter en redan genomförd betalning.

Källor

• Stripe Webhooks
• Stripe API: idempotent requests