DLR lag kumpara sa API accepted: itigil ang pagsunog ng prepaid sa mga huling resibo

Ang status na API accepted ay kumpirmasyon lang ng pagtanggap sa payload at hindi ng aktwal na pagdating ng SMS sa handset. Ang pagkakamaling ituring itong terminal state ay nagdudulot ng magastos na retries na umuubos sa inyong USD balance. Ang tamang paggamit ng DLR webhook ang solusyon para maiwasan ang pagkalugi.

Paglilinaw sa agwat ng pagtanggap at resibo

Kapag ang pag-inject ng mensahe ay nagtagumpay sa gateway, ang inyong platform ay agad na nakatatanggap ng API accepted payload. Gayunpaman, ang mga carrier delivery receipt (DLR) ay madalas na nahuhuli nang ilang segundo o minuto. Ang pagpapatakbo nang walang kamalayan sa likas na latency na ito ng network ay nagdudulot ng mga maling alarma at hindi kinakailangang mga escalation sa suporta.

Pagtukoy sa mga ugat ng pagkaantala ng signal

Ang pagsisikip ng network, mga paghahanap sa HLR, at ang lalim ng pila ng carrier sa ibaba ay madalas na nag-aantala sa mga huling callback ng DLR. Kung ang inyong sistema ay nagpapalagay ng mga agarang estado ng terminal, ang mga panandaliang pagkaantala ay nagdudulot ng agresibong muling pagtatangka na nagpapagod nang maaga sa inyong mga badyet sa pagmemensahe na USD 1,000/bawat buwan.

Pag-reconcile ng ledger at pinansyal na pagkakalantad

Ang mga modelo ng prepaid na pagmemensahe ay nangangailangan ng mahigpit na pagsasabay sa pagitan ng mga debit ng balanse at ng aktwal na pagtatapos ng mensahe. Ang pagbabawas ng pondo sa pagtanggap ng API habang binabalewala ang mga huling katayuan ng DLR ay lumilikha ng mga pagkakaiba sa pinansyal kapag ang mga mensahe ay tuluyang nabigo.

Mga maihahambing na estado ng ikot ng buhay ng mensahe

Mga pangangalaga sa pagpapatakbo laban sa tahimik na pagkaubos

Ang pagpigil sa pagkaagnas ng prepaid balance ay nakadepende sa mga awtomatikong JIT hold at dynamic state assignment. Sa halip na basta na lamang mag-debit sa pagsusumite ng API, magpatupad ng hold-and-assign mechanism na nagrereserba ng pondo hanggang sa kumpirmahin ng carrier ang paghahatid o matapos ang isang mahigpit na timeout.

Magsimula sa IOSOR

Buksan ang konsol ng IOSOR at pumunta sa iyong mga setting ng ikot ng buhay ng pagmemensahe upang ilipat ang iyong ledger mula sa mga agarang debit patungo sa mga hawak na may kamalayan sa estado. Magtakda ng awtomatikong pampasigla ng JIT na paghawak sa pagtanggap ng tinatanggap na payload ng API mula sa iyong gateway. Mapa ang iyong mga papasok na webhook ng DLR upang tapusin ang mga pagkakasundo ng balanse lamang kapag nakumpirma na ang mga estadong pangwakas ng paghahatid.

• Subukan muli ang mga nabigong item ng kampanya ng SMS nang walang dobleng pag…
• Suri ng dami ng SMS: kapag hindi na sapat ang prepaid pilot
• Listahan ng mga kakulangan sa coverage na maaaring ilakip ng finance sa isang

Buod ng IOSOR

Ang pagtrato sa payload ng pagtanggap ng API 200 OK bilang isang pangwakas na kaganapan sa paghahatid ay naglalantad sa iyong prepaid na ledger sa tahimik na pagkaubos mula sa mga naantalang resibo ng carrier at maagang pag-ulit. Ang pagpapatunay sa mga callback ng DLR sa ibaba bago ayusin ang mga transaksyong pampinansyal ay nagsisiguro na ang iyong balanse sa pagmemensahe ay mahigpit na sumasalamin sa mga na-verify na estado ng pagtatapos.