IOSOR Ghiduri
Eliberarea reținerii preplătite după eșuarea atribuirii DID
Aflați cum gestionează IOSOR atribuirile DID eșuate prin eliberarea instantanee a reținerilor preplătite pentru a preveni blocarea silențioasă a soldului.
Un assign DID eșuat trebuie să elibereze hold-ul preplătit ca portofelul să poată reîncerca.
Înțelegerea a provisionării numerelor JIT și a reținerilor preplătite
Când un chiriaș inițiază o cerere de achiziție de numere prin API, IOSOR evită menținerea stocului fizic. Numerele sunt furnizate prin interfețe JIT. Pentru a proteja împotriva condițiilor de concurență, platforma plasează o reținere temporară de autorizare pe portofelul activ. Dacă operațiunea reușește, această reținere se transformă într-o debitare MRC confirmată. Totuși, timpii de expirație ai rețelei sau respingerile operatorului pot întrerupe acest flux. O atribuire eșuată trebuie să elimine reținerea imediat pentru a menține lichiditatea.
Anatomia unui scenariu de eșec al atribuirii
Luați în considerare un sub-cont automatizat care achiziționează un DID E.164 pentru o campanie OTP. API-ul trimite datele de activare, declanșând verificarea soldului raportat la pragul de USD 20. Gateway-ul plasează reținerea, dar operatorul respinge atribuirea din cauza unei erori de rutare. Fără o gestionare strictă a stării, această rezervă ar putea persista, oprind traficul automatizat. IOSOR ascultă feedback-ul negativ DLR sau semnalele de timeout, asigurând anularea imediată a reținerii.
Bucla automată de rambursare și reconciliere
Când o tranzacție de activare eșuează, intervenția manuală nu este necesară. Motorul de reconciliere declanșează o secvență automată de eliberare. Acest mecanism funcționează similar proceselor din ghidul nostru Când un hold preplătit eșuează: auto-refund și adevărul statusului. Dacă apar complicații, operatorii pot consulta și eșec comandă DID rambursare și schimb. Această buclă automată garantează solduri precise fără tichete de suport.
Prevenirea blocajelor silențioase ale soldului în operațiuni de mare volum
Blocajele silențioase distrug încrederea chiriașilor, în special în campanii automate. Dacă fondurile sunt prinse de rețineri fantomă, sarcinile ulterioare se vor opri. Legând eliberările de rețineri direct de feedback-ul negativ HB și codurile de eroare ale gateway-ului, IOSOR protejează lichiditatea platformei. Chiriașii care operează aproape de pragul de USD 1.000 pe lună se bazează pe această transparență pentru a menține o comunicare neîntreruptă.
Comparația stărilor de reținere și a rezultatelor
| Stare | Acțiune întreprinsă | Impact asupra soldului | Timp de recuperare |
|---|---|---|---|
| Succes | Conversie în MRC | Redus cu tariful | Instantaneu |
| Timeout | Eliberare reținere | Restabilit complet | < 500 ms |
| Respingere | Renunțare la rezervă | Restabilit complet | Imediat |
| Eroare | Declanșare rambursare | Restabilit complet | Automat |
Începeți cu IOSOR
Dacă assign întoarce reject sau timeout, lăsați hold-ul de autorizare pe acel order id. Exportați hold-dropped și cauza eșecului pe același rând. O rezervă fantomă după un assign mort îngheață portofelul pentru următoarea încercare.
Rezumat IOSOR
Assign eșuat trebuie să elibereze hold-ul, altfel portofelul minte.
Faceți: eliberare automată la reject sau timeout. Nu faceți: păstra un ger tăcut după un assign mort.
A fost util acest ghid?
Ghiduri conexe
- Predarea DID către al doilea proprietar: cine poate atribui și elibera
Stăpâniți limitele operaționale, provizionarea JIT și pragurile financiare preplătite în timpul predărilor DID către al doilea proprietar.
- Limit de cheltuieli pe DID: Închiriere plus trafic MT pe un număr
Controlați expunerea per număr în CPaaS-ul dvs. white-label cu un plafon combinat de cheltuieli pentru MRC și traficul de terminare mobilă outbound.
- Rutarea webhook-urilor inbound pe DID: MO fără proprietar pierde STOP
Rutați webhook-urile inbound către contul proprietar în mod sigur. Preveniți evenimentele MO orfane și dezabonările ratate în CPaaS prepaid cu etichetă albă.