Çoğu kişi entegrasyonu şöyle sanır: tedarikçiden API anahtarını alırsın, e-pin scriptine girersin, bir ürün eklersin, test siparişi verirsin, olduysa oldu. Bu yaklaşım ilk gün işe yarar gibi görünür çünkü tedarikçinin ilk cevabı genelde temizdir. Sorun ikinci haftada başlar: bakiye biter, tedarikçi stok kodunu değiştirir, ödeme sağlayıcısı bir siparişi iki kez bildirir ve sen o anda canlı müşteriyle, canlı parayla, canlı yorumla baş başa kalırsın.
Gerçek şu ki büyüyen satıcıların hiçbiri entegrasyonu canlıda denemez. Onların bir provası vardır: kendi bilgisayarında ya da ayrı bir alt alan adında duran, gerçek sistemin birebir ikizi bir ortam. Bu yazıda o ortamı sıfırdan nasıl kuracağını, tedarikçiyi nasıl taklit edeceğini ve canlıya geçiş gecesini nasıl sıkıcı bir rutine dönüştüreceğini anlatıyorum. Bir dijital ürün satış scripti kurarken bu adımı atlamak, en pahalı kısa yol.
Test ortamı olmadan entegrasyon yapmak neden kumardır?
Bir e-pin işinde üç ayrı taraf aynı saniyede konuşur: müşterinin tarayıcısı, ödeme sağlayıcısı ve tedarikçinin API'si. Bu üçlünün her biri kendi başına stabil olabilir ama birleşme noktaları kırılgandır. Ödeme onayı geldi ama tedarikçi zaman aşımına düştüyse ne olacak? Tedarikçi kodu verdi ama e-posta gitmediyse? Müşteri ödeme sayfasında geri tuşuna bastıysa?
Bu soruların cevabını canlıda öğrenmek demek, her cevabı bir müşteri şikâyetiyle satın almak demek. Test ortamının asıl amacı "çalışıyor mu" sorusunu cevaplamak değil; bozulduğunda ne olduğunu güvenle görmek. İyi bir e-pin satış scripti sana bu senaryoları elle tetikleme imkânı verir: bakiye yok, stok yok, tedarikçi yavaş, imza hatalı.
Sandbox ile canlı arasındaki üç fark neyi gizliyor?
Tedarikçilerin sandbox ortamları rahatlatıcı ölçüde naziktir ve tam olarak bu yüzden yanıltıcıdır. Birinci fark hız: test sunucuları yüksüz olduğu için 200 milisaniyede cevap verir, canlıda aynı çağrı akşam 21.00'de 8 saniyeye çıkar. Zaman aşımı süresini sandbox'a göre ayarlarsan canlıda hepsi patlar.
İkinci fark veri çeşitliliği. Sandbox genelde tek bir örnek kod döner; canlıda seri numarası ile şifreyi ayrı alanlarda gönderen, bazı ürünlerde tek satır, bazılarında dört satır veri veren yapılarla karşılaşırsın. Üçüncü fark hata dili: test ortamı düzgün JSON hata verirken canlı ortam bazen düz HTML hata sayfası döner ve senin epin yazılım tarafındaki ayrıştırıcı bunu anlamaz. Bu yüzden test ortamın sadece tedarikçinin sandbox'ına bağlanmamalı, kendi ürettiğin çirkin cevapları da sindirebilmeli.
Kendi test ortamını kurarken hangi katmanları ayırmalısın?
Doğru kurulum dört katmanı birbirinden ayırır. Uygulama katmanı, yani scriptin dosyaları: canlıdan kopya, ama ayrı klasörde. Veritabanı katmanı: kesinlikle ayrı bir veritabanı, canlı tabloya test siparişi yazmak muhasebeni kalıcı olarak kirletir. Yapılandırma katmanı: anahtarlar, e-posta ayarları, ödeme kimlikleri tek bir dosyada toplanmalı ki kopyaladığında sadece o dosyayı değiştirsin.
Dördüncü katman en çok atlanan: dış dünya katmanı. Test ortamın gerçek müşteriye e-posta göndermemeli, gerçek SMS atmamalı, gerçek tedarikçiden stok düşmemeli. Bunun için bir "kuru mod" anahtarı koy: açıkken tüm dış çağrılar yazılır ama gönderilmez. Pinova gibi yönetim yazılımlarında bu anahtarı yapılandırmadan açıp kapatabilmen, test ile canlı arasındaki en önemli güvenlik kilidi.
| Katman | Canlı | Test ortamı | Atlanırsa olan |
|---|---|---|---|
| Alan adı | magaza.com | test.magaza.com | Google test sayfalarını indeksler |
| Veritabanı | db_canli | db_test | Sahte siparişler ciroya karışır |
| Tedarikçi API | Gerçek uç nokta | Sandbox + mock | Test siparişi gerçek stok yakar |
| Ödeme | Canlı anahtar | Test anahtarı | Kartından gerçek çekim |
| E-posta / SMS | Gerçek SMTP | Log dosyası | Müşteriye sahte kod gider |
| Arama motoru | index | noindex + şifre | Fiyat testleri sızar |
Tedarikçi API'sini nasıl taklit edersin?
En güçlü hamle, tedarikçiyi beklemeyi bırakıp onu taklit etmek. Kendi sunucunda küçük bir taklit uç nokta yaz: gelen isteği kaydeden, sonra senin belirlediğin cevabı dönen tek dosya yeterli. Bir parametreyle davranışını değiştirebilsin; başarı, stok yok, bakiye yetersiz, yavaş cevap, bozuk JSON, HTML hata sayfası.
Bu taklit katmanı sayesinde tedarikçinin sandbox'ının kapalı olduğu bir pazar günü bile entegrasyon geliştirmeye devam edebilirsin. Daha önemlisi, tekrarlanabilir hata üretebilirsin: "tedarikçi üç kez üst üste zaman aşımına düşerse sipariş hangi duruma geçiyor" sorusunu on saniyede test edip cevabı görebilirsin. Dijital ürün satış yazılımı tarafında sipariş durum makinesinin doğru kurulduğunu ancak böyle kanıtlarsın.
Test ortamında yakalanan arızaların dağılımı
- Tedarikçi cevap ayrıştırma 42%
- Ödeme bildirimi / çift kayıt 26%
- Teslimat e-postası ve şablon 20%
- Yetki ve panel hataları 12%
Ödeme sağlayıcısının test modunda görmediğin şey ne?
Ödeme testleri genelde "kart girdim, onay geldi" noktasında biter. Oysa e-pin işinde kritik olan kısım onaydan sonrasıdır: bildirimin sunucuna kaç kez geldiği, hangi sırayla geldiği ve senin buna nasıl davrandığın. Aynı bildirim iki kez gelirse müşteriye iki kod göndermemen gerekir; bu yüzden sipariş numarası üzerinde tek kullanımlık kilit şart.
Test ortamında bunu ölçmenin yolu, bildirimi elle tekrar göndermektir. Kaydettiğin bildirim gövdesini aynı adrese üç kez gönder ve veritabanında tek teslimat kaydı oluştuğunu doğrula. Ayrıca imzası bozuk bir bildirim gönder ve reddedildiğini gör. Bu iki test, ileride yaşayacağın en pahalı iki olayı, yani çift teslimat ve sahte onay girişimini, bir akşamda kapatır.
Test ortamında oluşan her siparişin numarasına sabit bir ön ek ver. İki ortam yanlışlıkla aynı veritabanına bakarsa tek bakışta ayırt edebilirsin; muhasebe raporlarında da filtrelemek kolaylaşır.
Canlıya geçiş gecesini nasıl provaya çevirirsin?
Geçiş gecesi doğaçlama yapılacak bir gece değil. Test ortamında yaptığın son işlem, canlıya geçişin birebir provası olmalı: anahtarları değiştir, önbelleği temizle, bir kuruşluk gerçek sipariş ver, teslimatı gör, iade et. Bu zinciri test ortamında yazılı adımlarla bir kez yürürsen canlıda sadece tekrar etmiş olursun.
Geri dönüş planını da aynı gece hazırla. Hangi dosyanın yedeği nerede, veritabanı yedeği kaç dakika önce alındı, sorun çıkarsa bakıma alma sayfasını nasıl açacaksın? Bir e-pin yazılımı kurulumunda felaket, hatanın kendisi değil; hatayı geri alamamaktır. Sonraki entegrasyonların için de bu ortamı silme, güncellemeleri hep önce orada dene.
| Kontrol | Nasıl test edilir | Beklenen sonuç | Durum |
|---|---|---|---|
| Tedarikçi zaman aşımı | Mock 20 sn beklesin | Sipariş "beklemede", müşteriye hata yok | Zorunlu |
| Stok bitişi | Mock stok-yok cevabı | Otomatik iade veya elle teslim kuyruğu | Zorunlu |
| Çift bildirim | Aynı gövdeyi 3 kez gönder | Tek teslimat kaydı | Zorunlu |
| Bozuk imza | İmzayı değiştir | 401 ve log kaydı | Zorunlu |
| E-posta şablonu | Kuru modda log oku | Kod maskesiz, marka doğru | Önerilir |
| Yüklenme yükü | 50 eşzamanlı sipariş | Kuyruk bozulmaz, kod tekrarlamaz | Önerilir |
| Geri dönüş | Yedekten geri yükle | 15 dakikada eski hale dönüş | Zorunlu |
Test ortamı kurmayı zahmet olmaktan çıkar
Pinova, aynı lisansla ayrı bir test kurulumu, kuru mod anahtarı ve tedarikçi cevaplarını kaydeden ayrıntılı log ekranıyla gelir. Entegrasyonu canlıda değil, provada dene.
Test ortamı için ayrı bir lisans almam gerekir mi?
Hayır. Ciddi sağlayıcılar aynı lisansla bir geliştirme/test kurulumuna izin verir. Satın alma öncesi bunu net biçimde sor; fiyat sayfasındaki koşullarda bu maddenin yer alması iyi bir işarettir.
Test ortamı canlı sunucuda mı olmalı, yoksa bilgisayarımda mı?
İkisi de olur. Bilgisayarında daha hızlı çalışırsın; ancak ödeme bildirimleri ve tedarikçi geri çağrıları dışarıdan erişilebilir bir adres istediği için bir alt alan adında şifreli bir test kurulumu çoğu satıcı için daha pratiktir.
Tedarikçim sandbox vermiyor, ne yapmalıyım?
Kendi mock uç noktanı yaz. Gerçek bir siparişin isteği ile cevabını bir kez kaydet, sonra o cevabı taklit et. Bu yöntemle sandbox'ı olmayan tedarikçilerle de güvenle çalışabilirsin.
Test ortamı Google'a düşer mi?
Önlem almazsan düşer. Alt alan adına şifre koy, noindex başlığı gönder ve site haritası üretimini kapat. Aksi hâlde test fiyatların ve deneme ürünlerin arama sonuçlarında görünebilir.
Test ortamı kurmak, işini büyütürken kendine tanıdığın en ucuz sigorta. Katmanları ayırdığın, tedarikçiyi taklit ettiğin ve geri dönüş planını yazdığın gün entegrasyon artık heyecan verici bir kumar değil, sıkıcı bir kontrol listesi olur; zaten olması gereken de bu. Bu düzenin hazır geldiği bir kurulumu kendi gözünle görmek istersen canlı demo üzerinden sipariş akışını ve log ekranlarını inceleyebilir, sonra özellikler listesinden kendi senaryolarına karşılık gelen başlıkları işaretleyebilirsin.