Bekreft betalinger på en sikker måte

Selv en ekte, signert hendelse må kontrolleres mot forventningene Deres. Bekreft at beløpet og valutaen samsvarer med det ordren skulle koste.

Hvis en ordre på $9 rapporterer en betaling på $0.50, må den avvises. Signaturen beviser at meldingen kommer fra leverandøren; kontroll av beløpet beviser at kunden betalte det vedkommende skylder.

Leverandører leverer webhooker minst én gang, noe som betyr at duplikater er normalt. Hvis håndteringen Deres gir kreditter eller forlenger et abonnement, kan behandling av samme hendelse to ganger føre til reell skade.

Registrer hver hendelses-ID De har behandlet, og hopp over gjentakelser. Gjør håndteringen trygg å kjøre et hvilket som helst antall ganger for den samme hendelsen.

Bekreftelse betyr å sammenligne leverandørens oppføring med Deres egen. Hent det autoritative objektet — betalingsintensjonen eller abonnementet — og sammenlign statusen med det De forventer, før De utfører en handling.

Hvis De henter data på nytt fra leverandørens API inne i håndteringen, lukker De gapet mellom en mulig foreldet hendelse og den gjeldende virkeligheten.

Leverandører forventer et raskt 2xx-svar, ellers prøver de på nytt og skaper dupliserte leveranser. Bekreft mottaket raskt, og utfør deretter tungt arbeid asynkront.

Mønsteret er: bekreft signaturen, legg hendelsen i en kø, og returner 200. En bakgrunnsarbeider utfører oppfyllelsen. Dette holder endepunktet pålitelig under belastning og ved langsomme operasjoner.

API-nøkler, webhook-hemmeligheter og signeringsnøkler er legitimasjon. Hvis De hardkoder dem i kildekoden eller sender dem til klienten, ligger et sikkerhetsbrudd og venter på å skje.

Oppbevar dem i miljøvariabler eller en hemmelighetstjeneste. Den hemmelige nøkkelen må bare finnes på serveren Deres; klienten får den publiserbare nøkkelen, som det er trygt å eksponere.

Penger kan også bevege seg bakover. En tilbakebetaling eller en kortreklamasjon bør tilbakekalle tilgang eller justere tilganger, utløst av webhook-hendelser som charge.refunded og charge.dispute.created.

Hvis De bare håndterer betalingen og ignorerer reverseringen, beholder en kunde som har fått tilbakebetaling betalte funksjoner gratis. Koble de bakoverrettede hendelsene til systemet med samme grundighet som de fremoverrettede.

Når penger er involvert, trenger De et uforanderlig spor. Logg hver mottatte webhook, hver beslutning om oppfyllelse og hver endring i tilganger, med tidsstempler og ID-er.

Dette revisjonsloggen er Deres forsvar i en tvist og det raskeste feilsøkingsverktøyet når en kunde sier «Jeg betalte, men har ingen tilgang». Logg aldri rå kortdata, bare referanser.

Når bekreftelsen mislykkes — feil signatur, avvikende beløp eller ukjent ordre — er det trygge standardvalget å nekte tilgang og varsle Dem selv, ikke å gi tvilen tiltalte.

Et betalingssystem bør feile lukket. Et falskt negativt resultat plager én kunde som De kan hjelpe manuelt; et falskt positivt resultat gir bort produktet eller inviterer til svindel.

Bekreft kjeden før De går live: signaturen er bekreftet, beløp og valuta samsvarer, hendelsen er behandlet idempotent, leverandørobjektet er avstemt, hemmeligheter ligger i miljøvariabler, tilbakebetalinger håndteres, og feil fører til at systemet feiler lukket.

Be AI-assistenten Deres om å revidere integrasjonen mot denne listen. Hvert manglende punkt er en dør en angriper eller en feil kan gå gjennom.

Trygg bekreftelse innebærer å stole bare på leverandørens signerte signaler fra serversiden. Bekreft signaturen til hver webhook, kontroller deretter beløp og valuta, behandle hendelser idempotent, og avstem mot det gjeldende leverandørobjektet før De gir tilgang.

Oppbevar hemmeligheter i miljøvariabler, svar raskt og behandle asynkront, håndter tilbakebetalinger og tvister ved å tilbakekalle tilgang, logg et revisjonsspor, og la systemet alltid feile lukket. Kjør hele sjekklisten før De går live.