DLR būsenos webhook koreliacija su išankstinio mokėjimo rezervacijomis

Siunčiant OTP SMS per IOSOR, sąskaitoje laikinai rezervuojama USD suma. Jei nesusiesite DLR webhook pranešimų su šiomis rezervacijomis, galite susidurti su įšaldytu kapitalu ir netiksliais likučiais. Įdiekite JIT suderinimo procesą per mūsų API, kad lėšos būtų automatiškai nurašytos arba grąžintos pagal pristatymo statusą.

Išankstinio mokėjimo rezervacijos mechanizmo supratimas

IOSOR ekosistemoje kiekviena siunčiama SMS užklausa inicijuoja momentinį JIT (Just-In-Time) likučio patikrinimą. Kai užklausa pradedama, sistema laikinai užšaldo sąskaitos likutį, kad užtikrintų pakankamą lėšų kiekį pranešimo pristatymui. Tai nėra galutinis nurašymas, o tik kapitalo rezervacija. Galutinis atsiskaitymas įvyksta tik gavus DLR (pristatymo patvirtinimo) būseną iš tinklo, užtikrinant, kad jūsų finansinė apskaita tiksliai atspindėtų faktinį kreditų sunaudojimą.

DLR pranešimo gyvavimo ciklas

Kai pranešimas išsiunčiamas, tinklas grąžina DLR būseną. Jūsų webhook galinis taškas gauna šį duomenų paketą, kuriame yra unikalus pranešimo ID ir galutinis būsenos kodas. IOSOR variklis susieja šį ID su originaliu operacijos įrašu. Jei būsena rodo sėkmingą pristatymą, sistema paverčia rezervuotą sumą nuolatiniu nurašymu. Jei būsena rodo klaidą, rezervacija grąžinama į jūsų turimą likutį, užtikrinant, kad mokate tik už sėkmingus bandymus.

Apskaitos suderinimo valdymas

Suderinimas yra automatizuotas, tačiau kūrėjai privalo stebėti delsą tarp išsiuntimo ir DLR gavimo. Jei DLR vėluoja, rezervacija išlieka aktyvi, o tai gali laikinai sumažinti jūsų turimą kreditą. Paskyroms, kuriose palaikomas 20 USD išankstinio mokėjimo minimumas, tai yra kritiškai svarbu norint išvengti paslaugų sutrikimų. Jei jūsų mėnesio apimtis viršija 1 000 USD, mūsų sistema inicijuoja peržiūrą, kad pakoreguotų kreditų limitus ir užtikrintų sklandų didelio dažnio srautą.

Kraštutinių atvejų ir skirtųjų laiko limitų valdymas

Ne visi pranešimai gauna DLR per numatytą laiką. Jei tinklas nepateikia būsenos atnaujinimo, IOSOR sistema naudoja valymo procesą, kuris atlaisvina pasenusias rezervacijas po nustatyto TTL (Time-To-Live) laikotarpio. Tai apsaugo nuo 'vaiduoklinių' rezervacijų įtakos jūsų likvidumui. Visada užtikrinkite, kad jūsų webhook tvarkyklė patvirtintų DLR gavimą per 500 ms, kad išlaikytumėte sinchronizaciją tarp mūsų apskaitos ir jūsų vidinių įrašų.

Būtini integracijos ištekliai

Norėdami užtikrinti, kad jūsų diegimas būtų patikimas ir atitiktų finansinio vientisumo geriausią praktiką, peržiūrėkite šiuos vadovus:

• Notifikacijų eiliškumas ir debeto knygavimas
• Pasikartojantis webhook neturi sukurti antro debeto
• idempotentiškumas, pakartojimai ir pinigai

Pradėkite su IOSOR

Norėdami užbaigti integraciją, eikite į 'IOSOR' konsolę ir atidarykite 'Webhook' nustatymus, kad sukonfigūruotumėte didžiosios knygos suderinimo galinį tašką. Įsitikinkite, kad jūsų klausyklė yra pasirengusi apdoroti 'dlr.status' duomenis ir tiesiogiai susieti juos su atitinkamu transakcijos sulaikymo ID. Šios koreliacijos išbandymas bandomojoje aplinkoje garantuos, kad rezervuotos lėšos bus atlaisvintos arba nurašytos akimirksniu, išvengiant didžiosios knygos nuokrypių.

IOSOR santrauka

Šiame vadove parodyta, kaip saugiai suderinti pranešimų pristatymą realiuoju laiku ir finansinės didžiosios knygos tikslumą. Susiedami gaunamus DLR atgalinius iškvietimus su aktyviais išankstinio mokėjimo sulaikymais, išvengsite kapitalo įšaldymo ir užtikrinsite, kad jūsų turimas likutis atspindėtų tikrąją pristatymo būseną, o ne blogiausio scenarijaus prielaidas.