IOSOR

IOSOR Guide

DLR, latenza e failover: una sola verità per prodotto e finanza

Unificate DLR, bande di latenza per corridoio e failover con onestà prepaid, così prodotto, ops e finance smettono di litigare sullo stesso webhook.

Il prodotto vuole conversione. La finance vuole addebiti prevedibili. Le ops vogliono una parola di stato che significhi la stessa cosa in cruscotto, webhook e fattura. Quando DLR, latenza e failover vivono in tre silos, ogni incidente diventa una lite di vocabolario — e il prepaid brucia mentre i team discutono.

IOSOR gestisce messaggistica prepaid white-label con un solo dizionario di stati tra canali: errori sicuri per il cliente, senza nomi di marchi altrui. Il catalogo promette una capacità solo quando è live; in setup non è live. Intorno a USD 1.000+ di uso mensile, gli export di stato terminale, le bande di latenza e l'addebito di ogni failover diventano materiale di revisione commerciale. Prima le prove, poi la scala.

Una tabella di verità per la direzione

Livello Domanda prodotto Domanda finance Artefatto condiviso
DLR L'utente l'ha ricevuto? La consegna è fatturabile? Stato terminale + marca temporale
Latency Dentro lo SLA? N/A salvo che i retry moltiplichino l'addebito p95/p99 per corridoio
Failover Quale percorso ha vinto? Quanti tentativi addebitati? Registro tentativi + ID di correlazione

Integrazione DLR che supera gli audit

  • Eventi inbound firmati o autenticati
  • Consumatori idempotenti con chiavi di deduplica
  • Correlazione invio → stato → libro mastro
  • Ispezione delle consegne recenti nel prodotto

Un webhook non firmato e un consumatore non idempotente trasformano i retry in ticket duplicati e addebiti duplicati. Vedi guida operativa alla deliverability SMS e non consegnato, rifiutato, scaduto. Catalogo live senza correlazione DLR–libro è una promessa che la finance non può difendere.

Bande di latenza, non medie di vanità

Tracciate accepted → submitted → delivered per corridoio. La conversione OTP ha forma geografica; una media mondiale nasconde un mercato rotto. Quando la latenza decade, decidete retry vs failover vs stop con responsabili nominati — non con la speranza. Tagliate p95/p99 nel report settimanale.

Failover con disciplina prepaid

Il failover salva gli utenti — o brucia i portafogli:

  1. Tetto di tentativi automatici per messaggio.
  2. Separate il reinvio utente dal failover di sistema.
  3. Mai failover verso voci di catalogo in setup.
  4. Documentate le regole di addebito per tentativo.

Le route mock in una catena di failover di produzione non sono una rete di sicurezza. Abbina il fallback voce/SMS a alert vocali e fallback OTP. Prodotto e finance devono esportare tutti i tentativi di un messaggio e allineare gli ID di correlazione. live è l'unica destinazione legittima; in setup non copre un OTP di produzione.

Segnali d'allarme

  • Delivered e sent usati come sinonimi nell'interfaccia
  • Tentativi di failover invisibili alla finance
  • Route mock nelle catene di failover di produzione
  • Parole di stato diverse tra webhook e fattura
  • Solo catture di schermo come prova
  • Failover promesso mentre il catalogo è in setup
  • Nomi di marchi altrui negli errori visibili al cliente

Iniziare con IOSOR

Scegliete un corridoio e un tipo di messaggio. Esportate i DLR terminali della scorsa settimana in un dizionario condiviso prodotto–finanza e fate passare lo stesso correlation ID da staging, failover e addebito wallet. Simulate un cambio di percorso e confrontate ciò che ha visto l’utente con ciò che ha addebitato il ledger. Correggete ogni etichetta Delivered se finance tiene ancora un retry o un addebito di failover.

Sintesi IOSOR

Prodotto e finanza devono leggere un DLR, un orologio di latenza e un esito di failover sullo stesso correlation ID.

Questa guida ti è stata utile?

Guide correlate