Verifiera betalningar säkert

Även en äkta, signerad händelse måste kontrolleras mot Era förväntningar. Bekräfta att beloppet och valutan stämmer med vad beställningen skulle ha kostat.

Om en beställning på 9 USD rapporterar en betalning på 0,50 USD ska Ni avvisa den. Signaturen visar att meddelandet kommer från leverantören; beloppskontrollen visar att kunden betalade det som hen är skyldig.

Leverantörer levererar webhookar minst en gång, vilket innebär att dubbletter är normala. Om Er hanterare tilldelar krediter eller förlänger en prenumeration kan två behandlingar av samma händelse orsaka verklig skada.

Registrera varje händelse-ID som Ni har behandlat och hoppa över upprepningar. Gör hanteraren säker att köra hur många gånger som helst för samma händelse.

Verifiering innebär att leverantörens post jämförs med Er egen. Hämta det auktoritativa objektet — betalningsavsikten eller prenumerationen — och jämför dess status med vad Ni förväntar Er innan Ni agerar.

Genom att hämta objektet på nytt från leverantörens API inuti hanteraren minskar Ni gapet mellan en eventuellt inaktuell händelse och den aktuella verkligheten.

Leverantörer förväntar sig ett snabbt 2xx-svar, annars försöker de igen och orsakar dubbla leveranser. Bekräfta mottagandet omedelbart och utför sedan det tunga arbetet asynkront.

Mönstret är: verifiera signaturen, lägg händelsen i en kö och returnera 200. En bakgrundsprocess utför leveransen. Detta håller slutpunkten tillförlitlig under hög belastning och vid långsamma operationer.

API-nycklar, webhook-hemligheter och signeringsnycklar är autentiseringsuppgifter. Att hårdkoda dem i källkoden eller skicka dem till klienten är ett säkerhetsintrång som bara väntar på att inträffa.

Förvara dem i miljövariabler eller en secrets manager. Den hemliga nyckeln får endast finnas på servern; klienten får den publicerbara nyckeln, som det är säkert att exponera.

Pengar kan också flöda tillbaka. En återbetalning eller en kortreklamation bör återkalla åtkomst eller justera åtkomsterna, styrt av webhookhändelser som charge.refunded och charge.dispute.created.

Om Ni bara hanterar betalningen och ignorerar återföringen kan en kund som fått pengarna tillbaka fortsätta använda betalda funktioner gratis. Koppla in de bakåtriktade händelserna lika noggrant som de framåtriktade.

När pengar är inblandade behöver Ni ett oföränderligt spår. Logga varje mottagen webhook, varje leveransbeslut och varje ändring av åtkomster med tidsstämplar och ID:n.

Denna granskningslogg är Ert försvar vid en tvist och Ert snabbaste felsökningsverktyg när en kund säger "Jag betalade men har ingen åtkomst". Logga aldrig rå kortdata, utan endast referenser.

När verifieringen misslyckas — felaktig signatur, avvikande belopp eller okänd beställning — är det säkra standardvalet att neka åtkomst och meddela Er själva, inte att fria hellre än fälla.

Ett betalningssystem ska misslyckas stängt. Ett falskt negativt resultat irriterar en kund som Ni kan hjälpa manuellt; ett falskt positivt resultat ger bort produkten eller möjliggör bedrägeri.

Bekräfta följande kedja innan Ni går live: signaturen är verifierad, belopp och valuta stämmer, händelsen har behandlats idempotent, leverantörsobjektet har stämts av, hemligheter finns i miljövariabler, återbetalningar hanteras och fel leder till stängd åtkomst.

Be Er AI-assistent granska integrationen mot denna lista. Varje punkt som saknas är en dörr som en angripare eller ett fel kan ta sig igenom.

Säker verifiering innebär att endast lita på leverantörens signerade signaler från serversidan. Verifiera signaturen för varje webhook, kontrollera sedan belopp och valuta, behandla händelser idempotent och stäm av mot det aktuella leverantörsobjektet innan Ni beviljar åtkomst.

Förvara hemligheter i miljövariabler, svara snabbt och behandla asynkront, hantera återbetalningar och tvister genom att återkalla åtkomst, logga ett granskningsspår och misslyckas alltid stängt. Kör hela checklistan innan Ni går live.