IOSOR Panduan

MSISDN Tidak Sah Tidak Boleh Didebit

Ketahui cara platform IOSOR menyekat nombor telefon E.164 yang tidak sah pada kemasukan, mengelakkan debit lejar yang salah dan melindungi baki prabayar anda.

MSISDN Tidak Sah Tidak Boleh Didebit.

Pengesahan Kemasukan lwn Kegagalan Hiliran

Apabila menghalakan trafik SMS atau OTP volum tinggi, membezakan antara alamat destinasi yang tidak sah pada kemasukan (ingress) dan kegagalan penghantaran hiliran (downstream) adalah kritikal untuk integriti kewangan. MSISDN yang tidak sah mesti ditolak serta-merta di pintu laluan API sebelum sebarang transaksi lejar berlaku. Jika nombor yang tidak sah melepasi pemeriksaan kemasukan, ia mungkin menghasilkan DLR hiliran dengan status tidak diketahui, yang kelihatan seperti perbelanjaan tetapi tidak menghasilkan penghantaran. IOSOR menguatkuasakan peraturan pengesahan yang ketat untuk mengelakkan perkara ini, memastikan baki prabayar anda dilindungi daripada format destinasi yang salah.

Enjin Penghuraian E.164

Setiap permintaan API yang menyasarkan nombor mudah alih menjalani penghuraian masa nyata terhadap standard E.164 global. Platform ini menyemak kod negara, kod destinasi domestik dan panjang nombor pelanggan. Jika format tidak sah, pintu laluan mengembalikan 'HTTP 400 Bad Request' serta-merta. Pengesahan JIT ini memastikan laluan penghalaan yang tidak wujud disekat sebelum sumber diperuntukkan atau sebarang pegangan prabayar dikenakan. Mekanisme ini menghalang nombor yang tidak sah daripada mencetuskan pertanyaan pembawa hiliran yang menanggung kos tersembunyi.

Peraturan Lejar dan Pegangan Prabayar

Untuk mengekalkan baki yang sihat, IOSOR menggunakan lejar masa nyata. Apabila permintaan SMS yang sah diterima, pegangan prabayar sementara diletakkan pada baki anda. Jika mesej berjaya dihantar, pegangan tersebut ditukar kepada debit. Walau bagaimanapun, jika nombor itu ditandakan sebagai tidak sah pada kemasukan, tiada pegangan dibuat dan sifar baki didebit. Ini melindungi lantai prabayar USD 20 anda daripada terhakis oleh rentetan destinasi yang rosak. Untuk akaun yang meningkat naik, semakan lembut berhampiran USD 1,000/bulan membantu mengoptimumkan jadual penghalaan dan melaraskan had MRC untuk sumber khusus.

Payload Webhook dan Kod Ralat

Apabila mesej ditolak pada kemasukan, respons API mengandungi payload ralat tertentu. Daripada menunggu webhook DLR tidak segerak, aplikasi anda menerima ralat segerak serta-merta. Payload ini termasuk parameter yang tidak sah dan kod penolakan yang jelas. Untuk nombor yang sah, sistem akan menetapkan laluan penghalaan dan menghantar kemas kini status melalui webhook, termasuk acara 'STOP' dan 'Verify OK', memastikan ketelusan penuh terhadap saluran pemesejan anda tanpa membazirkan kitaran API.

Sumber Pembangun dan Integrasi

Untuk membina integrasi yang mantap bagi mengelakkan perbelanjaan yang tidak perlu, pembangun harus melaksanakan pengesahan pihak pelanggan sebelum menghubungi API. Semak panduan penting ini untuk mengoptimalkan pelaksanaan anda:

Mulakan dengan IOSOR

Dari kotak pasir, POST destinasi tanpa kod negara dan satu dengan panjang mustahil. Jangka HTTP 400 dan ledger tidak berubah β€” tiada hold, tiada debit. Kemudian hantar E.164 sah dan sahkan hold muncul hanya selepas accept. Jika wang bergerak pada pasangan tak sah, penghurai masuk rosak.

Inti IOSOR

Tolakan format di pintu masuk bukan kegagalan hantar. MSISDN tak sah tidak boleh membuka hold. Buat: hurai E.164 sebelum wang bergerak. Jangan: tunggu DLR unknown menjelaskan debit yang tidak patut wujud. Ledger senyap hingga nombor terbentuk betul.

Adakah panduan ini membantu?

Panduan berkaitan