Web sitenize kartla ödeme eklemek istediğinizde iki teklif arasında büyük fiyat farkı görebilirsiniz. Bir teklif yalnızca hazır modül kurulumunu, diğeri ödeme, sipariş, iade ve raporlama akışının geliştirilmesini kapsıyor olabilir. Doğru karşılaştırma için önce müşterinin ödemesinden işletmenizin siparişi işlemesine kadar tamamlanması gereken işleri belirleyin.

Bu rehber, sanal POS hizmeti seçerken ve entegrasyon teklifi alırken sorulacak teknik sorulara odaklanır. Belirli bir sağlayıcıyı en ucuz ilan etmek veya değişken komisyonları sabit fiyat gibi sunmak yerine, hangi ihtiyacın hangi geliştirmeyi gerektirdiğini açıklar.

Önce tahsilat modelinizi netleştirin

Tek ürün satışı, hizmet bedeli tahsilatı, üyelik ödemesi ve çok satıcılı pazaryeri aynı proje değildir. Tek seferlik ödemede sipariş ve işlem eşleştirmesi yeterli bir başlangıç olabilir. Abonelikte yenileme, başarısız tahsilat ve iptal durumları; pazaryerinde ise alt satıcı ve hak ediş akışları ayrıca değerlendirilir.

Teklif istemeden önce mevcut site altyapınızı, ödeme sağlayıcınızı, para birimini, taksit ihtiyacını ve iadenin hangi panelden yapılacağını yazın. Sağlayıcı başvurusu ile yazılım entegrasyonunu ayrı takip edin. Yazılımın hazır olması, sağlayıcının işyeri hesabını onayladığı anlamına gelmez.

Hazır ödeme formu mu, özel API mi?

Sağlayıcının hazır ödeme formu, ödeme arayüzünü yeniden geliştirme ihtiyacını azaltabilir. Buna rağmen sepet tutarının hazırlanması, sipariş kaydının açılması ve ödeme sonucunun doğrulanması sizin uygulamanızın sorumluluğundadır. Hazır form kullanımı tüm entegrasyon işini ortadan kaldırmaz.

Özel API entegrasyonu arayüz ve iş akışı üzerinde daha fazla kontrol sağlayabilir. Bunun karşılığında kart verisinin geçtiği bileşenler, güvenlik gereksinimleri ve bakım kapsamı daha dikkatli ele alınmalıdır. Yalnızca buton rengini değiştirmek için daha karmaşık bir mimari seçmek yerine, gerçekten gerekli özelleştirmeleri listeleyin.

Güvenilir bir ödeme akışı neleri kapsar?

  1. Ürün fiyatı, indirim ve toplam tutarı sunucuda hesaplayın.
  2. Ödeme girişimini benzersiz bir sipariş referansıyla kaydedin.
  3. Sağlayıcının ödeme akışını başlatın ve işlem kimliğini saklayın.
  4. Dönüş veya bildirim sonrasında sonucu sunucudan doğrulayın.
  5. İşlemi sipariş, tutar ve para birimiyle eşleştirerek durumu güncelleyin.
  6. İadeyi ayrı bir işlem olarak kaydedip sipariş durumuna yansıtın.

İmzalı bildirimleri sağlayıcının tarif ettiği yöntemle doğrulayın. Aynı bildirim yeniden geldiğinde ikinci sipariş, ikinci stok düşümü veya ikinci hizmet aktivasyonu oluşmamalıdır. Bağlantı kesildiğinde işlem sonucunu sorgulayabilen bir kontrol akışı, müşterinin ödediği halde siparişinin beklemede kalmasını yönetmeye yardımcı olur.

Maliyeti hangi kalemler belirler?

  • Mevcut altyapı: Güncel ve desteklenen modül ile eski özel yazılımın bağlantısı farklı emek gerektirir.
  • İş akışı: Tek seferlik ödeme, kısmi iade, abonelik ve pazaryeri ayrı kapsamlar doğurur.
  • Operasyon: Muhasebe bağlantısı, işlem raporu ve hata takip paneli ek geliştirme olabilir.
  • Bakım: Sağlayıcı güncellemeleri ve üretim hatalarının takibi için sorumluluk belirlenmelidir.

Toplam maliyeti entegrasyon geliştirmesi, sağlayıcının ticari ücretleri ve devam eden işletim giderleri olarak ayırın. Teklifte test ortamı, canlıya geçiş desteği ve teslim sonrası hata düzeltme koşullarının bulunmasını isteyin. E-ticaretin diğer giderleri için e-ticaret kurulum maliyeti rehberimizi inceleyebilirsiniz.

Entegrasyonu teslim alırken neyi kontrol etmelisiniz?

Başarılı ödeme, reddedilen kart, yarıda bırakılan işlem, geciken bildirim ve tekrar gelen bildirim senaryolarını test edin. Kısmi iade ihtiyacınız varsa bunu ayrıca deneyin. Kontrol listesine mobil ekranı, sipariş e-postasını, stok değişimini ve yönetim panelindeki durumu da ekleyin.

MASDEV, mevcut sitenize uygun ödeme bağlantısını sipariş ve operasyon süreçleriyle birlikte geliştirebilir. Teklif talebinizde site altyapınızı, sağlayıcınızı ve tahsilat modelinizi paylaşmanız kapsamı netleştirmeyi kolaylaştırır.