IOSOR Guide
Ordine degli eventi contro registrazione a ledger
Eventi DLR e MO fuori ordine non devono violare le regole di addebito prepagato: la sequenza di arrivo non è una legge monetaria.
Le reti recapitano i callback fuori ordine. Un DLR in ritardo, un MO precoce o un'inversione di stato prima del settlement non devono inventare un secondo addebito né riscrivere una riga già regolata. Questa pagina è il contratto sull'ordine di registrazione: le regole del ledger sopravvivono al riordinamento — non è una guida agli ID di correlazione né un saggio di fatturazione MO contro MT.
L'ordine di arrivo non è legge nel ledger
L'arrivo HTTP è un incidente di trasporto. Il denaro viene registrato secondo hold → settle → aggiornamento dell'esito, e non in base al callback arrivato per ultimo. Un valore flessibile di USD 1,000/month tratta il riordinamento come un incidente finanziario quando il prodotto mostra successo mentre il ledger si muove due volte. USD 20 dimostra che un DLR tardivo forzato non apre mai un addebito parallelo.
Come appare il disordine nella pratica
| Schema di arrivo | Registrazione sicura | Reazione non sicura |
|---|---|---|
| DLR prima del settlement | In sospeso; regola una volta sotto hold | Addebito basato solo sul DLR |
| Fallito poi consegnato | Aggiorna l'esito sul posto | Secondo addebito per l'inversione |
| MO prima della correlazione MT | Archivia in inbox; unisci al settlement MT | Addebita MO come traffico in uscita |
| Stato dopo rimborso | Nessun nuovo denaro; annota | Regola di nuovo l'intento rilasciato |
| Due terminali, un intento | Una riga di. |
Regole di registrazione che resistono al riordinamento
Genera chiavi di hold e di idempotenza prima degli effetti collaterali (Contratto webhook prima del primo invio). Regola una volta per intento fatturabile; gli eventi successivi aggiornano solo l'esito. Non aprire mai un addebito parallelo per DLR o MO precoci o tardi. Rifiuta o parcheggia ciò che si trova al di fuori della finestra firmata — nessun successo inventato. Esporta i collegamenti per intento, non per timestamp di arrivo.
La latenza è normale; il denaro doppio non lo è
Le reti mobili falliscono. Le code si accumulano durante le ore di minor traffico per poi svuotarsi all'improvviso. Quando gli eventi arrivano con ore di ritardo, il ledger non deve ricalcolare i saldi attivi con dati obsoleti. Valida sempre la finestra temporale prima di toccare il saldo.
Checklist per l'acquirente sull'ordine degli eventi
Esigi che il tuo fornitore dimostri che un DLR tardi non attivi un secondo costo. Verifica che la riconciliazione raggruppi per ID di intento e non per ora di arrivo sul server web. Assicurati che le chiavi di idempotenza blocchino i replay anche quando gli stati arrivano invertiti.
Inizia con IOSOR
In console: Event order vs ledger posting must reconcile by shared id.. Nominate owner e gate prima di scalare.
Correlati: duplicate webhook no second debit webhook consumer ops at volume.
Sintesi IOSOR
Disciplina ops di turno—non brochure.
Fate: name owner + gate. Non: skip the gate.
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.