Neteisingas MSISDN neturi nurašyti lėšų

Neteisingas MSISDN neturi nurašyti lėšų.

Įėjimo patikra prieš vėlesnius maršruto gedimus

Valdant didelį SMS ar OTP srauto kiekį, labai svarbu atskirti neteisingą paskirties adresą įėjimo taške (ingress) nuo vėlesnio pristatymo gedimo (downstream). Neteisingas MSISDN turi būti atmestas iškart API vartuose, prieš atliekant bet kokią operaciją didžiojoje knygoje. Jei neteisingas numeris apeina įėjimo patikras, jis gali sugeneruoti vėlesnį DLR su nežinoma būsena, o tai atrodo kaip išlaidos, nors pristatymas neįvyksta. IOSOR taiko griežtas tikrinimo taisykles, kad išvengtų šios problemos ir užtikrintų, jog jūsų balansas būtų apsaugotas nuo neteisingų paskirties formatų.

E.164 analizavimo variklis

Kiekviena API užklausa, nukreipta į mobiliojo telefono numerį, yra analizuojama realiuoju laiku pagal pasaulinį E.164 standartą. Platforma tikrina šalies kodą, nacionalinį paskirties kodą ir abonento numerio ilgį. Jei formatas neteisingas, vartai nedelsdami grąžina HTTP 400 Bad Request klaidą. Šis greitas tikrinimas užtikrina, kad neegzistuojantys maršrutai būtų blokuojami prieš skiriant išteklius ar pritaikant išankstinio mokėjimo rezervavimą. Šis mechanizmas neleidžia neteisingiems numeriams inicijuoti užklausų operatoriams, kurios sukelia paslėptų išlaidų.

Didžiosios knygos taisyklės ir išankstinio mokėjimo rezervavimas

Siekdama išlaikyti tikslų balansą, IOSOR naudoja realiojo laiko didžiąją knygą. Kai priimama galiojanti SMS užklausa, jūsų balanse pritaikomas laikinas išankstinio mokėjimo rezervas. Jei pranešimas sėkmingai nukreipiamas, rezervas paverčiamas debetu. Tačiau jei numeris įėjimo taške pažymimas kaip neteisingas, rezervas nekuriamas ir iš jūsų balanso nurašoma nulis lėšų. Tai apsaugo jūsų USD 20 išankstinio mokėjimo ribą nuo praradimo dėl neteisingų adresų. Paskyroms, kurios plečia veiklą, švelnus peržiūrėjimas pasiekus USD 1,000 per mėnesį padeda optimizuoti maršruto lenteles ir koreguoti MRC limitus skirtiems ištekliams.

Webhook duomenys ir klaidų kodai

Kai pranešimas atmetamas įėjimo taške, API atsakyme pateikiama informacija apie klaidą. Užuot laukusi asinchroninio DLR webhook pranešimo, jūsų programa iškart gauna sinchroninę klaidą. Šiame atsakyme nurodomas neteisingas parametras ir aiškus atmetimo kodas. Galiojantiems numeriams sistema priskirs maršrutą ir siųs būsenos atnaujinimus per webhook, įskaitant STOP ir Verify OK įvykius, užtikrindama visišką jūsų pranešimų srauto skaidrumą be nereikalingo API ciklų švaistymo.

Kūrėjų ištekliai ir integracija

Norėdami sukurti patikimą integraciją ir išvengti nereikalingų išlaidų, kūrėjai turėtų įdiegti kliento pusės patikrą prieš kreipdamiesi į API. Peržiūrėkite šiuos svarbius vadovus, kad optimizuotumėte savo integraciją:

• E.164 telefono formato tikrinimas API įėjimo taškuose
• Piniginės bandomoji savaitė: rezervai ir debetai gyvame sraute
• SMS API pirkimo sąrašas

Pradėkite su IOSOR

Iš smėliadėžės POST-inkite paskirtį be šalies kodo ir vieną neįmanomo ilgio. Laukite HTTP 400 ir neliesto ledger — nei hold, nei nurašymo. Tada siųskite galiojantį E.164 ir patvirtinkite, kad hold atsiranda tik po accept. Jei pinigai pajudėjo ant netinkamos poros, įėjimo skaidymas sulūžęs.

IOSOR santrauka

Formato atmetimas prie įėjimo nėra pristatymo gedimas. Netinkamas MSISDN niekada neturi atidaryti hold. Darykite: skaidykite E.164 prieš pinigams judant. Nedarykite: laukti unknown DLR, kuris paaiškintų nurašymą, kurio neturėtų būti. Ledger tyli, kol numeris gerai sudėtas.