IOSOR Ghiduri

Când CLI este blocat, fallback-ul trebuie să fie corect

Aflați cum să gestionați corect identificarea apelantului blocată în verificarea prin flash-call. Evitați stările false de Verify OK și rutați corect către fallback-ul SMS OTP.

Blocarea CLI de către operatori compromite verificarea. Marcarea apelului ca reuşit alterează balanţa. IOSOR aplică un fallback corect prin API.

Mecanismul de blocare a CLI în verificarea prin Flash

Verificarea prin flash-call se bazează pe introducerea de către utilizatorul final a ultimelor cifre ale unui număr CLI E.164 primit. Atunci când operatorii locali sau filtrele de spam de la nivelul sistemului de operare blochează acest CLI, apelul nu sună niciodată sau CLI este complet mascat. Într-un mediu CPaaS white-label operat de IOSOR, tratarea unui apel blocat ca fiind o livrare reușită este o eroare critică de arhitectură. Trebuie să detectăm imediat livrarea eșuată, fără a ghici sau a presupune succesul.

De ce stările false de Verify OK vă distrug registrul financiar

Unele platforme maschează eșecurile de livrare pentru a umfla artificial ratele de succes, dar această practică vă distruge registrul financiar. Un CLI blocat nu este în niciun caz un 'Verify OK'. Dacă taxați clientul pentru o verificare reușită când, în realitate, nu a fost livrată nicio cifră, creați discrepanțe grave de facturare și pierdeți încrederea clienților. IOSOR impune o regulă strictă: o singură cale de debitare și un singur status. Dacă CLI este blocat, tranzacția este marcată ca eșuată, iar suma rezervată în avans este eliberată imediat.

Configurarea regulii cu o singură cale de debitare

Pentru a menține integritatea registrului, IOSOR folosește un model de alocare JIT (Just-In-Time) pentru resursele de rutare. Când începe o verificare, plasăm o rezervare temporară pe soldul preplătit al clientului. Dacă CLI este blocat, rezervarea este eliberată imediat, iar sistemul se pregătește pentru fallback. Acest lucru previne dubla facturare și asigură o transparență financiară deplină. Prin automatizarea acestui proces, minimizăm riscul erorilor manuale și ne asigurăm că fiecare tranzacție este înregistrată corect în timp real.

Gestionarea webhook-urilor în timp real pentru apelurile blocate

Atunci când un operator blochează un CLI, platforma primește un cod specific de deconectare din rețea. IOSOR traduce acest lucru într-un webhook în timp real trimis direct către aplicația dumneavoastră. Sistemul dumneavoastră trebuie să asculte acest webhook și să oprească imediat mașina de stări a apelului flash. Nu așteptați un timeout. Datele webhook-ului conțin destinația E.164, motivul eșecului și starea exactă, asigurându-vă că nu trimiteți niciodată o stare falsă de 'Verify OK' în baza de date.

Integrarea ghidurilor de fallback corecte

Odată ce blocarea este confirmată, declanșați imediat rutarea de fallback. Trecerea la SMS OTP se asigură că utilizatorul își primește codul fără întârziere. Pentru strategii detaliate de rutare, consultați ghidurile noastre:

Începeți cu IOSOR

Pentru a gestiona eficient evenimentele de CLI blocat, configurați endpoint-urile webhook în Consola IOSOR pentru a capta codurile de deconectare în timp real. Asigurați-vă că setările de alocare JIT sunt active pentru a elibera imediat reținerea preplătită la detectarea unui blocaj de operator. Acest lucru permite aplicației să declanșeze poarta de rezervă fără a aștepta un timeout manual.

Rezumat IOSOR

Acest articol demonstrează că un CLI blocat trebuie tratat ca o eroare de livrare pentru a menține integritatea facturării și încrederea utilizatorilor. Mascarea acestor eșecuri ca succese duce la discrepanțe în registru și împiedică tranziția necesară către SMS OTP, esențială pentru conversie.

Prioritizați răspunsurile webhook în timp real pentru a iniția imediat rutele alternative.

A fost util acest ghid?

Ghiduri conexe