Bekræft betalinger sikkert

Selv en ægte, signeret hændelse skal kontrolleres mod dine forventninger. Bekræft, at beløbet og valutaen svarer til det, ordren burde have kostet.

Hvis en ordre på 9 $ rapporterer en betaling på 0,50 $, skal du afvise den. Signaturen beviser, at beskeden kommer fra udbyderen; kontrol af beløbet beviser, at kunden har betalt det, vedkommende skylder.

Udbydere leverer webhooks mindst én gang, hvilket betyder, at dubletter er normale. Hvis din handler tildeler kreditter eller forlænger et abonnement, kan behandling af den samme hændelse to gange gøre reel skade.

Gem ID'et for hver hændelse, du har behandlet, og spring gentagelser over. Gør din handler sikker at køre et vilkårligt antal gange for den samme hændelse.

Bekræftelse betyder, at du sammenholder udbyderens post med din egen. Hent det autoritative objekt — betalingsintentionen eller abonnementet — og sammenlign dets status med det, du forventer, før du handler.

Hvis du henter oplysningerne igen fra udbyderens API i handleren, lukker du forskellen mellem en muligvis forældet hændelse og den aktuelle virkelighed.

Udbydere forventer et hurtigt 2xx-svar, ellers prøver de igen, hvilket skaber dubletter. Kvitter hurtigt for modtagelsen, og udfør derefter det tunge arbejde asynkront.

Mønstret er: Bekræft signaturen, læg hændelsen i kø, og returnér 200. En baggrundsarbejder udfører leveringen af produktet. Det holder slutpunktet pålideligt under belastning og ved langsomme operationer.

API-nøgler, webhook-hemmeligheder og signeringsnøgler er legitimationsoplysninger. Hvis du hardcoder dem i kildekoden eller sender dem til klienten, er det et sikkerhedsbrud, der bare venter på at ske.

Gem dem i miljøvariabler eller en hemmelighedshåndteringstjeneste. Den hemmelige nøgle må kun ligge på din server; klienten får den offentlige nøgle, som det er sikkert at eksponere.

Penge kan også bevæge sig tilbage. En tilbagebetaling eller en tvist om en kortopkrævning bør tilbagekalde adgang eller justere adgangsrettighederne, udløst af webhook-hændelser som charge.refunded og charge.dispute.created.

Hvis du kun håndterer betalingen og ignorerer tilbageførslen, beholder en kunde, der har fået pengene tilbage, betalingsfunktionerne gratis. Forbind de bagudrettede hændelser lige så omhyggeligt som de fremadrettede.

Når penge er involveret, har du brug for et uforanderligt spor. Log hver modtaget webhook, hver beslutning om levering af produktet og hver ændring af adgangsrettigheder med tidsstempler og ID'er.

Denne revisionslog er dit forsvar i en tvist og dit hurtigste fejlfindingsværktøj, når en kunde siger "Jeg har betalt, men har ingen adgang". Log aldrig rå kortdata, kun referencer.

Når en bekræftelse mislykkes — forkert signatur, uoverensstemmende beløb eller ukendt ordre — er den sikre standard at nægte adgang og gøre dig selv opmærksom på problemet, ikke at give nogen fordelen af tvivlen.

Et betalingssystem bør fejle lukket. Et falsk negativt resultat irriterer én kunde, som du kan hjælpe manuelt; et falsk positivt resultat giver dit produkt væk eller inviterer til svindel.

Bekræft kæden, før du går live: Signatur bekræftet, beløb og valuta stemmer, hændelse behandlet idempotent, udbyderens objekt afstemt, hemmeligheder i miljøvariabler, tilbagebetalinger håndteret, og fejl håndteres som lukket adgang.

Bed din AI-assistent om at gennemgå integrationen ud fra denne liste. Hvert manglende punkt er en dør, som en angriber eller en fejl kan gå igennem.

Sikker bekræftelse betyder, at du kun stoler på udbyderens signerede signaler fra serversiden. Bekræft signaturen på hver webhook, kontrollér derefter beløb og valuta, behandl hændelser idempotent, og afstem mod det aktuelle objekt hos udbyderen, før du giver adgang.

Opbevar hemmeligheder i miljøvariabler, svar hurtigt og behandl asynkront, håndtér tilbagebetalinger og tvister ved at tilbagekalde adgang, log et revisionsspor, og sørg altid for, at fejl lukker for adgangen. Kør hele tjeklisten, før du går live.