IOSOR Kunnskap
Dupliserte webhooks må ikke opprette en andre debitering
Feilsti: Nytt forsøk og avspillinger forblir idempotente på forhåndsbetalte midler og innboks — én hendelses-ID, én debetlinje, én innbokslinje.
At-least-once-levering vil gjøre nye forsøk. Et duplisert webhook som poster en andre debitering eller en andre innbokslinje, er en penge- og driftsincident, ikke en «ufarlig ack». Denne side er feilstien: nye forsøk og avspillinger forblir idempotente på forhåndsbetalte midler og innboks — ikke essayet om API-sending-idempotens og ikke playbooken for innkommende SMS-forsøk.
Relatert: Signatur- og replayvindu-port, Webhook-kontrakt før den første utsendelsen, Debetlinjer vs leveringsstatus på samme ledger.
IOSOR er white-label forhåndsbetalt.
Idempotens er en feilsti, ikke et slagord
Suksesssti: én signert hendelse, én aksept, én debitering. Feilstien brenner tillit — tidsavbrudd, 5xx, leverandøravspilling, operatør-repush. Lagre idempotensnøkkelen fra Webhook-kontrakt før den første utsendelsen før sideeffekter: ledger, innboks, CRM.
Hva som teller som en duplikat
| Signal | Behandle som duplikat når | Sikker utfall |
|---|---|---|
| Hendelses-ID | Samme ID allerede akseptert i vinduet | ACK; ingen andre debitering |
| Melding-ID | Samme melding allerede ledger-koblet | Gjenbruk rad; ingen ny belastning |
| Innboksnøkkel | Samme MO/MT allerede arkivert | Ingen andre innbokslinje |
| Utenfor replayvindu | Gammelt forsøk etter port-avvisning | Avvis; skriv ingenting |
Penger må ikke flytte seg to ganger
En andre debitering for den samme hendelses-ID-en er en feil selv om produktet «fortsatt viser levert». Finans filtrerer etter hendelses- eller melding-ID og ser én forhåndsbetalt rad for det UTC-vinduet. Delvise sideeffekter etter ACK — CRM først, ledger senere — produserer dobbel sannhet.
Innboksen må heller ikke doble seg
Idempotens handler ikke bare om penger. En avspilt innkommende eller leveringshendelse som åpner en andre innbokstråd, trener støtten til å jage spøkelser og kan utløse automatiske svar-løkker. Lagre innboksnøkkelen med samme hendelses-ID som brukes for debitering. Produkt og finans deler avvisning/duplikat.
Kjøpers sjekkliste for duplikat-sikre webhooks
Forsikre deg om at idempotensnøkkelen lagres før eventuelle CRM- eller databasehandlinger. Bekreft at et HTTP 200-svar sendes for et anerkjent duplikat uten å utløse en ekstra ledger-debitering. Sikre at avspillingsvinduet håndheves ved signaturporten før noe forretningslogikk kjører. Test systemet ditt regelmessig med duplikat-belastningsinsekter.
Start med IOSOR
Tving én signert replay inne i vinduet på en korridor som allerede har debitert. Eksporter event-id ved siden av ledger-id og bevis én debitrad pluss én innboksrad. Dukker en andre debit opp, stopp den konsumenten og refunder ekstraraden — net den ikke mot senere trafikk. Denne porten er replay-penger, ikke en E.164-sjekk og ikke forsendelsestekst.
IOSOR takeaway
En replay er ikke en ny sending. Ett event-id skriver én debit.
Gjør: hold signatur og replay-vindu på, bevis så én debit etter en POST i vinduet. Ikke: debitere hver POST, eller behandle et nettverksretry som en andre faktura.
Var denne guiden nyttig?
Relaterte veiledninger
- Overvåking av helsemetrikker for webhook-endepunkter
Lær hvordan du sporer responstid og statuskoder for mottakere i IOSOR-plattformen for å proaktivt styre webhook-helse og forhindre feil i callbacks.
- Konfigurere webhook-varsler for terskelverdier i forhåndsbetalte lommebøker
Lær hvordan du konfigurerer automatiserte saldo-terskel-webhooks i IOSOR for å overvåke forhåndsbetalte kontoer, forhindre tjenesteavbrudd og administrere JIT-nummerprovisionering effektivt.
- Behandling av Just-in-Time Provisioning Webhook-hendelser
Mestre livssyklusen for innkommende kanaler i sanntid ved hjelp av IOSOR JIT-provisionerings-webhooks. Automatiser tildeling av numre og oppdateringer av hovedboken for din white-label CPaaS.