Sepet Terk Oranını Düşürme & Dönüşüm Oranını Artırma | Bölüm 2

İlk bölümünde alışveriş sepeti, ödeme adımları tasarımı ve kartlı ödeme sayfası konularına değindiğimiz Sepeti Terk Etme Oranını Düşürmek ve Dönüşüm Oranını Artırmak İçin Yapmanız Gerekenler yazı dizisinin bu ikinci bölümünde syntactic ve semantic validasyonlara ait detayları bulacaksınız.

3- Syntactic ve Semantic Validasyonlar

Kartlı ödeme sayfasında, bankaya istek gönderilmeden önce yapılması gereken bir takım syntactic ve semantic validasyonlar bulunur. Bu validasyonlara dikkat ederek başarılı ödeme sayınızı ve sepet dönüşüm oranınızı artırabilirsiniz.

Dilerseniz, detaylara girmeden önce küçük bir istatistikle başlayalım: Tüm syntactic ve semantic validasyonları yapsanız bile bankaya gönderilen her 100 ödeme isteğinin yaklaşık 15-20′si başarısızlıkla sonuçlanır. Başarısızlıkla sonuçlanan bu hataların detaylarını bir sonraki makalede bulabilirsiniz.

Ek Bilgi: Kartın ilk 6 veya 8 karakterine BIN Numarası denir. BIN Numarasına göre kartın tipi (Visa, MasterCard, American Express), kartın grubu (kredi kartı, banka kartı, ön ödemeli kart), kartın ailesi (wings, bonus, maximiles, world, …) ve kartın bankası (Akbank, Garanti Bankası, İş Bankası, YKB, ..) ve bireysel mi ticari kart mı olduğu tespit edilebilir. Ödeme sistemlerine ilişkin temel tanımlara, daha önce yayınladığımız yazımızda ulaşabilirsiniz. 

Bankaya gönderilen ödeme isteğinin mümkün olduğunca geçerli olması için yapmanızı önerdiğimiz syntactic ve semantic validasyonlar şunlardır:

• Kart Üzerindeki Kart Sahibinin Adı-Soyadı Alanı: En az ikişer karakterden oluşmalı ve aralarında boşluk bulunmalıdır (örnek: Su Ay)
• Kart Numarası: Nümerik olmalı, harf yazılamamalıdır. ([0-9])
• Kart Numarası: Visa ve MasterCard’lar için 16, American Express (Amex) için 15 karakterden oluşmalıdır. Visa, MasterCard ve Amex kırılımlarını öğrenmek için tıklayınız.
• CVC2 (Güvenlik Kodu): Visa ve MasterCard’lar için 3, American Express (Amex) için 4 karakterden oluşmalıdır. Böylece Kart Numarası ve CVC2 alanı toplamda 19 karakter olmalıdır.
• Kart Numarası: Luhn algoritmasından geçmeli, bu algoritmaya uygun olmalıdır. Hem önyüzde JavaScript ile hem de sunucu tarafında validasyon yapılmalıdır. 
• Son Kullanma Tarihi: Mevcut ay ve yıldan büyük-eşit olmalıdır. 
• Girilen Kart:  Eğer girilen kart, banka kartı (debit card) veya ön ödemeli kart (prepaid card) ise:
  • 3D Secure seçeneği zorunlu olmalı, (Bu kartlardan bazı istisnalar hariç 3D Secure dışında ödeme geçemez) 
  • Taksit seçenekleri gizlenmelidir ve peşin seçeneği zorunlu kılınmalıdır. (Bu kartlardan taksitli işlem geçemez)
• Girilen Kart: Eğer girilen kart, sizde sanal POS’u olmayan bir bankaya ait ise, taksit seçenekleri gizlenmeli, peşin seçeneği zorunlu kılınmalıdır. (Sizde sanal POS’u olmayan banka kredi kartlarına taksit yapamazsınız.)
• Girilen Kart: Eğer girilen kartın bankasına ait bir sanal POS sizde mevcut fakat o anda ilgili sanal POS çeşitli sebeplerle pasif durumda ise kullanıcıya bilgilendirme mesajı verilmeli ve taksit seçenekleri gizlenmelidir. Peşin seçeneği ise zorunlu kılınmalıdır. (Bu ödeme isteği kendi bankasına ait sanal POS’tan değil, o anda sistemde varsayılan olan başka bir bankaya ait sanal POS’tan peşin olarak gerçekleşmek durumundadır.)

4- Ödeme Hatalarının Tasnifi ve Önyüzde Gösterilmesi Gereken Mesajlar

Sepeti Terk Etme Oranını Düşürmek ve Dönüşüm Oranını Artırmak İçin Yapmanız Gerekenler – Yazı Dizisi‘nin sonuncusu olan bu yazımızda, ödeme hatalarının tasnifi ve önyüzde gösterilmesini önerdiğimiz mesajlara/metinlere ait detayları bulacaksınız.

Kartlı ödeme sayfasında, hem önyüzde (client side javascript) hem de sunucu tarafında yapılan syntactic ve semantic validasyonlardan geçemeyen kullanıcılara gösterilmesi gereken mesajlar aşağıdaki gibi olabilir. 

• Ad-soyad bilginiz geçerli değil, … [Ad-soyad bilgisi girilmemişse veya 4 karakterden küçükse veya alfanümerik değilse …]
• Kart numaranız geçerli değil, … [Kart numarası 15 veya 16 hane nümerik değilse veya luhn algoritmasından geçemiyorsa]
• Son kullanma tarihiniz geçerli değil, … [Girilen son kullanma tarihi sistem tarihinden küçük ise veya nümerik değilse]
• Güvenlik kodu/CVC2 bilginiz geçerli değil, … [Güvenlik kodu 3 haneliyse (Visa ve MasterCard için) veya 4 hane (amex için) değilse, nümerik değilse, …]
• Kartınıza taksit yapılamamaktadır, … [Taksit seçilmişse ve karta taksit yapılamıyorsa, banka kartı veya ön ödemeli kart olabilir. Sizde sanal POS’u olmayan banka kartı olabilir veya sanal POS’u olan bankanın kartı olmasına rağmen sanal POS o anda aktif değilse, …]
• Kartınız ile sadece 3D Secure işlem yapılabilir, … [Banka veya ön ödemeli kart seçilmişse ve 3DS olmayan işlem deneniyorsa]
• Kartınız/bankanız 3D Secure işlemi desteklememektedir, … [Kart veya banka 3D Secure işlemi desteklemiyorsa ve kullanıcı 3D Secure işlem seçmişse]
• Satın almak istediğiniz ürün (ler) satışa kapanmıştır, … [Sepet adımlarında ilerlerken, ürünler tükenmiş veya satışa kapanmışsa, … (race-condition, sold-out)]

Diyelim ki syntactic ve semantic validasyonları yaptınız, kullanıcının herhangi bir validasyon hatası bulunmuyor ve ödemeyi bankaya göndermeye hazırsınız. Bankaya gönderilen her 100 ödeme isteğinin yaklaşık 15-20′si (%15-20) başarısızlıkla sonuçlanır. Bu hataların dağılımı ise kabaca aşağıdaki gibidir:

• % 33-38 “Limitiniz Yetersiz“
• % 15-18 “Genel Red, İşlem Onaylanmadı“
• % 10-12 “Son Kullanma Tarihi Hatalı/Geçersiz“
• % 2-3 “Güvenlik Kodu/CVC2 Hatalı“
• % 29-40 Diğer: İnternete kapalı kart, günlük işlem sayısının aşılması, 1 TL’nin altında taksitli işlem denenmesi, sipariş numarasının daha önceden kullanılmış olması, çalıntı kartla işlem denemesi, kartın provizyon vermemesi, karta taksit yapılamaması, kart sahibine açık olmayan işlem, erişim problemleri, sistemsel problemler,…

Ödeme isteği başarısızlıkla sonuçlandığında, bankadan hataya ait kod ve mesaj dönmektedir. Malesef ki hata kodları ve mesajları bankadan bankaya değişebildiği gibi, bir banka özelinde de hata kodu ve mesajı tekil değildir, her bir hata koduna ait tekil bir mesaj olmadığı gibi, bir hata mesajı farklı hata kodlarında da bulunabilmektedir.

Örnek:

• 051 nolu hata kodu Payten/Asseco API’sini kullanan bankalar ve Garanti Bankası için Limitiniz Yetersiz hatası anlamına gelirken, nadiren de olsa 061, 065 ve 099 nolu hata kodları da içerdiği mesaja göre Limitiniz Yetersiz hatası anlamına gelebilir.

Bu noktada, bankadan dönen hata kodlarını ve mesajlarını öğrenen bir kural setinden geçirip, tasnif edip son kullanıcıya uygun bir dille aktardığınızda, hatanın nedenini anlayan kullanıcı ikinci kez bilinçli bir şekilde deneyecektir. Bu da sepet dönüşüm oranınızı (conversion) arttıracaktır.

Örneğin, kullanıcı “Limitiniz Yetersiz” hatası aldığında siz bu hatayı yakalayıp kullanıcıya “Kartınızın limiti XX TL’lik işlem için yeterli değildir !” derseniz, kullanıcı da sanal kart kullanıyorsa kart limitini yükseltecek veya cebindeki diğer kart ile ödemeyi

deneyecektir (Unutmayın ki 2022 yılı BKM verilerine göre 161 milyon banka kartı, 93 milyon kredi kartı mevcut).
Ödeme dönüşüm oranı artırıcı, sitenizdeki müşteri ödeme deneyimini iyileştirici ve katma değerli Craftgate servisleri için bizimle iletişime geçebilirsiniz.