Çoğu işletme sahibi SMS'i basit bir kutucuk sanır: panelden bir API anahtarı yapıştırırsın, mesajlar gider, iş biter. Oysa e-pin ve dijital ürün satışında SMS, ödeme altyapısından sonra müşteriye dokunan ikinci en kritik kanaldır. Kodun kendisi saniyeler içinde üretilir ama müşterinin telefonuna düşmeyen tek bir doğrulama mesajı, tamamlanmış bir ödemeyi iade talebine çevirir. Sorun genelde yazılımda değil, yazılım ile sağlayıcı arasındaki sözleşmede, başlıkta ve kuyruk mantığındadır.
Gerçek şu ki piyasadaki birçok e-pin satış scripti, SMS'i sadece "gönder ve unut" şeklinde kurgular. Gönderim başarısız olduğunda kimse haberdar olmaz, teslimat raporu okunmaz, ikinci sağlayıcıya düşme mantığı hiç yazılmaz. Pinova tarafında bu işi farklı ele alıyoruz: SMS bir bildirim değil, sipariş yaşam döngüsünün denetlenebilir bir adımı. Bu yazıda entegrasyonun teknik iskeletini, maliyet matematiğini ve mevzuat tarafını, bir e-pin yazılımı kurarken gerçekten karşılaşacağın sırayla açıyorum.
SMS entegrasyonu neden ödeme entegrasyonundan daha kırılgan?
Ödeme sağlayıcısı başarısız olduğunda kullanıcı anında görür: ekranda hata çıkar, kart çekilmez, sen de logdan yakalarsın. SMS ise sessiz başarısızlığın ustasıdır. Sağlayıcı sana 202 Accepted döner, mesaj kuyruğa alınır, operatör tarafında filtrelenir ve hiçbir yere düşmez. Senin panelinde "gönderildi" yazar, müşteride ise hiçbir şey yoktur. İşte bu yüzden ciddi bir dijital ürün satış yazılımı, sağlayıcının kabul yanıtı ile gerçek teslimat raporunu iki ayrı durum olarak saklamak zorundadır. Pinova'da her gönderim kaydı kuyruğa alındı, sağlayıcıya iletildi, operatöre iletildi, cihaza ulaştı, başarısız şeklinde beş durumla izlenir; rapor webhook'u gecikirse kayıt otomatik olarak "doğrulanmamış" bandına düşer ve yeniden deneme mantığı devreye girer.
Hangi mesaj türünü hangi kanaldan göndermelisin?
Bütün mesajları aynı havuzdan göndermek, entegrasyonda yapılan en pahalı hatadır. Doğrulama kodu ile kampanya duyurusu aynı öncelik sırasına girdiğinde, akşam saat 20.00'de gönderdiğin 8.000 kişilik bültenin arkasında bekleyen OTP mesajı üç dakika gecikir ve o müşteri siparişi tamamlamaz. Kanal ayrımı bu yüzden mimari bir zorunluluktur. İşlemsel trafik her zaman ayrı bir kuyruk, ayrı bir öncelik ve mümkünse ayrı bir sağlayıcı hesabı kullanmalıdır. Pazarlama trafiği ise hız değil maliyet optimize edilerek, toplu paketlerle, gece bandı yasaklarına uyacak şekilde planlanır. Aşağıdaki tabloda bir epin yazılım kurulumunda kanalların nasıl ayrılması gerektiğini bulacaksın.
| Mesaj türü | Öncelik | Hedef gecikme | Yeniden deneme | İzin gerekli mi? |
|---|---|---|---|---|
| Giriş / işlem doğrulama (OTP) | Kritik | 0-6 saniye | 2 deneme, 20 sn arayla | Hayır (işlemsel) |
| Sipariş onayı ve kod teslim bildirimi | Yüksek | 0-30 saniye | 3 deneme, artan aralık | Hayır (işlemsel) |
| Bayi bakiye uyarısı | Orta | 0-5 dakika | 2 deneme | Hayır (sözleşmesel) |
| İade / hata bilgilendirme | Yüksek | 0-60 saniye | 3 deneme | Hayır (işlemsel) |
| Kampanya ve indirim duyurusu | Düşük | Toplu, saat bandına göre | 1 deneme | Evet (ticari izin) |
Tek sağlayıcıya bağlanmak neden zamanlı bombadır?
Bir sağlayıcının paneli bakıma girdiğinde, kontör bittiğinde ya da operatör tarafında başlığın geçici olarak askıya alındığında satışın tamamen durur. Burada çözüm, yazılımın sağlayıcıyı bir sürücü (driver) olarak görmesidir. Yani kod içinde "şu firmanın API'si" değil, "SMS gönderici arayüzü" bulunur; hangi firmanın kullanılacağı sadece ayarlardaki bir tercihtir. Böylece ikinci, hatta üçüncü bir sağlayıcıyı yedek olarak tanımlar; birincil sağlayıcı üst üste belirlediğin sayıda hata döndüğünde sistem otomatik olarak devre kesiciyi açar ve trafiği yedeğe taşır. Beş dakika sonra küçük bir sağlık testiyle birincile geri döner. Bu kalıp olmadan kurulan hiçbir e-pin satış yazılımı gerçek yoğunlukta güvenilir sayılmaz.
Başarısız SMS gönderimlerinin gerçek nedenleri
- Hatalı numara biçimi ve normalizasyon eksikliği 45%
- Başlık / İYS kaynaklı operatör reddi 25%
- Kontör bitimi ve limit aşımı 20%
- Sağlayıcı kesintisi ve zaman aşımı 10%
Numara normalizasyonu: sessizce paranı yiyen detay
Müşterilerin telefon numarasını asla senin beklediğin biçimde yazmaz. Başında sıfır, ülke kodu, parantez, boşluk, tire, hatta yanlışlıkla eklenmiş bir karakter... Sağlayıcıya olduğu gibi gönderdiğinde bazı istekler reddedilir, bazıları ise kabul edilip hiçbir yere ulaşmaz ve yine kontörden düşer. Doğru yaklaşım, numarayı kayıt anında tek bir kanonik biçime çevirmek, veritabanında o biçimde saklamak ve gönderim katmanında ikinci kez doğrulamaktır. Ayrıca aynı numaraya kısa aralıkta art arda OTP isteyen kullanıcıları sınırlamak gerekir; aksi halde bir kişi tek başına yüzlerce mesajlık kontörü tüketebilir. Pinova'da hem numara başına hem IP başına pencere bazlı sınır tanımlanır ve aşan istekler mesaj harcamadan reddedilir.
E-pin kodunun kendisini SMS gövdesine yazmak, ikinci el ekran görüntüsü ve "kod kullanılmış" itirazlarının en büyük kaynağıdır. SMS'te yalnızca sipariş numarası ve tek kullanımlık görüntüleme bağlantısı gönder; kod panelde, oturum doğrulamasının arkasında açılsın.
İYS, başlık ve ticari ileti: hangi mesaj gerçekten izin ister?
Türkiye'de toplu ileti gönderimi İleti Yönetim Sistemi kapsamındadır ve burada ayrım nettir: doğrulama kodu, sipariş durumu, teslimat bildirimi gibi mesajlar işlemsel sayılır; indirim duyurusu, yeni ürün tanıtımı, bayilik çağrısı ise ticari iletidir ve onaylı izin gerektirir. Yazılım tarafında bunun karşılığı, her müşteri kaydında ticari izin bayrağı tutmak ve pazarlama kuyruğunun bu bayrağı sorgulamadan tek bir mesaj bile üretememesidir. İzin listesi düzenli olarak senkronize edilmeli, izin geri çekildiğinde kayıt anında güncellenmelidir. Başlık tarafında ise marka adınla eşleşen bir gönderici başlığı almak, teslim oranını doğrudan yükseltir; jenerik başlıklar hem güven kaybettirir hem filtrelenme riskini artırır.
Kurulumdan önce hangi maddeleri işaretlemelisin?
Entegrasyonu yapmadan önce sağlayıcıyla ve kendi ekibinle netleştirmen gereken maddeler var. Aşağıdaki liste, sahada en çok geri dönüş aldığımız sorunların önüne geçmek için hazırlandı. Her maddeyi "evet" yapmadan canlıya çıkma; çünkü bu kalemlerin hepsi, sonradan düzeltmesi kurmasından çok daha pahalı olan şeylerdir.
| Kontrol maddesi | Neden önemli | Durum |
|---|---|---|
| Teslimat raporu webhook'u tanımlı mı? | Sessiz başarısızlığı görmenin tek yolu | Zorunlu |
| Yedek sağlayıcı ve devre kesici eşiği var mı? | Kesintide satışın durmaması için | Zorunlu |
| İşlemsel ve pazarlama kuyrukları ayrı mı? | OTP gecikmesini önler | Zorunlu |
| Numara normalizasyonu ve tekil kayıt kuralı | Boşa giden kontörü bitirir | Zorunlu |
| Numara ve IP başına gönderim limiti | Kontör sömürüsünü engeller | Zorunlu |
| Ticari izin bayrağı ve İYS senkronu | Mevzuat ve ceza riski | Zorunlu |
| Kontör azaldı uyarısı (eşik bildirimi) | Gece yarısı kontör bitmesini önler | Önerilir |
| Şablon yönetimi ve değişken denetimi | Bozuk mesaj metnini engeller | Önerilir |
| Mesaj başına maliyet raporu | Sipariş başı gerçek maliyeti görmek | Önerilir |
SMS maliyetini sipariş başına nasıl hesaplamalısın?
İşletmelerin büyük kısmı SMS'i genel gider yazar ve gerçek etkisini hiç görmez. Halbuki doğru ölçüm çok basit: bir siparişin tamamlanması için ortalama kaç mesaj harcandığını bul. Kayıt doğrulaması, giriş doğrulaması, sipariş onayı ve olası tekrar denemeler üst üste bindiğinde tek satış için üç dört mesaj çıkabilir. Buna bir de boşa giden, teslim edilemeyen gönderimleri ekle. Rakam netleştiğinde iki şey görürsün: ilki, OTP'yi gereksiz yere her girişte istemenin ne kadara mal olduğu; ikincisi, bazı bildirimleri e-posta veya panel içi bildirime taşımanın anında kâr yazdığı. İyi kurgulanmış bir dijital ürün satış scripti bu raporu sana hazır sunar; tahmin etmek zorunda kalmazsın. Ayrıntılı özellik kırılımını özellikler bölümünde, paket farklarını ise fiyat tablosunda görebilirsin.
SMS tarafını tahmine bırakmayı bırak
Kuyruk, yedek sağlayıcı, teslimat raporu ve izin yönetimi kutudan çıktığı gibi hazır gelsin; sen ürün ve satışa odaklan.
Birden fazla SMS sağlayıcısını aynı anda kullanabilir miyim?
Evet. Doğru kurgu, sağlayıcıları sürücü olarak tanımlayıp birincil ve yedek sıralaması vermektir. Birincil sağlayıcı belirlediğin hata eşiğini aştığında trafik otomatik olarak yedeğe geçer, sağlık testi başarılı olduğunda geri döner.
Doğrulama kodu mesajları için ticari izin almam gerekir mi?
Hayır. Doğrulama, sipariş onayı ve teslimat bildirimi gibi mesajlar işlemsel ileti sayılır. İzin gerektiren kısım kampanya, indirim ve tanıtım içerikli ticari iletilerdir; bunlar için onay kaydı tutman ve izin durumunu senkron etmen gerekir.
E-pin kodunu doğrudan SMS ile göndermek mantıklı mı?
Önerilmez. Kod SMS gövdesinde kaldığında ekran görüntüsü, cihaz devri ve itiraz riskleri artar. Bunun yerine sipariş numarası ve kısa ömürlü bir görüntüleme bağlantısı gönder, kodu oturum doğrulamasının arkasında göster.
Kontörüm gece bitti, sabaha kadar hiç mesaj gitmedi. Bu nasıl önlenir?
Eşik bazlı bakiye uyarısı ve yedek sağlayıcı ile. Kontör belirlediğin seviyenin altına indiğinde yöneticiye e-posta ve panel bildirimi düşer; birincil hesap tükendiğinde işlemsel mesajlar otomatik olarak ikinci hesaptan gönderilmeye devam eder.
SMS entegrasyonu, doğru kurulduğunda görünmez; yanlış kurulduğunda ise her gün destek kutunda kendini hatırlatır. Kuyruk ayrımı, yedek sağlayıcı, teslimat raporu ve izin yönetimi bir araya geldiğinde müşterin hiçbir şey fark etmez, sen de gece yarısı kontör kovalamazsın. Bu yapının hazır haliyle nasıl çalıştığını kendi gözünle görmek istersen canlı demo üzerinden panele girip gönderim kayıtlarını, durum akışını ve şablon yönetimini adım adım inceleyebilirsin.