Test Ortamı (Sandbox) Kullanımı: Sanal POS Entegrasyonunu Test Etme

Sanal POS entegrasyonunda teknik gereksinimleri doğru şekilde karşıladığınızı görmek ve canlı ortama sorunsuz geçmek için önce güvenli test ortamı kullanılır. Sandbox olarak da adlandırılan bu ortam, gerçek ödeme akışını taklit ederken herhangi bir finansal risk oluşturmaz; böylece hem altyapınızı doğrular hem de olası hataları canlı sistem etkilenmeden yakalarsınız. Test kartlarıyla yapılan tüm işlemler size entegrasyonunuzun nasıl davrandığını gösterir, ödeme sürecinin her adımını güvenle sınamanızı sağlar. Sandbox kullanımı, başarılı sanal POS entegrasyonunun olmazsa olmaz adımlarından biridir.

Sanal POS Test Ortamı (Sandbox) Nedir? 

Sanal POS test ortamı, banka ya da ödeme sağlayıcısının, gerçek ödeme akışını simüle eden ancak gerçek para hareketi yaratmayan özel sistemidir. Entegrasyonunuzu canlı kullanıma açmadan önce tüm ödeme senaryolarını adım adım denenir, sisteminizin doğru yanıt verip vermediğini kontrol edilir. Başarılı/başarısız işlem, provizyon, iptal, iade gibi tüm kritik adımların nasıl çalıştığını görebilirsiniz.

Sandbox işletmelere risk almadan test yapma özgürlüğü verir. Böylece canlı ortamdaki olası hataları önceden yakalayabilir, ödeme akışınızın sorunsuz çalışacağından emin olabilirsiniz. Böylelikle hem teknik ekip hem de operasyon tarafı, entegrasyonun tüm detaylarını güvenle doğrular.

Türkiye’deki Popüler Sanal POS Sağlayıcılarının Test Ortamları Nasıl Kullanılır? 

Türkiye’de hizmet veren çoğu sanal POS sağlayıcısı, geliştirme sürecinizi hızlandırmanız adına kapsamlı sandbox ortamı sunar. Test ortamları sağlayıcıya göre değişse de genel prensip aynıdır: Önce test hesabı oluşturur, ardından API anahtarlarınızı alır, işlemleri test kartlarıyla simüle ederek entegrasyonunuzu doğrularsınız.

Sanal POS Test Ortamında Hangi Test Senaryoları Uygulanmalıdır?

Sanal POS entegrasyonunun sağlıklı şekilde çalışıp çalışmadığını görmek için ödeme akışının her adımını test ortamında doğrulamak gerekir. Taksitli ödeme ve iade süreçlerinin doğru işlemesi, canlı ortamdaki kullanıcı deneyiminin sorunsuz olmasını sağlar.

Başarılı Ödeme Testleri

Başarılı ödeme senaryoları, ödeme akışının iskeletini oluşturur. Test kartlarıyla yapılan bir ödeme isteğinin doğru şekilde işlenmesi, provizyonun alınması, sipariş kaydının sorunsuz oluşturulması bu aşamada kontrol edilir. Başarılı işlemin ardından hem kullanıcı tarafındaki doğrulama mesajlarının hem de backend tarafındaki log kayıtlarının tutarlı şekilde ilerlemesi beklenir.

Başarısız Ödeme Testleri

Gerçek kullanıcıların sık yaşayabileceği hataların doğru simüle edilmesi kritik önem taşır. Limit yetersizliği, yanlış kart bilgisi, son kullanma tarihi hatası, CVV doğrulama hatası ve 3D doğrulama başarısızlığı gibi çeşitli durumlarda sistemin doğru hata kodlarını döndürmesi gerekir. Testlerde asıl amaç, ödeme sağlayıcısının ürettiği hata senaryolarının uygulama tarafından doğru yakalanmasıdır. Oluşturulan başarısız işlem kaydı incelenir.

3D Secure Testleri

3D Secure akışı, güvenlik gereksinimleri açısından en önemli adımlardan biridir. Tarayıcının 3D doğrulama ekranına sorunsuz yönlenmesi, sağlayıcı tarafından dönen “başarılı / başarısız” sonucun doğru işlenmesi beklenir. Ek olarak geri dönüş URL’si, callback (bildirim) endpoint’leri senaryoları da bu aşamada kontrol edilir. 3D sürecinin herhangi bir adımında yaşanacak uyumsuzluk, canlı ortamda ödeme kayıplarına neden olabileceğinden kapsamlı bir test yapılması zorunludur.

Taksitli Ödeme Testleri

Türkiye pazarında taksitli ödeme neredeyse standart hâline geldiği için tüm taksit seçeneklerinin doğru çalıştığından emin olmak gerekir. Banka veya ödeme sağlayıcısının sunduğu taksit planlarının sisteme doğru yansıması, seçilen taksit sayısına göre provizyon tutarının ve komisyonun doğru hesaplanması kritik noktalardır. Bazı sağlayıcılar her taksit sayısı için özel hata senaryoları sunar; dolayısıyla farklı taksit kombinasyonlarının API tarafından nasıl yanıtlandığı da test edilmelidir.

İptal ve İade Testleri

Ödeme akışında işlem sonrası süreçler de en az ödeme kadar önem taşır. Provizyon aşamasında yapılan iptallerde işlemin bankaya düşmeden durdurulması, tamamlanan işlemlerde ise tam veya kısmi iadenin doğru şekilde işlenmesi gerekir. İade talebinin API üzerinden iletilmesi, sağlayıcının yanıt döndürmesi, iade durumunun sipariş sisteminde güncellenmesi gibi birçok adım test edilir. İade süreçlerinin hatalı çalışması, muhasebe tarafında ciddi sorunlar yaratabileceği için kapsamlı doğrulama yapılır.

Test Kartları ve Test Verileri Nasıl Kullanılır?

Sanal POS test ortamında ödeme akışını doğru şekilde simüle edebilmek için sağlayıcıların sunduğu test kartlarını ve test verilerini kullanmak gerekir. Gerçek kartlarla işlem yapmadan tüm senaryoları denemenize olanak tanır, ödeme sürecinizin gerçek ortama hazır olup olmadığını anlamanızı sağlar.

Genel Test Kartları

Birçok ödeme sağlayıcısı, tüm temel senaryoları denemenizi sağlayan genel test kartları sunar. Kartlar çoğunlukla her sağlayıcı için aynı formatta olur; başarılı ödeme, başarısız ödeme, 3D onayı veya reddi gibi durumları simüle etmek için kullanılır. Genel test kartları, entegrasyonun temel akışını hızlıca doğrulamak için en ideal başlangıç noktasıdır.

Banka Özel Test Kartları

Bazı bankalar, kendi sistemlerinin davranışını daha gerçekçi simüle etmek için özel test kartları sağlar. Bu kartlar sayesinde belirli bankalara özgü taksit seçenekleri test edilebilir. Banka özel test kartları çoklu POS entegrasyonlarında hata ayıklamayı kolaylaştırır, canlı ortamda ortaya çıkabilecek banka bazlı farklılıkları önceden görmenizi sağlar.

Test CVV ve Son Kullanma Tarihleri

Test ortamında kullanılan CVV ve son kullanma tarihleri standarttır, sağlayıcı tarafından belirlenmiş sabit değerler içerir. Bilgiler gerçek doğrulamalara tabi olmadığı için sisteminizin kart doğrulama adımlarını test ederken her işlem kombinasyonu rahatlıkla denenebilir. Ayrıca bazı sağlayıcılar, farklı hataları tetiklemek için özel CVV veya tarih değerleri sunar; veriler sayesinde hata senaryoları da detaylı şekilde test edilebilir.

Test Müşteri Bilgileri

Test ortamlarında kullanılan müşteri bilgileri gerçek kullanıcı verilerinden tamamen bağımsızdır. Örnek isim, adres, telefon veya e-posta kalıplarından oluşur. Sipariş oluşturma, fatura bilgisi işleme ve doğrulama adımlarını test ederken gereklidir. Aynı zamanda veri tabanında müşteri bilgisi işleyen sistemlerin tutarlı çalıştığını görmek için de kullanılır. Böylece canlı ortamda yaşanabilecek eksik ya da hatalı bilgi sorunları daha test aşamasında tespit edilebilir.

Sanal POS Entegrasyonu İçin Gerekli API Anahtarları Nasıl Alınır ve Yapılandırılır? 

Sanal POS entegrasyonunun sağlıklı çalışması için doğru API anahtarlarını alıp sisteminize doğru şekilde tanımlamalısınız. Test ortamında kullanılan anahtarlar ile canlı ortam anahtarları birbirinden farklıdır, her biri doğru yapılandırılmadığında ödeme akışı beklenmedik şekilde kesintiye uğrayabilir.

Sandbox API Anahtarları

Test ortamında işlem yapabilmek için sağlayıcının sunduğu sandbox API anahtarları kullanılır. Anahtarlar gerçek ödeme akışını simüle ederken hiçbir finansal risk oluşturmadan entegrasyonun doğrulanmasını sağlar. Panel üzerinden “Test” veya “Sandbox” sekmesi altında oluşturulabilir. Test anahtarlarının doğru tanımlanması, ödeme, iade, hata gibi tüm senaryoların gerçekçi şekilde çalışmasını mümkün kılar.

API Güvenlik Anahtarları

API güvenlik anahtarları, sağlayıcı ile sisteminiz arasındaki iletişimin doğruluğunu garanti eden imza, secret key veya token gibi özel anahtarlardır. Kötü niyetli erişimleri engellemek ve işlem bütünlüğünü korumak için kullanılır. Her sağlayıcının doğrulama yöntemi farklı olabilir; doğru şifreleme algoritmasının, doğru endpoint’lerin kullanılması entegrasyonun güvenliği açısından büyük önem taşır.

Callback URL Yapılandırması

Callback URL, işlem tamamlandığında sağlayıcının sisteminize gönderdiği son işlem bilgisinin iletildiği adrestir. URL doğru tanımlanmadığında sipariş durumları güncellenmez, ödeme başarılı olsa bile sisteminiz “beklemede” olarak kalabilir. Test ortamında callback URL’nin doğru yanıt verdiğinin, gerekli doğrulama adımlarını çalıştırdığının mutlaka doğrulanması gerekir. Canlıya geçerken test URL’sinin canlı URL ile değiştirilmesi kritik bir adımdır.

Webhook Ayarları

Webhook’lar, sağlayıcının ödeme sürecine ait değişiklikleri anlık olarak sisteminize ilettiği otomatik bildirim mekanizmalarıdır. Ödeme başarı durumu, iade işlemleri, fraud kontrolleri veya gecikmeli onaylar gibi bilgiler webhook üzerinden aktarılabilir. Yani webhook URL’lerinin doğrulanması, güvenlik imzasının (signature validation) yapılması entegrasyonun vazgeçilmez bir parçasıdır. Canlı ortamda ise güvenlik için IP doğrulaması veya ek imza kontrolü yapılması önerilir.

Sanal POS Test Ortamında Sık Karşılaşılan Sorunlar ve Çözümleri Nelerdir?

Sanal POS test ortamı, canlıya geçmeden önce tüm hataların ortaya çıkmasını sağlayan en güvenli aşamadır; test ederken bazı yaygın sorunlarla karşılaşmak oldukça normaldir. Sorunların büyük kısmı API yapılandırmasından kaynaklanır. Aşağıdaki maddelerde test sürecinde en sık görülen problemlerin pratik çözümlerini bulabilirsiniz:

• API Anahtarlarının Hatalı Kullanılması: Test anahtarları yerine canlı anahtarların kullanılması, hatalı endpoint tanımları veya eksik güvenlik anahtarları entegrasyonun çalışmamasına neden olur. Panelden alınan anahtarların doğru ortam (test/canlı) için düzenlenip düzenlenmediği kontrol edilmeli, API endpoint adreslerinin doğru olduğundan emin olunmalıdır.
• 3D Secure Yönlendirme Sorunları: 3D ekranının açılmaması, yönlendirme döngüsüne girme veya doğrulama sonucunun geri dönmemesi sık görülen problemlerdir. 3D dönüş URL’si (returnUrl) ve callback URL’lerinin doğru tanımlandığı, URL’lerin HTTPS kullandığını kontrol etmelisiniz.
• Callback/Webhook Bildirimlerinin Gelmemesi: Ödeme başarıyla tamamlansa bile sistemde sipariş “beklemede” kalabilir; sebebi callback veya webhook’un doğru şekilde tetiklenmemesidir. Callback URL’nin dışarıdan erişilebilir olması, doğru HTTP yanıtı döndürmesi gerekir. Loglama bu aşamada kritik önem taşır.
• Test Kartlarıyla İşlemin Başarısız Olması: Bazı sağlayıcılar farklı test kartlarıyla farklı hata kodları döndürür; yanlış kart kullanımı işlemin beklenmedik şekilde reddedilmesine neden olur. Sağlayıcının sunduğu güncel test kartı listesinden seçim yapmaya özen göstermelisiniz.
• Zaman Aşımı (Timeout) Hataları: API yanıtının geç gelmesi veya sistemin belirli bir süre sonunda isteği kesmesi, özellikle yüksek yük testlerinde sık görülür. Timeout sürelerinin sağlayıcı önerilerine göre ayarlanması, gereksiz uzun işlemlerin arka planda yönetilmesi zorunludur.
• JSON Veri Formatı Hataları: Gönderilen isteklerin JSON formatında eksik parametre, yanlış veri tipi veya hatalı imza gibi problemler içermesi işlem reddiyle sonuçlanır. Sağlayıcının API dokümantasyonu birebir takip edilmeli, zorunlu alanlar her istekte kontrol edilmeli, imza algoritmalarında boşluk/hata bırakılmamalıdır.
• Test Ortamı ile Canlı Ortam Farkları: Her iki ortam arasında küçük farklar olabilir; özellikle banka POS’larında test ortamı, canlı davranışın birebir aynısı olmayabilir. Sağlayıcı dokümantasyonundaki “test-canlı farkları” bölümü kontrol edilmeli; canlıya geçişte tüm anahtarlar güncellenmelidir.

Test Ortamından Canlı Ortama Nasıl Geçilir?

Sandbox ortamında tüm test senaryoları başarıyla tamamlandıktan sonra canlı ortama geçiş süreci başlar. Hem API anahtarlarının hem de URL yapılandırmalarının doğru şekilde değiştirilmesi, canlı ortamda beklenmedik hataların önüne geçer. Geçiş sırasında dikkat edilmesi gereken başlıca noktalar şöyle özetlenebilir:

• Canlı ortama geçerken ilk adım test anahtarlarını bırakıp, panelden alınan canlı API anahtarlarını tanımlamaktır. Canlı ortamda kullanılan imza (signature), secret key veya token değerleri her zaman sandbox ortamından farklıdır; bu nedenle tüm anahtarların eksiksiz güncellendiğinden emin olmak gerekir.
• Test sürecinde kullanılan URL’ler canlı endpoint’lerle birebir değiştirilmelidir. Tek URL’nin bile test ortamında kalması, işlemlerin başarısız olmasına neden olabilir.
• Test ortamında kullanılan callback ve webhook adresleri genellikle geçici URL’lerdir. Canlıya geçişte dışarıdan erişilebilir URL’lerin tanımlanması gerekir. Ek olarak canlı ortamda imza doğrulaması mutlaka aktif hâle getirilmelidir.
• Bazı sağlayıcılar canlı ortamda ek güvenlik kontrolleri ister. IP doğrulama, JWT imzası, HTTPS zorunluluğu veya rate limit değerleri bu aşamada devreye girer. Kontrollerin doğru yapılandırılması, operasyon güvenliği için önemlidir.
• URL’ler tanımlandıktan sonra düşük tutarlı test işlemi yapılması önerilir. Ödeme akışının canlı ortamda doğru çalıştığını doğrulamak için son adımdır. Başarılı işlem, callback bildirimi, sipariş güncellemeleri ve log kayıtları tek tek kontrol edilmelidir.
• Canlı ortamda oluşabilecek hataları hızlıca yakalamak için loglama, hata bildirimleri ve izleme (monitoring) mekanizmalarının açık olması gerekir. İlk günlerde olası sorunların hızla çözülebilmesini sağlar.

Farklı Programlama Dillerinde Sandbox Entegrasyonu Nasıl Yapılır? 

Farklı programlama dilleriyle sandbox entegrasyonu yapılırken temel mantık aynı kalır: sağlayıcının sunduğu test API anahtarları kullanılır, test endpoint’lerine istek gönderilir, dönen yanıtlar işlenir. PHP, Node.js, Python, Java veya .NET gibi dillerde yalnızca kullanılan HTTP kütüphaneleri değişir. Entegrasyonun işleyişi, parametre yapısı ve imza (signature) oluşturma mantığı tüm dillerde benzerdir. Bu nedenle sağlayıcının API dokümantasyonu, test kartları hangi dili kullanırsanız kullanın entegrasyonun temel rehberi olur.

FAQ 

Sanal POS test ortamında yapılan işlemler için ücret ödenir mi?

Hayır, test ortamında yapılan işlemler tamamen ücretsizdir. Ödeme sağlayıcıları, geliştirme sürecini kolaylaştırmak için tüm denemeleri sanal olarak simüle eder.

Test ortamında gerçek kredi kartı bilgileri kullanılabilir mi?

Kesinlikle kullanılmamalıdır. Test ortamı özel test kartları için tasarlanır; gerçek kart bilgileri hem güvenlik riski taşır hem de sistem tarafından kabul edilmez. 

3D Secure doğrulaması test ortamında nasıl simüle edilir? 

Bankaların sunduğu özel 3D Secure test akışları kullanılır. Genellikle başarı, hata veya kullanıcı iptali gibi senaryoları tetikleyen test kodları bulunur.

Sandbox ortamında yapılan işlemlerin raporlarına nasıl erişilir? 

Çoğu ödeme sağlayıcı, test panelinde raporlama bölümlerini de ayrı ayrı verir. Buradan test ödemeleri, hata kodları ve işlem detaylarını detaylarıyla birlikte görüntüleyebilirsiniz.

Test ortamında işlem limitleri var mıdır? 

Evet, bazı sağlayıcılar test ortamında maksimum tutar gibi sınırlar koyabilir. Limitler özünde geliştirme sürecini etkilemez, yalnızca güvenlik amaçlıdır.

Sandbox API anahtarları ile canlı ortamda işlem yapılabilir mi? 

Sandbox anahtarları yalnızca test işlemleri içindir, canlı ortam tarafından tanınmaz. Canlıya geçtiğinizde gerçek üretim (production) anahtarlarını almanız gerekir.

Test ortamında başarılı olan bir entegrasyon canlı ortamda da aynı şekilde çalışır mı?

Genellikle evet, çünkü test ortamı canlı sistemin birebir kopyası olacak şekilde tasarlanır. Ancak canlı ortamda ek güvenlik filtreleri, fraud kontrolleri veya banka onay adımları devreye girebilir.