Son kullanıcı gönderimi hala tek bir ön ödemeli defterden düşer

Gömülü mesajlaşma son kullanıcıya ücretsizmiş gibi gelir: SaaS arayüzünde Gönder düğmesine basar ve yeşil bir onay işareti görür. Ancak arka planda, gerçekleşen her başarılı gönderim hala ISV'ye ait tek bir ön ödemeli defterden düşer. Ürün bir API entegre etti diye sihirli bir şekilde ikinci bir cüzdan oluşmaz. Eğer ISV bakiyedeki tutma işlemlerini finanse etmiyorsa, gönderim sahte bir teslim edildi durumuyla değil, dürüst bir ürün hatasıyla başarısız olmalıdır.

Kurgusal muhasebe en yaygın başarısızlık şeklidir: IOSOR cüzdanı tarafından desteklenmeyen uygulama içi kredi sayaçları, ön ödemeli defter tüketilirken yapılan SaaS iadeleri veya tek bir OTP için iki kez borç kaydeden eşgüçsüz yeniden denemeler. Gömülü yapı yönetim konsolunu gizler; ancak fon sağlayan taraf her zaman ISV kalır.

Mimarinin temel kuralı: son kullanıcı gönderimi ≡ ISV ön ödemeli borç kaydı. Tüm tasarım incelemeleri bu ilke ile başlar.

Arayüz ürün kredilerini gösterse bile tek bir defter vardır

Müşterilere satılan mesaj paketleri ISV'nin ticari katmanına aittir. Bunların, ISV tarafından fonlanan tek IOSOR cüzdanındaki ön ödemeli tutma ve borç kayıtlarına doğrudan eşlenmesi gerekir. Defter satırlarıyla asla uyuşmayan bir müşteri bakiyesi, destek ekibi için büyük bir borç yüküne dönüşür.

Tutmalar ve eşgüçlülük gömülü yollarda da geçerliliğini korur

Sunucu tarafı gönderimlerinde OTP ve işlemsel SMS'ler için mutlaka eşgüçlülük (idempotency) anahtarları kullanılmalıdır. SaaS arayüzündeki bir çift tıklama, tek bir kullanıcı eylemi için iki ayrı borç kaydı oluşturmamalıdır. Zaman aşımı sonrası yapılan yeniden denemeler, nihai bir DLR raporu veya tanımlı bir hata alınana kadar aynı anahtarı izlemelidir.

Ürün hatalarını defter gerçeğiyle eşleştirin

Kanal devirleri aynı cüzdanda kalır

Eğer ürün daha sonra SMS'in yanına e-posta veya ses hizmeti eklerse, finans onaylı bir kanal devri yapılmadığı sürece harcamalar yine aynı ön ödemeli defterden düşmeye devam eder. Gömülü yapı ücretsiz bir yan kanal oluşturmaz. SaaS ayarlarında yeni bir canlı modülü açmadan önce cüzdan komşuluğu dokümantasyonunu okuyun.

İlgili operasyon yolları

• Cüzdanda ikinci kanal: harcama devri
• eşgüçlülük, yeniden deneme ve para
• Çok kiracılı hesaplarda hız sınırlarının güvenli uygulanması

IOSOR ile başlayın

IOSOR Konsolunu açın ve kiracı kredi sisteminizi doğrudan birincil ön ödemeli cüzdan defterine eşleyin. Tüm sunucu tarafı gömme isteklerinin, ana cüzdan üzerinde bir bekletme işlemi başlatmadan önce deterministik bir eşsizlik anahtarı iletilmesini sağlayın. Gelen DLR'leri işlemek için web kancası uç noktanızı yapılandırın; böylece açık bekletme durumları kesin defter borçlarına veya serbest bırakmalarına dönüşsün.

IOSOR özeti

Gömülü bir yazılım arayüzü, son kullanıcılara özel mesaj kredileri sunabilir; ancak her gerçek gönderim, bağımsız yazılım satıcısı tarafından finanse edilen tek ön ödemeli cüzdan defterine bağlanır. Yeniden denemeler, kanal genişletmeleri ve kullanıcı durum sinyalleri, desteklenmeyen arayüz soyutlamaları yerine doğrudan cüzdan bekletmeleriyle mutabakata varılmalıdır. Katı sunucu tarafı eşsizlik anahtarları uygulayın ve her kiracı arayüzü durumunu gerçek defter DLR yanıtlarıyla eşleyin. Desteklenmeyen ikincil cüzdanlar icat etmeyin veya kiracı arayüzü yeniden denemelerinin somut defter bekletmeleri olmadan çalışmasına izin vermeyin.