IOSOR

IOSOR Znalosti

Selhání tichého ověření, poté jeden debet za OTP — ne dva

Zjistěte, jak IOSOR řeší selhání tichého ověření a přechází na SMS OTP bez dvojího účtování. Pochopte pravidla hlavní knihy, limity předplatného a nastavení webhooků.

Selhání tichého ověření, poté jeden debet za OTP — ne dva.

Mechanika záložního řešení při selhání tichého ověření

Při implementaci tichého mobilního ověření (silent auth) se primární cesta pokouší ověřit identitu uživatele přímo prostřednictvím hlaviček mobilní sítě. Tento proces tichého ověření je rychlý a bezproblémový, ale může selhat, pokud je uživatel na Wi-Fi nebo u nepodporovaného operátora. V takových případech IOSOR automaticky spustí záložní řešení (fallback) na standardní SMS OTP. Tím je zajištěno, že proces ověření pokračuje bez přerušení uživatelského zážitku.

Pravidla hlavní knihy pro neúspěšné tiché pokusy

Klíčovou provozní otázkou je, jak hlavní kniha (ledger) platformy tyto přechody zaznamenává. Pokud pokus o tiché ověření selže, nesmí generovat poplatek za úspěšné ověření. Hlavní kniha považuje pokus o tiché ověření a následnou SMS OTP za jedinou logickou transakci. Pokud tiché ověření selže, transakce zůstává otevřená. Teprve když je záložní SMS OTP úspěšně ověřena a platforma obdrží stav 'Verify OK', provede hlavní kniha jeden debet.

Zamezení dvojímu účtování při přechodu na SMS

Aby se zabránilo dvojímu účtování, rozhraní API platformy IOSOR sleduje token transakce napříč oběma kanály. Některé platformy chybně účtují poplatek za doručení tichého pokusu a další za SMS OTP. IOSOR se tomu vyhýbá použitím jednotné šablony ověření. Pokud tiché ověření selže, systém označí tichou fázi jako neúspěšnou, ale ponechá relaci aktivní. Při odeslání SMS OTP systém čeká na konečný stav doručení (DLR) a zadání uživatele, než provede zaúčtování.

Správa předplacených zůstatků a limitů

Všechny transakce na platformě se započítávají proti vašemu předplacenému zůstatku. IOSOR vyžaduje minimální předplacený zůstatek ve výši USD 20, aby vaše API zůstalo aktivní a předešlo se náhlým výpadkům služeb během kampaní s vysokým provozem. U účtů, které škálují svůj objem ověřování, se při dosažení přibližně USD 1,000/měsíc spouští mírné posouzení za účelem vyhodnocení vzorců používání, optimalizace směrování a úpravy limitů propustnosti.

Integrační odkazy a ověřování webhooků

Chcete-li nakonfigurovat záložní logiku a sledovat záznamy v hlavní knize, nahlédněte do našich podrobných průvodců. Změny stavu můžete sledovat v reálném čase přihlášením k odběru našich webhooků pro ověřování, které poskytují okamžité datové přenosy pro každou událost DLR a 'Verify OK'.

Začněte s IOSOR

Zkontrolujte datovou zátěž záložních transakcí v konzoli IOSOR v protokolech ověřovací relace. Zajistěte, aby vaše aplikace během předání SMS OTP opětovně použila jednotný transakční token namísto inicializace odpojené druhé relace. Pomocí webhookových událostí ověřte, že selhaná kontrola mobilní sítě se zaúčtuje jako nulový přechod předtím, než dojde k jedinému odečtení za SMS.

Shrnutí IOSOR

Přechod ze tiché mobilní verifikace na SMS OTP musí celou sekvenci považovat za jeden nepřerušitelný pokus. Propojení kontrol hlaviček mobilní sítě a doručení SMS s jednotným transakčním ID zajišťuje, že vaše účetní kniha zaznamená jedinou zpoplatnitelnou událost až po úspěšném odeslání kódu.

Opětovně použijte původní ID ověřovací relace při spuštění logiky záložní SMS. Nevytvářejte odpojená sekundární ověřovací volání API, která by neúspěšné tiché kontroly hodnotila jako samostatné zpoplatnitelné úkony.

Byl tento průvodce užitečný?

Související průvodci