Sanal POS başvurusu, yalnızca ödeme formuna kart alanları eklemek değildir. İşletme bilgileri, ürün veya hizmet modeli, internet sitesinin hazırlığı, sağlayıcı koşulları ve teknik entegrasyon birlikte değerlendirilir. Başvuru onayı sağlayıcının incelemesine bağlıdır; bütün işletmeler için aynı evrak, süre veya komisyon geçerli değildir.
Bu rehber başvuru öncesi hazırlığı, teklif karşılaştırmasını ve ödeme akışının testini düzenlemek için hazırlanmıştır. Vergi ve tüketici işlemlerine ilişkin kararlar işletmenin özel durumuna göre güncel resmi kaynaklar ve ilgili uzmanlarla değerlendirilmelidir. Amaç tek bir sağlayıcı önermek değil, neyi sormanız ve neyi doğrulamanız gerektiğini görünür hale getirmektir.
1. Ödeme ihtiyacınızı tarif edin
Hangi ürün veya hizmet için ödeme alacağınızı yazın. Tek seferlik satış, abonelik, ön ödeme veya farklı tahsilat biçimleri aynı ihtiyaç değildir. Para birimi, hedef müşteri ülkesi, ortalama işlem tutarı ve beklenen hacim gibi bilgiler sağlayıcı görüşmesinde gerekli olabilir. Tahminler gerçekçi varsayımlarla hazırlanmalıdır.
Ödeme akışının nerede başlayacağı da belirlenir. E-ticaret sepeti, ödeme bağlantısı veya özel başvuru süreci farklı teknik kapsamlar oluşturur. İş modelinizin sağlayıcı tarafından desteklenip desteklenmediği baştan sorulur. Sonradan ortaya çıkan uyumsuzluk, tasarım ve geliştirme işinin yeniden yapılmasına yol açabilir.
2. Banka ve ödeme hizmeti seçeneklerini karşılaştırın
Doğrudan banka çözümü ile ödeme hizmeti sağlayıcısı farklı ticari ve operasyonel koşullar sunabilir. Tek bir etiket üzerinden hangisinin daha iyi olduğuna karar verilmez. Kart kapsamı, taksit, ödeme aktarımı, destek, iade ve teknik uyum birlikte incelenir. Sağlayıcının yetki durumu güncel resmi kayıtlardan doğrulanmalıdır.
Özellikle ödeme kuruluşu veya elektronik para kuruluşuyla çalışırken TCMB'nin ödeme hizmetleri ve kuruluş listeleri esas alınabilir. Bir markanın tanınmış olması bütün hizmetlerinin aynı kapsamda yetkili olduğunu varsaymak için yeterli değildir. Sözleşmede hizmeti hangi tüzel kişinin verdiği ve hangi ürünün alındığı anlaşılmalıdır.
3. Komisyonun ötesindeki koşulları okuyun
Teklifteki tek oran toplam maliyeti açıklamayabilir. Taksit, farklı kart türleri, iade, işlem bedeli, sabit ücret veya ödeme aktarım düzeni gibi kalemler bulunabilir. Sağlayıcının sunduğu koşullar yazılı alınır. Sözlü verilen bilgiyle sözleşme arasında fark varsa açıklama istenir.
Karşılaştırma aynı varsayımsal işlem dağılımı üzerinden yapılabilir. Tek çekim ve taksitli satış oranları farklıysa yalnızca en düşük oranı karşılaştırmak yanıltır. Ödeme aktarım zamanının işletmenin nakit akışına etkisi de düşünülür. Burada kesin maliyet hesabı için sağlayıcının güncel tarifesi ve işletmenin gerçek işlem yapısı gerekir.
4. Başvuru belgelerini sağlayıcının listesine göre hazırlayın
İşletme türü ve hizmete göre istenen belgeler değişebilir. Vergi, yetki, kimlik, banka ve şirket bilgileri gibi alanlar başvuru sürecinde talep edilebilir. İnternetteki eski bir evrak listesini bütün sağlayıcılar için geçerli saymayın. Güncel liste doğrudan sağlayıcıdan alınmalıdır.
Belgelerdeki unvan, adres ve hesap bilgileri arasında tutarlılık kontrol edilir. Eksik veya farklı yazılmış bilgiler incelemeyi uzatabilir. Belgelerin güvenli kanaldan iletilmesi gerekir. Başvuru dosyasının kim tarafından takip edildiği belirlenir; ek bilgi talepleri dağınık e-postalar içinde kaybolmamalıdır.
5. Sitenin temel bilgilerini tamamlayın
İşletme kimliği, iletişim yolu, ürün veya hizmet açıklaması ve işlem koşulları açık olmalıdır. Boş ürün sayfaları, çalışmayan menüler ve örnek metinler başvurunun hazırlık düzeyini zayıflatır. Kullanıcının ne satın aldığını ve satıcıyla nasıl iletişim kuracağını anlayabilmesi gerekir.
Fiyat ve teslim bilgileri gerçek uygulamayla tutarlı tutulur. İade veya iptal süreci yalnızca bir bağlantı olarak değil, anlaşılır bilgi olarak sunulur. Hukuki metinler başka bir işletmeden kopyalanmamalıdır. Mesafeli satış sözleşmesi ve ön bilgilendirme işletmenin işlem modeline göre hazırlanır.
6. ETBİS ve e-belge süreçlerini ayrıca değerlendirin
Elektronik ticaret faaliyetinizin kayıt ve bildirim gereklilikleri güncel resmi açıklamalardan kontrol edilir. ETBİS resmi sitesi ve ilgili sık sorulan sorular başlangıç kaynağıdır. Eski kurulum listelerindeki karekod adımı güncel kabul edilmemelidir; ETBİS karekod uygulamasının sonlandırıldığı resmi olarak duyurulmuştur.
Fatura süreci ödeme entegrasyonundan ayrı ama bağlantılıdır. Başarılı siparişin ne zaman belgeye dönüşeceği, iptal ve iadenin nasıl ele alınacağı belirlenir. GİB e-Belge kaynakları ve mali müşavirinizle işletmenin koşulları değerlendirilir. E-Arşiv Fatura ile E-Fatura aynı uygulama gibi ele alınmamalıdır.
7. Teknik entegrasyon yöntemini seçin
Sağlayıcının sunduğu yönlendirmeli ödeme sayfası, hazır modül veya API gibi yöntemler incelenir. Seçim sitenin altyapısı ve bakım kapasitesiyle uyumlu olmalıdır. Hazır modül kullanmak test ihtiyacını ortadan kaldırmaz. Sürüm uyumu, güncelleme desteği ve hata davranışı kontrol edilir.
Ödeme verisinin hangi sistemden geçtiği anlaşılmalıdır. İşletmenin ihtiyaç duymadığı kart bilgilerini kendi uygulamasında saklamaması tercih edilir. Güvenlik gereksinimleri kullanılan entegrasyon modeline göre sağlayıcıyla netleştirilir. Görsel olarak siteye daha çok benzediği için daha karmaşık bir yöntem seçmek her zaman gerekli değildir.
8. Sipariş ve ödeme durumlarını ayrı modelleyin
Sipariş oluşturulması, ödemenin tamamlanması ve ürünün gönderilmesi farklı durumlardır. Kullanıcı ödeme ekranına geçtiğinde sipariş otomatik olarak ödenmiş sayılmamalıdır. Başarısız veya yarım kalan işlem için uygun durum tutulur. Böylece stok ve fatura süreçleri yanlış tetiklenmez.
Ödeme sonucunun sağlayıcıdan güvenilir biçimde doğrulanması gerekir. Tarayıcı dönüş adresine gelmek tek başına yeterli değildir. Sunucu bildirimleri ve doğrulama yöntemi sağlayıcının güncel dokümanına göre uygulanır. Aynı bildirim tekrar geldiğinde aynı sipariş yeniden işlenmemelidir. Bu davranış teslim testinin parçası olmalıdır.
9. 3D Secure akışını doğru anlayın
3D Secure kart sahibi doğrulamasıyla ilgilidir. Her işlemde aynı ekran veya SMS deneyimi beklenmemelidir. Doğrulama ile ödemenin finansal sonucu farklı aşamalardır. Entegrasyon, sağlayıcının döndürdüğü durumları doğru yorumlamalıdır.
Kullanıcı doğrulama sırasında vazgeçerse, zaman aşımı olursa veya banka işlemi onaylamazsa ne gösterileceği hazırlanır. Hata mesajı anlaşılır olmalı, hassas teknik ayrıntıları kullanıcıya taşımamalıdır. Kullanıcı yeniden denediğinde çift sipariş veya yanlış tahsilat görünümü oluşmaması kontrol edilir.
10. Test ortamında senaryoları tamamlayın
Başarılı ödeme dışında başarısız işlem, iptal, zaman aşımı ve tekrarlanan bildirim denenir. Tutar, para birimi ve sipariş kimliği kontrol edilir. Farklı ürün kombinasyonları ve indirimler varsa toplamın doğru hesaplandığı doğrulanır. Kargo ücretinin ödeme tutarıyla aynı olması gerekir.
Test erişimleri ve canlı erişimler ayrı tutulur. Test siparişleri gerçek satış raporuna karışmamalıdır. Sonuçlar kısa bir tabloda kaydedilebilir: senaryo, beklenen durum, gerçekleşen durum ve düzeltme. Sadece “ödeme başarılı” ekranını görmek bütün entegrasyonun tamamlandığı anlamına gelmez.
11. İade ve kısmi iade akışını deneyin
Satış kadar satış sonrası işlem de önemlidir. Sağlayıcının desteklediği iade yöntemleri ve süreleri sözleşmeden öğrenilir. Tam ve varsa kısmi iade senaryoları uygulamanın sipariş kaydıyla eşleştirilir. İade talebinin gönderilmesi ile sonucun tamamlanması farklı durumlar olabilir.
Müşteri hizmetleri ekibinin hangi ekrandan ne yapacağı belirlenir. Yanlışlıkla aynı iadenin tekrar başlatılması önlenir. Fatura ve stok süreçlerinin nasıl güncelleneceği ayrıca planlanır. Sepet terk oranı satış öncesi davranışı gösterirken iade oranı satış sonrası kalite hakkında farklı bilgi verir.
12. Mobil ödeme deneyimini kontrol edin
Gerçek bir telefonda ürün seçimi, adres girişi ve ödeme tamamlanır. Klavye açıldığında alanların görünmesi, hata mesajlarının anlaşılması ve geri dönüşlerin çalışması kontrol edilir. Dış ödeme ekranından siteye dönüldüğünde doğru sipariş durumu gösterilmelidir.
Kullanıcı ağ bağlantısını kaybederse veya sekmeyi kapatırsa işletmenin kaydı doğru kalmalıdır. Arayüzde “bekleniyor” durumu gerekebilir; kesinleşmemiş işleme başarı mesajı verilmemelidir. Responsive tasarım ödeme akışında gerçek görev testiyle doğrulanır.
13. Canlı geçişi kontrollü yapın
Canlı erişimler, alan adı ve bildirim adresleri kontrol edilir. Test ayarlarının üretimde kalmadığı doğrulanır. Uygun küçük bir canlı işlem, sağlayıcının izin verdiği test yaklaşımıyla denenebilir. İşlem kaydı, tahsilat ve varsa iade sonucu karşılaştırılır.
Geçiş sırasında sorumlu teknik kişi ve işletme yetkilisi ulaşılabilir olmalıdır. Hata halinde ödeme akışının nasıl durdurulacağı veya önceki sürüme nasıl dönüleceği bilinmelidir. Ödeme kabulü başladıktan sonra ilk işlemler yakından izlenir. Günlük operasyon kontrolü için kısa bir sorumluluk listesi hazırlanır.
14. Mutabakat ve raporlamayı kurun
Site siparişleri, sağlayıcı işlem kayıtları ve banka aktarımı aynı kapsamla karşılaştırılır. Komisyon, iade ve diğer kesintiler açıklanabilir olmalıdır. Bir fark görüldüğünde hangi işlem kimliğiyle araştırılacağı belli olur. Sadece paneldeki toplam satış tutarına bakmak yeterli değildir.
Ortalama sipariş değeri ve reklam gelir raporları hesaplanırken hangi tutarın kullanıldığı belirtilir. Kargo, vergi ve iade tanımları tutarlı tutulur. ROAS kar değildir; ödeme maliyetleri ve ürün giderleri ayrıca değerlendirilir. Ölçüm planı dönüşüm takibi rehberinde açıklanır.
15. Başvuru olumsuz sonuçlanırsa
Sağlayıcının bildirdiği gerekçe öğrenilir. Eksik belge, site hazırlığı veya iş modeline ilişkin koşullar farklı çözüm gerektirir. Aynı başvuruyu değişiklik yapmadan tekrar göndermek yerine somut eksik ele alınır. Onay kararının sağlayıcıya ait olduğu unutulmamalıdır.
Farklı sağlayıcı değerlendirilirken yalnızca onay ihtimaline odaklanılmaz. Sözleşme, destek, teknik kapsam ve maliyet yine incelenir. İş modelini yanlış tanıtarak başvuru yapmak ileride daha büyük operasyon sorunları doğurabilir. Gerçek faaliyet ve ürünler açık biçimde anlatılmalıdır.
Karşılaştırma toplantısında sorulacak sorular
- İş modelimiz ve ürün grubumuz destekleniyor mu?
- Komisyon dışında hangi ücret ve koşullar var?
- Ödemeler hangi düzenle aktarılıyor?
- İade ve uyuşmazlık süreçlerinde sorumluluklar neler?
- Altyapımız için hangi entegrasyon yöntemi öneriliyor?
- Test ve canlı ortam erişimleri nasıl veriliyor?
- Teknik sorunlarda hangi destek kanalını kullanacağız?
- Sözleşme sona erdiğinde kayıt ve erişimler nasıl yönetilecek?
Yanıtlar tarih ve teklif sürümüyle saklanabilir. Böylece başvuru sırasında konuşulan koşullar uygulama aşamasında karşılaştırılır. Sağlayıcı şartları değiştiğinde işletmenin hangi alanları yeniden değerlendirmesi gerektiği görülür. Sözlü varsayımlar yerine yazılı ve anlaşılır bilgilerle karar vermek süreci daha yönetilebilir hale getirir.