IOSOR

IOSOR Znalosti

Incident týdne peněženky: Zablokovaná autorizace není druhá platba

Zvládněte svůj první incident s peněženkou CPaaS bez paniky. Zjistěte, jak předplacená držení, zadržené autorizace a limit USD 20 fungují bez dvojího účtování.

Incident týdne peněženky: Zablokovaná autorizace není druhá platba.

Když na váš white-label portál dopadne první incident peněženky

Panel operátora ukazuje červený poplach: zákazník hlásí zamrzlou objednávku a tvrdí, že zůstatek utrpěl dvojí zásah. Panika nastupuje, protože se obáváte chyby fakturačního motoru. V provozu předplaceného CPaaS je zlatým pravidlem absolutní poctivost hlavní knihy. Zablokovaná autorizace není nikdy druhým výběrem z uživatelského zůstatku.

Anatomie předplaceného držení versus zaúčtované platby

Pochopení mechaniky účetní knihy zabraňuje lavině tiketů podpory. Drženi je jednoduše rezervovaná část z předplaceného limitu USD 20, která zaručuje, že klient pokryje nadcházející dávku zpráv. Nepřevádí finanční prostředky do naší provozní knihy, dokud potvrzení doručení (DLR) nepotvrdí úspěch přes webhook. Pokud upstream operátor relaci přeruší, držení zůstane aktivní ve stavu čekání. Nikdy se nezmění v dokončený odpis.

Prevence paniky s jasným uživatelským rozhraním

Pracovníci podpory často nesprávně interpretují čekající držení jako skutečné poplatky, protože starší systémy je naučily zaměňovat autorizaci s inkasem. Své uživatelské rozhraní musíte nastavit tak, aby zobrazovalo čekající držení v odlišné jantarové barvě oddělené od zelených plateb. Když zákazník otevře tiket o zaseknuté objednávce, vaším prvním krokem je kontrola API logu na nevyřešený HB signál.

Navigace v limitu USD 20 a spouštěčích kontroly

Každý nový klientský prostor začíná přísným předplaceným limitem USD 20 na ochranu před chybami ve skriptech. Jakmile zákazník škáluje své objemy OTP a notifikací, překročení měkkého prahu poblíž USD 1 000/měsíc spustí automatickou kontrolu shody. Tato revize vyhodnocuje vzorce provozu a poměry DLR. Má nulový vztah k fakturačním držením. Klienti si často pletou rutinní kontroly rizika se zaseknutými drženími; oddělení zajišťuje hladké škálování.

Krok za krokem protokoly pro operátory

Když si klient stěžuje na zablokované držení, postupujte podle této přesné provozní sekvence k diagnostice příčiny bez narušení živých kampaní:

Krok Akční položka Očekávaný stav hlavní knihy
1 Dotaz na ID transakce přes API Vyhledat čekající autorizaci
2 Zkontrolovat upstream webhook Ověřit timeout HB signálu
3 Prověřit přiřazení JIT čísla Potvrdit frontu operátora
4 Obnovit zobrazení zůstatku Uvolnit držení, pokud vypršelo

Začněte s IOSOR

Otevřete konzoli IOSOR a přejděte na kartu Fakturace tenanta, kde můžete filtrovat čekající autorizace oproti surovým zpětným voláním DLR. Zkontrolujte aktivní účetní knihu transakcí, abyste našli neuvolněné blokace, které překročily standardní dobu platnosti TTL, aniž by obdržely konečné potvrzení doručení nebo událost vrácení peněz.

Shrnutí IOSOR

Tato příručka ukázala, že uvíznutá blokace zůstatku je izolovaná autorizační rezervace, nikoli duplicitní finanční poplatek v účetní knize vašeho tenanta. Zaměňování autorizačních blokací s konečnými debety vypořádání vytváří zbytečné eskalace tiketů a poškozuje uživatelskou důvěru ve vaši platformu s vlastní značkou.

Pravidelně auditujte TTL čekajících autorizací a zřetelně prezentujte stavy blokací v uživatelském rozhraní portálu tenanta pomocí vyhrazených indikátorů stavu. Nespouštějte nouzové ruční vrácení peněz ani nedovolte agentům podpory upravovat zůstatky v účetní knize, aniž byste nejprve ověřili zpětná volání o stavu doručení oproti autorizačnímu protokolu.

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

Související průvodci