IOSOR Kunskap
En dubblett-webhook får inte skapa en andra debitering
Felflöde: försök igen och uppspelningar förblir idempotenta på förbetalda pengar och inkorg – ett händelse-ID, en debiterad rad, en inkorgsrad.
Leverans minst en gång kommer att göra nya försök. En dubblett-webhook som skickar en andra debitering eller en andra inkorgsrad är en incident gällande pengar och drift, inte en ofarlig bekräftelse. Denna sida är felflödet: försök och uppspelningar förblir idempotenta för förbetalda pengar och inkorg – inte uppsatsen om API-sändningens idempotens eller manualen för inkommande SMS-omförsök.
Relaterat: Signatur- och replayfönstergrind, Webhook-kontrakt före den första sändningen, Debitrader vs leveransstatus på samma ledger.
IOSOR är white-label förbetalt.
Idempotens är ett felflöde, inte en slogan
Lyckat flöde: en signerad händelse, ett accepterande, en debitering. Felflöde bränner förtroende – timeout, 5xx, leverantörens uppspelning, operatörens återtryck. Spara idempotensnyckeln från Webhook-kontrakt före den första sändningen innan sidodeffekter: ledger, inkorg, CRM.
Vad som räknas som en dubblett
| Signal | Behandla som dubblett när | Säkert utfall |
|---|---|---|
| Händelse-ID | Samma ID redan accepterat inom fönstret | Bekräfta; ingen andra debitering |
| Meddelande-ID | Samma meddelande redan kopplat till ledger | Återanvänd rad; ingen ny debitering |
| Inkorgsnyckel | Samma MO/MT redan arkiverad | Ingen andra inkorgsrad |
| Utanför replayfönster | Gammalt omförsök efter grindens avvisande |
Pengar får inte flyttas två gånger
En andra debitering för samma händelse-ID är en bugg även om produkten «fortfarande visar levererat». Finans filtrerar på händelse- eller meddelande-ID och ser en förbetald rad för det UTC-fönstret. Partiella sidodeffekter efter bekräftelse – CRM först, ledger senare – tillverkar dubbel sanning.
Inkorgen får inte heller dubbleras
Idempotens handlar inte bara om pengar. En uppspelad inkommande händelse eller leveranshändelse som öppnar en andra inkorgstråd tränar supporten att jaga spöken och kan utlösa automatiska svarsloopar. Spara inkorgsnyckeln med samma händelse-ID som används för debitering. Produkt och finans delar avvisande/dubblett.
Köparens checklista för dubblettsäkra webhooks
Se till att idempotensnyckeln sparas före eventuella CRM- eller databasåtgärder. Bekräfta att ett HTTP 200-svar skickas för en erkänd dubblett utan att utlösa en extra ledger-debitering. Säkerställ att uppspelningsfönstret upprätthålls vid signaturgrinden innan någon affärslogik körs. Testa ditt system regelbundet med dubblettbelastningsinjektioner.
Börja med IOSOR
Tvinga en signerad replay inuti fönstret på en korridor som redan debiterat. Exportera event-id bredvid ledger-id och bevisa en enda debetrad plus en enda inkorgsrad. Dyker en andra debit upp, stoppa den konsumenten och återbetala extraraden — netta den inte mot senare trafik. Den här grinden är replay-pengar, inte en E.164-kontroll och inte leveranstext.
IOSOR sammanfattning
En replay är inte en ny sändning. Ett event-id skriver en debit.
Gör: håll signatur och replay-fönster på, bevisa sedan en debit efter en POST i fönstret. Gör inte: debitera varje POST, eller behandla en nätverksretry som en andra faktura.
Var den här guiden till hjälp?
Relaterade guider
- Övervakning av hälsomått för webhook-slutpunkter
Lär dig hur du spårar svarstid och statuskoder för mottagare inom IOSOR-plattformen för att proaktivt hantera webhook-hälsa och förhindra callback-fel.
- Konfigurera webhook-varningar för tröskelvärden i plånboken
Lär dig hur du konfigurerar automatiska webhooks för saldotrösklar i IOSOR för att övervaka förbetalda konton, förhindra tjänsteavbrott och hantera JIT-nummerprovisionering effektivt.
- Bearbetning av webhook-händelser för Just-in-Time Provisioning
Bemästra realtidslivscykeln för inkommande kanaler med IOSOR JIT-provisioneringswebhooks. Automatisera nummer tilldelning och reskontrauppdateringar för din white-label CPaaS.