IOSOR

IOSOR Kunskap

Ogiltigt MSISDN får inte debiteras

Lär dig hur IOSOR-plattformen blockerar ogiltiga E.164-telefonnummer vid ingången, vilket förhindrar felaktiga debiteringar i huvudboken och skyddar ditt förbetalda saldo.

Ogiltigt MSISDN får inte debiteras.

Ingressvalidering kontra nedströmsfel

Vid dirigering av stora volymer SMS- eller OTP-trafik är det avgörande för den finansiella integriteten att skilja mellan en ogiltig mottagaradress vid ingången (ingress) och ett leveransfel nedströms. Ett ogiltigt MSISDN måste avvisas omedelbart vid API-gatewayen innan någon transaktion sker i huvudboken. Om ett ogiltigt nummer kringgår ingresskontrollerna kan det generera en DLR nedströms med en okänd status, vilket ser ut som en förbrukning men inte resulterar i någon leverans. IOSOR tillämpar strikta valideringsregler för att förhindra detta, vilket säkerställer att ditt saldo skyddas mot felaktiga destinationsformat.

E.164-parsningsmotorn

Varje API-begäran som riktar sig till ett mobilnummer genomgår en realtidsparsning mot den globala E.164-standarden. Plattformen kontrollerar landskod, nationell destinationskod och abonnentnumrets längd. Om formatet är ogiltigt returnerar gatewayen omedelbart 'HTTP 400 Bad Request'. Denna JIT-validering säkerställer att icke-existerande dirigeringsvägar blockeras innan resurser tilldelas eller någon förbetald spärr tillämpas. Denna mekanism förhindrar att ogiltiga nummer utlöser operatörsförfrågningar nedströms som medför dolda kostnader.

Huvudboksregler och förbetalda spärrar

För att upprätthålla ett hälsosamt saldo använder IOSOR en realtidshuvudbok. När en giltig SMS-begäran accepteras placeras en tillfällig förbetald spärr på ditt saldo. Om meddelandet dirigeras framgångsrikt omvandlas spärren till en debitering. Men om numret flaggas som ogiltigt vid ingången skapas ingen spärr och noll saldo debiteras. Detta skyddar din förbetalda minimigräns på USD 20 från att urholkas av felaktiga destinationssträngar. För konton som skalar upp hjälper en mjuk granskning nära USD 1,000/månad till att optimera dirigeringssökvägar och justera MRC-gränser för dedikerade resurser.

Webhook-data och felkoder

När ett meddelande avvisas vid ingången innehåller API-svaret en specifik felkod. Istället för att vänta på en asynkron DLR-webhook får din applikation ett omedelbart synkront fel. Detta svar innehåller den ogiltiga parametern och en tydlig avvisningskod. För giltiga nummer kommer systemet att tilldela dirigeringsvägen och skicka statusuppdateringar via webhook, inklusive 'STOP'- och 'Verify OK'-händelser, vilket säkerställer full transparens över din meddelandepipeline utan att slösa API-cykler.

Utvecklarresurser och integration

För att bygga en stable integration som undviker onödiga utgifter bör utvecklare implementera validering på klientsidan innan de anropar API:et. Granska dessa viktiga guider för att optimera din implementering:

Börja med IOSOR

Från sandlådan POST:a en destination utan landskod och en med omöjlig längd. Vänta HTTP 400 och ett orört ledger — inget hold, inget debet. Skicka sedan ett giltigt E.164 och bekräfta att holdet syns först efter accept. Flyttade pengar på det ogiltiga paret är ingångsparsningen trasig.

IOSOR sammanfattning

Ett formatavslag vid ingången är inte ett leveransfel. Ett ogiltigt MSISDN får aldrig öppna ett hold. Gör: parsa E.164 innan pengar rör sig. Gör inte: vänta på en unknown DLR som förklarar ett debet som inte ska finnas. Ledgern tiger tills numret är välformat.

Var den här guiden till hjälp?

Relaterade guider