Uluslararası Checkout'ta Ödeme Yöntemi Seçimi
Kart formu her yerde aynı görünür, ödeme alışkanlıkları her yerde aynı değildir. Hollandalı kullanıcı iDEAL arar, Brezilyalı boleto, Çinli Alipay. Uluslararası satış yapan bir arayüzde ödeme adımının işi, kartı kabul etmek değil, karşıdaki kişinin zaten kullandığı yöntemi ona ilk bakışta göstermek.
Kart formu tek başına neyi kaçırıyor
Kredi kartına erişimi olmayan büyük bir kitle var: genç kullanıcılar, düzenli gelir belgesi olmayanlar, bankacılık sistemine mesafeli davranan bölgeler. Bu kişiler alışverişten vazgeçmiyor, ödeme adımından vazgeçiyor. Sepete kadar gelmiş, ürünü seçmiş, sonra tek satırlık bir kısıtla duvara toslamış kullanıcı en pahalı kayıptır, çünkü onu oraya getirmenin maliyeti çoktan ödenmiştir.
Yaygın yerel yöntemler kabaca şu gruplara ayrılıyor:
- Banka tabanlı anlık transfer: Hollanda'da iDEAL, Belçika'da Bancontact, Almanya'da giropay, Polonya ve Hindistan'da benzer yerel şemalar.
- Dijital cüzdanlar: Çin'de Alipay ve WeChat Pay, geniş coğrafyada PayPal, cihaz tarafında Apple Pay ve Google Pay.
- Çevrimdışı ödeme: Brezilya'da boleto bancário, Meksika'da market kasasında nakit ödeme. Sipariş oluşur, para birkaç gün sonra gelir.
- Taksit: yüksek sepet tutarlarında, bazı pazarlarda kartın kendisinden daha belirleyici.
Yöntemi ülkeye göre siz seçin
Ödeme yöntemi seçimini kullanıcıya sormak yerine ülkeye göre varsayılan sıralamayla çözerim: teslimat ülkesi neyse o pazarın en yaygın iki yöntemi üstte, kart hemen altında, kalan her şey "diğer ödeme yöntemleri" başlığının arkasında. Tahmin yanlış çıkarsa kullanıcı tek tıkla listeyi açar, yani yerelleştirme bir kısıt değil, bir ön sıralama olur.
Aynı mantık kart tipi sorusu için de geçerli. "Banka kartı mı, kredi kartı mı?" diye sormanın teknik bir gerekçesi yok; kart numarasının ilk hanelerindeki BIN bilgisi kart tipini de, veren kurumu da zaten veriyor. Kullanıcıya bildiği ama düşünmesi gereken bir soruyu sormak, formda gereksiz bir karar noktası açar. Bu soruyu kaldırın.
Her yöntem arayüzde bir satır, arkada bir sistem
"Mümkün olduğu kadar çok yöntem sunun" tavsiyesi maliyet tarafını atlıyor. Bir ödeme yöntemi eklemek, ödeme sayfasına bir logo koymak değildir. Her yöntem beraberinde kendi başarısız ödeme durumunu, kendi iade akışını, kendi webhook'unu ve kendi mutabakat raporunu getirir. Test yükü de yöntem sayısıyla doğru orantılı büyümez: yöntem, para birimi ve senaryo (başarılı, iptal, kısmi iade, zaman aşımı) çarpılır.
Sekiz yöntem sunan bir mağaza, sekiz ayrı iade prosedürü işletiyor demektir. Bunların bir kısmı otomatik değildir; çevrimdışı ödemede iade banka havalesiyle elle yapılır ve müşteri hizmetleri o yükü taşır. Yöntem listesini uzatma kararı bu yüzden tasarım kararı olduğu kadar operasyon kararıdır, ve pazar başına iki iyi seçenek, global on zayıf seçenekten iyi sonuç verir.
Ek adımlı ödemelerde arayüz sipariş sonrası devam eder
Boleto, kasada nakit ödeme veya token'lı doğrulama gibi yöntemlerde kullanıcı "öde" tuşuna bastığında iş bitmiyor. Ödeme birkaç saat, bazen birkaç gün sonra tamamlanacak. Bu aradaki boşluk tasarlanmazsa kullanıcı siparişin düştüğünü sanar.
Bu ekranda üç şey net olmalı: ne yapması gerektiği, nereye kadar süresi olduğu ve belgeye sonradan nasıl ulaşacağı. Barkodu ekranda göstermek yetmez, aynı belgeyi e-postayla da gönderin ve yazdırılabilir tutun. Sipariş durumu sayfası "ödeme bekleniyor" demeli, "beklemede" gibi belirsiz bir etiket kullanmamalı. Bu akışta ek satış ekranı göstermek en kötü karardır; kullanıcı bir görevi tamamlamaya çalışıyor, araya giren her ekran o görevi geciktirir.
Ölçerken ortalamaya bakmayın
Checkout terk oranını tek bir sayı olarak izlemek yanıltır. Genel oran sabit dururken belirli bir ülkedeki oran çok yüksek olabilir ve ortalama bunu gizler. Ödeme adımı metriklerini ülke ve yöntem kırılımında tutun; eksik yöntem sorunu neredeyse her zaman coğrafi bir kümede toplanır. Bir pazarda terk oranı diğerlerinin belirgin üstündeyse, önce oradaki ödeme seçeneklerine bakın, arayüzün geri kalanını sonra sorgulayın.