Pirminis kanalas neveikia: užsakytas atsarginis kelias be dvigubo nurašymo

Kai pirminis kanalas negali priimti arba užbaigti siuntimo, pirkėjams reikia užsakyto, pinigams saugaus kelio, sąžiningai atspindimo kliento vartotojo sąsajoje. Perjungimas nėra „išbandykite kiekvieną vamzdį, kol kas nors prilips“. Tai yra pavadinta seka: pirminis, tada atsarginis vienas, tada atsarginis du, jei dokumentuota – kiekvienas su aiškiu sustojimu. Piniginė rodo vieną apmokestinamą nurašymą už vieną kliento ketinimą, net jei kanalai pasikeitė užkulisiuose. IOSOR yra white-label išankstinio apmokėjimo CPaaS. Prietaisų skydelis ir webhook niekada neatskleidžia tiekėjų prekių ženklų.

Užsakytas atsarginis kopijavimas nėra „purkšti ir melstis“

Parašykite tvarką prieš paleidimą į gamybą. Pirminis kanalas aptarnauja koridorių, kol yra sveikas. Esant griežtam atmetimui, viršijus koridoriaus juostos laiko limitą arba kai saugykla nepasirengusi – pereikite prie kito kanalo. Neperduokite vieno OTP trims kanalams lygiagrečiai. Neišradinėkite naujos tvarkos incidento metu.

Vienas nurašymas už vieną kliento ketinimą

Sekite išankstinio balanso rezervas prieš pirmą nurašymą: rezervuokite vieną kartą, atsiskaitykite vieną kartą, kai kanalas priima vienetą. Atsarginis kopijavimas pagal tą patį ketinimą pakartotinai naudoja pinigų tapatybę – idempotentiškumas, pakartojimai ir pinigai.

Baltos etiketės statusas, kai pirminis kanalas neveikia

Kliento vartotojo sąsaja ir eksportas rodo IOSOR statusus: priimta, laukiama, pristatyta, nepavyko, reikia dėmesio – niekada kanalo prekių ženklų. Operacijos gali registruoti vykdantį kanalą; pirkėjai neturi to matyti. Perjungiant, atnaujinkite tą pačią ketinimo eilutę: rezultatas ir laiko žymės keičiasi; pinigų tapatybė nesikeičia.

Kada to nevadinti perjungimu

Mažas gautųjų laiškų skaičius su sąžiningu „Priimta/Išsiųsta“ yra pristatymas – vadovas esant žemam SMS pristatymui, o ne aklas kanalo apvertimas. Vėluojantis DLR po sėkmingo priėmimo yra vėlavimas – DLR, vėlavimas ir perjungimas – o ne antras nurašymas atsarginiame kanale.

Pirkėjo kontrolinis sąrašas užsakytam keliui

1. Atsarginės kopijos tvarka parašyta ir valdoma prieš „Live“?
2. Kiekviena perjungimo klasė susieta su laukimu, nesėkme ar kitu kanalu?
3. Vienas idempotentiškumo raktas apima pirminius ir atsarginius pinigus?
4. Kliento statusai yra baltos etiketės be tiekėjų prekių ženklų?
5. Nepavykusios rezervacijos keliai automatiškai atšaukiami be tylių atsiskaitytų vaiduoklių?

Pradėkite su IOSOR

Konsolėje sukonfigūruokite rikiuotą atsarginę seką prieš nukreipdami didelės apimties koridoriaus srautą gyvai. Užtikrinkite, kad kiekvienas atsarginis kelias prisijungtų prie pradinio kliento ketinimo ID, kad vienas išankstinis apmokėjimas apimtų geležinkelio perjungimą be dvigubo piniginės nurašymo. Nustatykite griežtus laiko limito vartus ir tvirtus atmetimo trigerius, kad srautas būtų perkeltas švariai be lygiagrečių bandymų.

IOSOR santrauka

Pirminis kanalo perjungimas pavyksta tik tada, kai atsarginė seka yra iš anksto apibrėžta ir griežtai susieta su vienu finansiniu rezervavimu. Bandymas taikyti lygiagretų nukreipimą sukelia dvigubus nurašymus ir sugadina pranešimų būsenų sekimą. Operatoriai konsolėje privalo nustatyti aiškias laukimo ribas, apibrėžti griežtus atmetimo kodus bei patikrinti kredito likutį prieš aktyvuojant antrinį kanalą UTC laiku. Nebandykite inicijuoti avarinio maršruto keitimo dėl įprastų vėlavimų, kai pagrindinis kanalas jau patvirtino pristatymo užklausą.