IOSOR

IOSOR Kunskap

Webhook-kontrakt före den första sändningen

Köparspår: kom överens om signerad URL, händelsetyper och idempotensnyckel före den första förbetalda sändningen — kontrakt först, betald trafik sedan.

En förbetald sändning utan ett webhook-kontrakt är utgift utan gemensam sanning. Köpare måste låsa den signerade URL:en, händelselistan och idempotensnyckeln innan det första betalda meddelandet lämnar plånboken — inte efter att finansavdelningen frågar varför status och huvudbok inte matchar. Denna sida är det köparspåret, inte en checklista för nycklar vid lansering och inte en djupdykning i signaturer.

Kom överens om kontraktet före första betalda sändning

Betald sändning innebär att plånboken kan debitera. Kontrakt innebär att produkt, finans och drift redan delar var callbacks landar, vilka händelser som räknas som pengar eller statussanning, och vilken nyckel som gör omsändningar säkra. Lanseringsvanor och bana kan se gröna ut medan kontraktet fortfarande är en Slack-tråd — det är inte redo.

Signerad URL och konsumentägande

Kontraktsfält Varför köpare bryr sig
HTTPS-callback-URL En destination produkt och drift kan namnge
Ägare av signeringshemlighet Vem som roterar; aldrig en delad chattklistring
ACK vs process-regel Persistera först; sidorörelser efter ACK
Miljödelning Pilot-URL ≠ produktions-URL
Stäng vid okänd värd Förfalskad levererad uppdaterar aldrig huvudboken

Händelsetyper som produkt och finans delar

Lista händelser som kan flytta pengar eller status före första sändningen: accepterad, levererad, misslyckad, utgången, inkommande STOP och eventuellt verifieringsresultat du behandlar som sanning. Olistade händelser stängs ned — de uppfinner inga huvudboksrader. Delade ord: Gemensamt statusspråk för produkt och finans.

Idempotensnyckel före utgift

Idempotensnyckeln förhindrar dubbeldebitering vid nätverksavbrott. Utan denna nyckel kommer varje försök att skicka samma meddelande att debitera din plånbok flera gånger. Se till att denna nyckel genereras på klientsidan och verifieras av servern före den första sändningen. Låt inte ditt system gissa om ett meddelande har skickats.

Köparchecklista för webhook-kontraktet

Verifiera din HTTPS-callback-URL. Håll signeringshemligheten säker och dela den aldrig i chatt. Bekräfta att alla finansiella händelser finns med i kontraktet. Testa "fail closed" med en okänd värd för att säkerställa att din huvudbok förblir korrekt. Se till att alla intressenter är överens om händelseformatet.

Börja med IOSOR

Gå in i IOSOR-konsolen och registrera er signerade HTTPS-återuppringningsadress samt det angivna fältet för idempotensnyckel innan betalda meddelandeutskick aktiveras. Säkerställ att teamledarna för produkt, finans och teknik granskar det delade händelseschemat – såsom levererat, misslyckat och utånget – för att bekräfta att ej listade återuppringningar automatiskt misslyckas stängt. Kör ett test med dubbletthändelsenyttolast utan kostnad genom er webhook-port för att verifiera att omsändningar registreras mot en enda reskontrarad innan trafikspärrar släpps.

IOSOR sammanfattning

Ett webhook-kontrakt är inte en informell anpassning; det är en uttrycklig gräns som skyddar finans och produkt från dubbeldragningar och spökstatusuppdateringar. Att fastställa ägarskap för signeringshemlighet, exakt adressägarskap och strikt tolkning av idempotensnyckel före den första betalda leveransen förhindrar att omsändningsstormar hittar på reskontraposter.

Lås fast er händelselista för återuppringning och tillämpa en arkitektur med bekräftelse före biverkningar för alla inkommande återuppringningar. Starta inte livestruket produktionstrafik med syntetiska nycklar härledda från tidsstämplar eller kroppshashar, och lita aldrig på muntliga överenskommelser om händelsestatusdefinitioner.

Var den här guiden till hjälp?

Relaterade guider