IOSOR

IOSOR Tudás

Második katalógustermék: jelvény átadás

Szabályozza, hogyan váltanak a termékjelvények többszolgáltatásos bevezetés során a white-label prepaid CPaaS-on, állapoteltolódás nélkül.

Második katalógustermék: jelvény átadás.

Katalógusállapot a második termék érkezésekor

Egy második katalógusajánlat bevezetése egy white-label prepaid CPaaS-on belül azonnali UI kihívást jelent. Az operátorok gyakran küzdenek a jelvények szinkronizálásával a számlázási események során. Amikor egy bérlő virtuális számot kér egy meglévő OTP munkafolyamat mellé, a vezérlőpultnak azonnal tükröznie kell a JIT lefoglalást. Egy prepaid zárolás fenntartja az alapot, miközben az útvonalválasztási szabályok a bérlői profilhoz kötik az eszközt. Tekintse át az alapvető útvonalválasztási logikát az «ops when many products ship» (/learn/catalog/catalog-ops-when-many-products-ship) részben, hogy elkerülje az elavult jelzőket.

Hamis Élő státusz megelőzése átadáskor

Az idő előtti aktiválás elromlott üzenetküldési folyamatokhoz vezet. Egy szolgáltatás sem mutathat aktív státuszt mielőtt a DLR telemetria megerősíti a felvízi készséget. Ha a jelvény túl korán átfordul, az ügyfelek útvonal-hibákkal találkoznak, és a bizalom gyorsan megkopik. Olvasson a «false Live badge» (/learn/catalog/false-live-badge-incident-path) útról, hogy megértse, a korai státuszfrissítések hogyan váltanak ki támogatási jegyeket.

Bérlői bevezetés és kezdeti hitelkeret korlátok

Minden munkaterület szilárd pénzügyi alapon indul, 20 USD prepaid kerettel. Ez a kezdeti egyenleg védi az infrastruktúrát a Csalárd automatizációtól, miközben engedi a legitim teszteket. Ahogy a forgalom eléri az 1000 USD/hó körüli puha felülvizsgálatot, az automatizált jelzők ellenőrzik a használati mintákat hirtelen megszakítások nélkül. A bérlők az első eszközüket a «one account first path» (/learn/partner/white-label-one-account-first-path) keretrendszer szerint konfigurálják.

Többszolgáltatásos státusz összehasonlító táblázat

Állapot Jelvény Címke Számlázási Művelet Webhook Indító
Függőben Kiépítés JIT Zárolás asset.requested
Aktív Élő Egyenleg Terhelés asset.provisioned
Sikertelen Hiba Zárolás Visszatérítés asset.failed
Felfüggesztve Zárolva Folyamat Szünet asset.suspended

Webhookok és HB szinkronizációs mechanika

A valós idejű státuszfrissítések robusztus HB rutinokra és webhook kézbesítésre támaszkodnak. Szám hozzárendelésekor a platform JSON payloadot küld a bérlői végpontnak. Ha a végpont nem nyugtázza a vételt, a UI átmeneti állapotban tartja az átadási jelvényt az egyeztetés végéig. Ez biztosítja a DLR folytonosságot a nagy áteresztőképességű SMS forgalomhoz.

Kezdje el az IOSOR-ral

Nyissa meg a második termék chipjét. Hagyja In setupban, amíg a bind és egy kézbesített DLR meg nem erősíti az új vonalat. Az első termék a saját során marad Live — nem ajándékozza a jelvényt. Live-ra csak akkor váltson, ha a provisioned webhook és a prepaid hold egyezik. Írja le, ki adta át a jelvényt.

Kapcsolódó: Katalógus incidens hét: A hamis éles állapot alatt sem történhet terhelés Katalógus számlázási hét: a hamis Éles állapot nem számlázható Élesként előre fizetett egyenleg zárolása az első terhelés előtt.

IOSOR összegzés

A második katalógustermék második ígéret. Az átadó jelvény a megerősített bindet követi, nem a kiosztási kérést.

Tegye: az új chip In setup marad, amíg webhook plusz hold egyezik, majd a billentő neve.

Ne tegye: Live-ot festeni, mert az első már megy, vagy mert a JIT számot adott.

Hasznos volt ez az útmutató?

Kapcsolódó útmutatók