Mobil uygulaması olan bir işletme sahibi genelde şunu sanır: uygulama sadece sitenin küçültülmüş hâlidir, siteyi kuran ekip bir de telefon ekranı çizer, iş biter. Oysa mobil uygulama siteye bakmaz; scriptin arkasındaki API katmanına bakar. Yani senin uygulamanın gördüğü şey vitrin değil, vitrinin arkasındaki depo memurudur. O memur ne kadar disiplinliyse uygulaman o kadar sağlıklı çalışır, ne kadar gevşekse uygulaman o kadar sessizce para kaybettirir.
İşin can sıkıcı tarafı şu: bu kayıp genelde hata ekranı olarak gelmez. Kullanıcı uygulamada bir e-pin satın alır, ödeme geçer, kod ekranda görünmez; kullanıcı ikinci kez dener, bu sefer görünür. Sen panelde iki sipariş görürsün, iki farklı kod düşmüştür, biri iade edilir. Panel sana "her şey yolunda" der çünkü panelin baktığı yer web oturumudur. Gerçek olay API tarafında yaşanmıştır. Bu yazıda, mobil uygulaması olan işletmeler için bir e-pin satış scripti seçerken veya mevcut e-pin yazılımını mobil için hazırlarken bakman gereken katmanı tek tek açıyorum.
Çoğu kişi API'yi "bağlantı" sanır, oysa o bir sözleşmedir
API'yi kablo gibi düşünmek en yaygın hata. Kablo takılır ve çalışır; API ise iki tarafın imzaladığı bir sözleşmedir. Uygulaman "şu ürünün stoğunu sor" der, script "şu formatta cevap veririm" der. Sözleşmenin maddeleri belirsizse uygulama geliştiricin her ekranda tahmin yürütür. Tahmin yürüten kod, bir gün seni ararayan bir müşteri olarak geri döner. İyi bir dijital ürün satış scripti API'sini belgelendirir: her uç nokta için hangi alanın zorunlu olduğunu, hata kodlarının ne anlama geldiğini, para biriminin kuruş mu tam sayı mı geldiğini yazar. Belgesi olmayan bir API, yazılı olmayan sözleşmedir; tarafların ikisi de haklı çıkar, müşteri kaybeden sen olursun.
Mobil uygulaman neden web panelinden farklı davranmak zorunda?
Web tarayıcısı kapanınca oturum biter; telefon uygulaması aylarca açık kalır. Tarayıcı sürekli internettedir; telefon asansörde şebeke kaybeder, ödeme ekranında bankaya gider döner. Bu yüzden mobil için tasarlanmamış bir epin yazılım altyapısı, aynı isteği iki kez almaya hazır değildir. Kullanıcı "Satın Al"a bastı, istek gitti, cevap gelmeden şebeke koptu, uygulama tekrar denedi: script bunu iki ayrı sipariş sayarsa iki kod harcarsın. Çözüm basit ve standarttır: her sipariş isteğine uygulamanın ürettiği benzersiz bir işlem anahtarı eklenir, script aynı anahtarı ikinci kez görürse yeni sipariş açmaz, ilkinin sonucunu döner. Bu tek madde, mobil kaynaklı çift satışların neredeyse tamamını bitirir.
| İhtiyaç | Web tarafında karşılığı | Mobil tarafında olması gereken | Atlanırsa sonuç |
|---|---|---|---|
| Oturum | Çerez tabanlı oturum | Süreli erişim + yenileme anahtarı | Kullanıcı sürekli çıkış yer |
| Sipariş oluşturma | Form gönderimi | Tekrar-güvenli işlem anahtarı | Aynı üründen çift satış |
| Kod teslimi | Sayfa yenileme | Durum sorgulama + bildirim | Kod göründü sanılıp iade |
| Stok | Sayfa açılışında okuma | Rezervasyon süreli kilit | Ödenen ürünün stoğu biter |
| Fiyat | Sunucuda hesaplanır | Sunucuda hesaplanır, asla cihazda | Fiyat oynanmış sipariş |
| Sürüm | Anında güncellenir | Sürüm başlığı ile uyumluluk | Eski uygulamalar kırılır |
Token, oturum ve cihaz: uygulamanın sessizce sızdırdığı üç nokta
Mobil uygulamada saklanan erişim anahtarı, kasanın anahtarı gibidir. Uzun ömürlü tek bir anahtar üretip telefona gömen kurulumlar hâlâ çok yaygın. Doğru kurgu ikilidir: kısa ömürlü bir erişim anahtarı ve onu yenileyen ayrı bir anahtar. Erişim anahtarı çalınsa bile ömrü dakikalarla sınırlıdır. Yenileme anahtarı ise cihazla eşleşir; kullanıcı "tüm cihazlardan çıkış yap" dediğinde script tarafında tek hamlede iptal edilebilir. Bir de cihaz kaydı meselesi var: aynı hesabın onlarca cihazdan aynı anda bakiye harcaması senin için normal mi? Değilse bunu API seviyesinde sınırlaman gerekir, uygulama arayüzünde değil. Arayüzde konan her kural, isteği doğrudan API'ye gönderen biri tarafından beş dakikada aşılır.
Mobil kaynaklı destek taleplerinin dağılımı
- Oturum ve giriş sorunları 45%
- Kod teslim gecikmesi 25%
- Ödeme dönüşü kayıpları 20%
- Diğer 10%
Stok senkronizasyonu: aynı kodu iki kişiye satmanın matematiği
Web'de iki kullanıcı aynı anda son kodu almaya çalıştığında script genelde veritabanı seviyesinde bir kilit kullanır. Mobilde ise araya ödeme sağlayıcısına gidiş-dönüş girer ve bu süre uzar. Kullanıcı bankada 40 saniye beklerken o kod hâlâ rafta duruyorsa, başka biri kapar. Doğru yaklaşım süreli rezervasyon: sipariş açıldığı anda kod belirli bir süre için kilitlenir, ödeme onaylanırsa teslim edilir, süre dolarsa otomatik serbest bırakılır. Bu davranışı olmayan bir e-pin scripti mobilde büyüdükçe iade oranını da büyütür. Rezervasyon süresini ödeme sağlayıcının ortalama dönüş süresinin en az üç katı yapmak pratikte iyi sonuç verir.
Telefonun uçak modunu, ödeme onay ekranındayken aç ve kapat. Sipariş tek kalıyorsa API'n tekrar-güvenli demektir; ikiye çıkıyorsa işlem anahtarı eksiktir.
Sipariş durumu ve bildirim: kullanıcıyı uygulamada tutan sessiz döngü
Mobilde kullanıcı ekranı kapatır. Kod hazır olduğunda onu geri çağıracak bir mekanizma yoksa, kullanıcı yarım saat sonra "param gitti" diye yazar. Bu yüzden API'nin sipariş durumu için net bir uç noktası ve tercihen bir bildirim tetikleyicisi olmalı. Durum değerleri muğlak olmamalı: "bekliyor", "ödendi", "teslim edildi", "iade" gibi sayılı ve sabit durumlar kullan. "işleniyor" gibi her şeyi kapsayan bir durum, destek ekibini de uygulamayı da kör eder. Pinova gibi yapılandırılmış bir e-pin satış yazılımı tarafında bu durum makinesi hazır gelir; senin işin sadece uygulamanın hangi durumda hangi ekranı göstereceğine karar vermek olur.
Sürüm yönetimi: API'yi değiştirdiğinde eski uygulamalar ne olacak?
Web'de bir alanı yeniden adlandırırsan kullanıcılar sayfayı yeniler ve sorun biter. Mobilde öyle değil; kullanıcıların bir kısmı altı ay önceki sürümü kullanıyordur. Bu yüzden API'de alan silmek veya anlamını değiştirmek, uzaktan uygulama kırmakla eşdeğerdir. Kural şu: yeni alan eklemek serbesttir, var olanı kaldırmak sürüm işidir. İsteğe bir sürüm başlığı koy, script eski sürümler için eski davranışı korusun. Ayrıca API'nin "bu sürüm artık desteklenmiyor, lütfen güncelle" diyebileceği bir yol bırak; uygulamanın kırılarak değil, nazikçe uyararak yaşlanması gerekir.
| Kontrol maddesi | Neden önemli | Durum |
|---|---|---|
| Her sipariş isteğinde işlem anahtarı | Çift satışı ve çift tahsilatı bitirir | Zorunlu |
| Kısa ömürlü erişim + yenileme anahtarı | Çalınan anahtarın etkisini sınırlar | Zorunlu |
| Fiyatın yalnızca sunucuda hesaplanması | Cihazdan gelen tutara güvenilmez | Zorunlu |
| Süreli stok rezervasyonu | Ödeme beklerken kodun kapılmasını önler | Zorunlu |
| Sabit ve sayılı sipariş durumları | Destek yükünü doğrudan azaltır | Yüksek |
| Sürüm başlığı ve geriye uyumluluk | Eski uygulamaları kırmadan geliştirme | Yüksek |
| İstek hız sınırı ve kötüye kullanım koruması | API'yi doğrudan dövmeye karşı savunma | Yüksek |
| Hata kodlarının belgelenmesi | Geliştiricinin tahmin yürütmesini engeller | Orta |
Peki bunların kaçı senin mevcut kurulumunda var?
Dürüst ol: yukarıdaki sekiz maddeyi bir kağıda yaz ve mevcut altyapını kuran kişiye tek tek sor. Cevapların yarısı "öyle bir ihtiyaç olmadı" ise, ihtiyaç doğduğunda bunu müşteri şikâyetinden öğreneceksin demektir. Mobil uygulama, işletmeni büyütürken aynı zamanda altyapındaki her boşluğu büyüteçle gösterir. Özellik listesine bakarken "mobil uyumlu" ifadesine değil, API'nin nasıl belgelendiğine ve yukarıdaki davranışların hazır gelip gelmediğine bak. Paket karşılaştırması için fiyatlandırma bölümü işini görür.
Uygulaman hazır, sıra altyapıda
Pinova, mobil uygulamanın güveneceği API davranışlarını kutudan çıktığı gibi sunar: işlem anahtarı, süreli stok rezervasyonu, sürümlenmiş uç noktalar ve belgeli hata kodları.
Mobil uygulamam için ayrı bir script mi almalıyım?
Hayır. Doğru kurgu tek bir arka uç ve onun üzerine oturan iki yüzdür: web ve mobil. İki ayrı script, iki ayrı stok ve iki ayrı muhasebe demektir; bu da uzun vadede en pahalı çözümdür.
API'yi başka bir geliştiriciye açmak güvenli mi?
Anahtar bazlı erişim, yetki kapsamı ve hız sınırı varsa güvenlidir. Geliştiriciye üretim anahtarı yerine sınırlı yetkili test anahtarı vermek standart uygulamadır.
Çift sipariş sorununu uygulamada çözemez miyim?
Kısmen çözersin ama garanti edemezsin. Ağ kopması uygulamanın kontrolü dışındadır; kalıcı çözüm sunucu tarafında aynı işlem anahtarını ikinci kez kabul etmemektir.
Bildirim altyapısı script ile mi gelir?
Script sipariş durumunu ve tetikleyiciyi sağlar; bildirimi cihaza ileten servis ayrıdır. Önemli olan, scriptin durum değiştiğinde dışarıya haber verebilen bir kancaya sahip olmasıdır.
Mobil tarafta kazanan işletme, en şık ekranı çizen değil; ağ koptuğunda bile doğru davranan altyapıyı kuran işletmedir. Yukarıdaki maddeleri kendi kurulumunda tek tek işaretle, eksikleri gördüğünde de bu davranışların hazır gelen bir sistemde nasıl çalıştığını canlı demo üzerinde kendi gözünle dene; bir sipariş aç, ağı kes, sonucu gör.