Ödeme Entegrasyonu Planlarken Geliştirme Öncesi Sorular

Ödeme sağlayıcısı seçmeden önce altı soruyu netleştirin: müşterilerinizin fiilen hangi yöntemleri kullandığı, döviz çevrimi ve itirazlar dahil toplam maliyet, paranın hesabınıza ne zaman geçtiği, iade ve itirazların nasıl yönetildiği, sağlayıcı değiştirirseniz saklı kartlara ne olacağı ve ödeme başarılı olup siparişiniz oluşmadığında sorumluluğun kimde olduğu.

Sonuncusu alıcıların atladığı, operasyon ekiplerinin devraldığı sorudur. Ödeme entegrasyonu büyük ölçüde işler ters gittiğinde ne olacağının tasarımıdır.

Önemli noktalar

• Yerel yöntemler dönüşümü belirler: Türkiye'de taksit desteği çoğu zaman tercih değil belirleyici etkendir.
• Oranı değil toplam maliyeti karşılaştırın: Döviz çevrimi, itiraz ücretleri ve valör gecikmesi genelde yüzde farkını aşar.
• Önce hata durumlarını tasarlayın: Siparişsiz alınan ödeme pahalı durumdur ve gerçekleşecektir.
• Kart taşınabilirliği bir bağımlılık sorusudur: Entegrasyondan önce sorun, ayrılmak istediğinizde değil.

Müşterilerinizin nasıl ödediğiyle başlayın

Ödeme yöntemi tercihi pazara göre keskin biçimde değişir ve bir zevk meselesi değildir. Bazı pazarlarda kart, bazılarında havale, bazılarında cüzdanlar baskındır ve bazı perakende sektörlerinde taksit büyük önem taşır.

Türkiye'deki bir müşteri kitlesi için taksit desteği ve arkasındaki banka ilişkileri, bir sepetin dönüşüp dönüşmeyeceğini çoğu zaman belirler. Bunlara sahip olmayan daha ucuz bir sağlayıcı gerçekte daha ucuz değildir.

Varsaymak yerine görebildiğiniz yerde mevcut müşterilerinizin ne kullandığını kontrol edin. Az kullanılan yöntemler eklemek entegrasyon eforu getirir ve sonrasındaki her işlemde mutabakatı zorlaştırır.

Para kabul etmenin toplam maliyetini karşılaştırın

İlan edilen yüzde yalnızca bir bileşendir. Eksiksiz bir karşılaştırma; yöntem başına işlem yüzdesi ve sabit ücreti, döviz çevrim marjını, itiraz ve uyuşmazlık ücretlerini, iade işleme maliyetini, aylık platform ücretlerini, valör gecikmesini ve nakit akışına etkisini ve entegrasyonun kendi maliyetini içerir.

Valör zamanlaması düzenli olarak hafife alınır. İki günde ödeme yapan bir sağlayıcı ile yedi günde yapan arasındaki fark işletme sermayesi pozisyonunuzu ciddi biçimde değiştirir ve marjı ince bir işletme için bu fark, orandaki yüzde kesirlerinden ağır basabilir.

Geliştirmeden önce hata durumlarını tasarlayın

Başarılı ödemeler basittir. Gerçek tasarım gerektirenler aradakilerdir:

• Ödeme yetkilendirildi ama sipariş servisiniz kısa süre erişilemez
• Yeniden deneme veya çift gönderim yüzünden müşteriden iki kez tahsilat
• Müşteri tarayıcıyı kapattıktan sonra ödemenin başarılı olması
• Kısmen karşılanmış bir sipariş için iade talebi
• Yetkilendirme ile tahsilat arasında stokun tükenmesi

Her birinin tanımlı bir davranışı, bir sahibi ve kurtarma yolu olmalıdır. En zararlısı, kayıt oluşmadan alınan paradır; çünkü müşteri bunu hemen bilir, sisteminiz bilmez. Aday sağlayıcılara, webhook'larının ve mutabakat raporlarının bunu ay sonunda değil dakikalar içinde tespit etmenize nasıl yardım ettiğini sorun.

Mutabakatı baştan planlayın

Birinin her gün, sağlayıcının tahsil ettiğini söylediğiyle sisteminizin sattığını söylediğinin örtüştüğünü doğrulaması gerekir. Tasarlanmış bir süreç olmadan bu, hacimle birlikte büyüyen manuel bir tablo işine dönüşür.

Sipariş tutarı için hangi sistemin yetkili olduğunu, iadelerin ve kısmi iadelerin iki tarafta nasıl temsil edildiğini, döviz çevriminin nasıl kaydedildiğini ve bir uyuşmazlığı kimin araştıracağını belirleyin. Sağlayıcıya özellikle bunun için hangi raporlamayı sunduğunu ve otomatik çekilip çekilemeyeceğini sorun.

Bunun daha geniş ticaret geliştirmesine nasıl bağlandığı için e-ticaret uygulaması geliştirme rehberi yazısına bakın.

Uyum durumunuzu anlayın

Kart verisi sunucularınıza hiç değmiyorsa — barındırılan ödeme sayfası, yönlendirme veya sağlayıcı tarafından sunulan alanlar kullanıldığında — uyum yükümlülükleriniz belirgin biçimde hafiftir. Ham kart verisini kendiniz işlemek çok daha katı gereklilikler doğurur ve ödeme işi yapmayan hiç kimse için nadiren buna değer.

Her sağlayıcının hangi modeli sunduğunu doğrulayın ve müşteriyi sitenizde tutuyor görünürken aslında kart bilgilerini sizin kodunuzla toplayan entegrasyonlara dikkat edin. Bu ayrım yükümlülüklerinizi belirler ve satış materyalinden her zaman anlaşılmaz.

Ayrılmanın neye benzediğini sorun

Pratik bağımlılık saklı kartlardır. Müşteriler ödeme bilgilerini sağlayıcınızda kaydettiyse ve siz değişirseniz, bu token'lar genellikle sağlayıcının desteklemeyi kabul etmesi gereken bir göç süreci olmadan taşınmaz.

Entegrasyondan önce kart token'larının başka bir sağlayıcıya taşınıp taşınamayacağını, hangi koşullarda ve hangi maliyetle taşınacağını sorun. Destekleyen sağlayıcılar bunu söyler. Desteklemeyenler belirsiz yanıt verir ki bu da yanıtın kendisidir ve bunu iki yıl sonra değil şimdi duymak çok daha iyidir.

İlgili rehberler

İlgili içerikler:

• E-Ticaret Uygulaması Geliştirme: Pratik Planlama Rehberi
• B2B E-Ticaret Portalı: Sepetin Ötesindeki İş Akışları
• Müşteri Portalı Geliştirme: İş Akışları, Entegrasyonlar ve Benimseme

Ödeme Entegrasyonu Planlarken Geliştirme Öncesi Sorular rehberinden doğan çalışma; ürün stratejisi, tasarım, geliştirme veya entegrasyon desteği gerektiren somut bir girişime dönüşürse E-Ticaret Platformunuzu Konuşalım.