IOSOR Guide
Un webhook duplicato non deve creare un secondo addebito
Percorso di errore: tentativi e replay rimangono idempotenti sul saldo prepaid e sulla inbox — un ID evento, una riga di addebito, una riga inbox.
La consegna almeno una volta effettuerà nuovi tentativi. Un webhook duplicato che pubblica un secondo addebito o una seconda riga inbox è un incidente di denaro e operazioni, non un «ack inoffensivo». Questa pagina è il percorso di errore: tentativi e replay rimangono idempotenti sul saldo prepaid e sulla inbox — non il saggio sull'idempotenza dell'invio API e non il playbook di ripetizione SMS in entrata.
Correlato: Gate di firma e finestra di replay, Contratto webhook prima del primo invio, righe di addebito e stato di consegna sullo stesso ledger.
IOSOR è prepaid white-label.
L'idempotenza è un percorso di errore, non uno slogan
Percorso felice: un evento firmato, un accettato, un addebito. Il percorso di errore brucia la fiducia — timeout, 5xx, replay del provider, re-push dell'operatore. Memorizza la chiave di idempotenza dal Contratto webhook prima del primo invio prima degli effetti collaterali: ledger, inbox, CRM.
Cosa conta come duplicato
| Segnale | Trattare come duplicato quando | Risultato sicuro |
|---|---|---|
| ID evento | Stesso ID già accettato nella finestra | ACK; nessun secondo addebito |
| ID messaggio | Stesso messaggio già collegato al ledger | Riutilizza riga; nessun nuovo addebito |
| Chiave inbox | Stesso MO/MT già archiviato | Nessuna seconda riga inbox |
| Fuori finestra | Tentativo obsoleto dopo rifiuto gate | Rifiuta; nessuna scrittura denaro/stato |
| Tipo sconosciuto | Fuori dalla lista |
Il denaro non deve muoversi due volte
Un secondo addebito per lo stesso ID evento è un bug anche se il prodotto «mostra ancora consegnato». La finanza filtra per evento o ID messaggio e vede una riga prepaid per quella finestra UTC. Effetti collaterali parziali dopo l'ACK — CRM prima, ledger dopo — fabbricano una doppia verità. Se l'elaborazione fallisce dopo la persistenza, riprova il worker sulla stessa chiave; non riaccettare il corpo HTTP come nuovo addebito.
Anche la inbox non deve raddoppiare
L'idempotenza non riguarda solo il denaro. Un evento in entrata o di consegna ripetuto che apre un secondo thread inbox addestra il supporto a inseguire fantasmi e può innescare cicli di risposta automatica. Memorizza la chiave inbox con lo stesso ID evento usato per l'addebito. Prodotto e finanza condividono rifiuto e duplicazione.
Checklist per l'acquirente per webhook a prova di duplicato
Esigi che il tuo fornitore confermi la memorizzazione della chiave di idempotenza prima dell'effetto collaterale. Verifica che i guasti di rete non generino un secondo addebito nella stessa finestra UTC. Esigi che i tentativi restituiscano lo stesso ACK memorizzato senza toccare il saldo. Testa con USD 20 prima di passare a volumi maggiori.
Inizia con IOSOR
Forzate un replay firmato dentro la finestra su un corridoio già addebitato. Esportate l’event id accanto all’id del ledger e provate una sola riga di addebito e una sola riga inbox. Se compare un secondo addebito, fermate quel consumatore e rimborsate la riga in più — non compensatela col traffico successivo. Questo cancelletto è denaro di replay, non un controllo E.164 né un testo di spedizione.
Sintesi IOSOR
Un replay non è un invio nuovo. Un event id scrive un addebito.
Fate: tenete firma e finestra di replay, poi provate un addebito dopo un POST in finestra. Non fate: addebitare ogni POST, né trattare un retry di rete come seconda fattura.
Questa guida ti è stata utile?
Guide correlate
- Monitoraggio delle metriche di salute degli endpoint Webhook
Impara a tracciare la latenza di risposta del ricevitore e i codici di stato all'interno della piattaforma IOSOR per gestire proattivamente la salute dei webhook.
- Configurazione degli avvisi Webhook per le soglie di saldo prepagato
Scopri come configurare webhook automatici per le soglie di saldo in IOSOR per monitorare gli account prepagati, prevenire interruzioni e gestire il provisioning JIT.
- Elaborazione degli eventi webhook di provisioning Just-in-Time
Padroneggia il ciclo di vita in tempo reale dei canali in entrata utilizzando i webhook di provisioning JIT di IOSOR. Automatizza l'assegnazione dei numeri e gli aggiornamenti del ledger per il tuo CPaaS white-label.