Sessiz Değiştirme Yerine Kirli Havuzun Atamayı Durdurması

Kirli bir havuz tespit edildiğinde numarayı sessizce değiştirmek, webhook entegrasyonunu ve DLR takibini bozan büyük bir tuzaktır. IOSOR, bu sorunu çözmek için atama akışını anında durdurur.

Kirli Havuz Tespitinin Çalışma Mekanizması

Bir E.164 numarası için JIT (Just-In-Time) talebi başlatıldığında, IOSOR platformu hedef havuzun sağlık metriklerini titizlikle değerlendirir. Gelen SMS spam'leri, yüksek hacimli işlenmemiş STOP anahtar kelimeleri veya başarısız OTP teslimat modelleri tespit edilirse, havuz kirli olarak işaretlenir. Sistem, aktif bir hesaba güvenliği ihlal edilmiş bir numara atamak yerine atama hattını tamamen durdurur. Bu sayede müşterilerin kötü şöhretli numaraları devralması ve teslimat sorunları yaşaması önlenir.

Sessiz Değiştirmenin Neden Bir Platform Riski Olduğu

Kötü bir havuzu gizlemek için sessizce numara değiştirmek, alt sistemlerde ciddi senkronizasyon sorunlarına yol açar. Bir alıcı belirli bir E.164 kaynağı talep ettiğinde ve arka planda sessiz bir değişiklik yapıldığında, webhook uç noktaları karışır ve DLR (teslimat raporu) takibi tamamen bozulur. IOSOR'da, müşteri konsolunda sahte bir 'Aktif' durumu göstermiyoruz. Arka planda kaynakları değiştirirken başarıyı taklit etmek, API uyumsuzluk hatalarına neden olur ve finansal defterin doğruluğunu bozar.

Needs_swap Durumu ve Operasyon Konsolu Görünürlüğü

Kirli havuzları güvenli bir şekilde yönetmek için dahili sistem, işlemi 'Needs_swap' durumuyla işaretler. This özel teknik terim, müşteri tarafında kafa karışıklığını önlemek için kesinlikle operasyon tarafında kalır. Alıcı, kendi panelinde temiz bir 'Beklemede' veya 'Duraklatıldı' durumu görür. Bu, platform operatörleri havuzu manuel olarak incelerken veya temel yönlendirme yollarını değiştirirken yanlış beklentilerin oluşmasını engeller. Alıcının API'si, simüle edilmiş bir başarı mesajı yerine yapılandırılmış bir duraklatma bildirimi alır.

Defter Bloke İşlemleri ve Ön Ödemeli Alt Sınır

Bu atama duraklatması sırasında, alıcının bakiyesindeki ön ödemeli bloke aktif kalır ancak tahsil edilmez. Hesap bakiyesi gerekli olan USD 20 ön ödemeli alt sınırın altına düşerse, aşım durumlarını önlemek için atama otomatik olarak reddedilir. Aylık USD 1,000 civarındaki yumuşak inceleme sınırına yaklaşan yüksek hacimli hesaplar için bu duraklatma, hatalı varlıklar üzerinde kontrolsüz MRC (Aylık Tekrarlayan Ücret) birikmesini önler. Havuz temizlendiğinde veya operasyon ekibi tarafından değiştirildiğinde, defter blokesi kesinleştirilir.

Engellenen Atamaların ve İlgili Sorunların Çözülmesi

Bu engellenen atamaların çözülmesi, havuzun sağlığının sistematik olarak doğrulanmasını gerektirir. Operatörler, yönlendirme günlüklerini incelemeli ve blokeyi kaldırmadan önce gelen SMS ve OTP akışlarının tamamen temiz olduğunu onaylamalıdır. Bu manuel kontrol süreci, yalnızca yüksek kaliteli ve güvenilir numaraların müşterilere sunulmasını sağlar.

İlgili yazılar: Bir Numara Havuzu Yeniden Kullanılmadan Önce Bekleme Süresi · Numara Yaşlandırma İtibardır, JIT Satın Alımı Değildir · ilk tahsilattan önce ön ödemeli bakiye rezervi.

IOSOR ile başlayın

Engellenmiş bir atamayı çözmek için IOSOR Ops konsolunu açın ve şu anda Needs_swap durumunda bulunan işaretli JIT işlemini bulun. Alıcı panosunun, webhook uç noktalarını ve DLR takibini bozar türden yanıltıcı bir Aktif durumu yerine Duraklatıldı durumunu doğru şekilde gösterdiğini doğrulayın. Kirli havuz metrikleri temizlendiğinde veya manuel takas onaylandığında, normal yönlendirmeye devam etmek için defter tutmasını kaldırın.

IOSOR özeti

Bu makale, kirli havuz sorunlarını sessiz numara takaslarıyla maskelemenin alt akış API senkronizasyonunu bozan kritik bir platform riski olduğunu kanıtladı.