OpenCart checkout’ları müşteriyi nerede kaybeder — ve nasıl düzeltiriz

Yeniden tasarlamadan önce sayın

Checkout konuşmaları neredeyse her zaman bir fikirle başlar: form çok uzun, buton yanlış renk. Fikir ucuzdur. OpenCart insanların nerede durduğunu zaten kaydediyor ve çoğu mağaza sahibi bu kayda hiç bakmamış oluyor.

Bir müşteri onay adımına ulaşıp ödeme tamamlanmazsa OpenCart siparişi yine yazar — order_status_id değeri 0 olarak. Bu satırlar varsayılan sipariş listesinde görünmez; Satış → Siparişler ekranında “Eksik Siparişler” filtresini seçmeniz gerekir. Tamamlanan siparişlerinizin yanındaki bu sayı, sorunun dürüst boyutudur.

SELECT DATE(date_added) AS gun,
       SUM(order_status_id = 0) AS tamamlanmayan,
       SUM(order_status_id > 0) AS tamamlanan
FROM oc_order
WHERE date_added >= CURDATE() - INTERVAL 30 DAY
GROUP BY gun
ORDER BY gun;

Oranın istikrarlı olması normaldir; insanlar fikir değiştirir. Tek bir günde sıçraması normal değildir: orası genelde bir ödeme eklentisinin, bir kargo tarifesinin ya da bir SSL sertifikasının bozulduğu öğleden sonradır ve vitrin hâlâ düzgün göründüğü için kimse fark etmemiştir.

OpenCart 2.x / 3.x

6 adımlı akordeon

OpenCart 4.x

tek sayfa, AJAX

Tamamlanmayan sipariş

order_status_id = 0

Öncesindeki adımlar için sayfa görüntüleme yerine GA4’ün e-ticaret olaylarını kullanın; varsayılan checkout URL’yi neredeyse hiç değiştirmediği için sayfa temelli huniler hiçbir şey anlatmaz. view_cart, begin_checkout, add_shipping_info, add_payment_info ve purchase olaylarını gönderin, huniyi bunların üstüne kurun.

window.dataLayer = window.dataLayer || [];
dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: 'begin_checkout',
  ecommerce: {
    currency: 'TRY',
    value: 1249.90,
    items: [{ item_id: '1042', item_name: 'Bornoz', price: 1249.90, quantity: 1 }]
  }
});

Adımların kendisi

OpenCart 2.x ve 3.x tek sayfada altı bölümlü bir akordeonla gelir: ödeme seçenekleri, fatura bilgileri, teslimat bilgileri, teslimat yöntemi, ödeme yöntemi, onay. Her bölüm sunucuya gönderim yapıp bir sonrakini açar. Çalışır, ama her bölüm takılma ihtimalidir ve ikinci bölümdeki bir doğrulama hatası müşteriyi sayfanın yukarısına geri fırlatır.

OpenCart 4.x bunun yerine parçaları AJAX ile yüklenen gerçek bir tek sayfa checkout koydu. Bu birkaç takılmayı ortadan kaldırıyor — ve yeni bir arıza biçimi getiriyor. Bu AJAX çağrılarından biri hata döndüğünde sayfa çoğu zaman görünür hiçbir şey yapmaz: müşteri Onayla’ya basar, buton öylece durur. Tarayıcının ağ sekmesini açın, onay isteğini izleyin ve dönen JSON’u okuyun; sebep neredeyse her zaman içindedir.

Zorunlu üyelik

Yapısal olarak en büyük kayıp hâlâ, ödeme yapabilmesi için insanlardan önce hesap açmalarını istemek. Misafir ödeme ayarı Sistem → Ayarlar → mağazayı düzenle → Seçenek sekmesinde, Ödeme başlığı altında. Açın ve ikinci radyo düğmesi olarak değil, önceden seçili seçenek olarak bırakın.

İnsanlara bir öğleden sonra kaybettiren bir ayrıntı: sepette indirilebilir bir ürün varsa OpenCart misafir ödemeyi devre dışı bırakır, çünkü indirme hakkının bir hesaba ait olması gerekir. Misafir ödeme açık olduğu hâlde sunulmuyorsa, ayara bakmadan önce sepetin içine bakın.

Aynı Seçenek sekmesinde Hesap Sözleşmesi ve Ödeme Sözleşmesi ayarları var. Bunları bir bilgi sayfasına bağlamak zorunlu bir onay kutusu ekler. Hukuken gerekiyorsa ödeme tarafındakini bırakın, ama bunun bir adım olduğunu bilin: ekrandan kayıp giden işaretlenmemiş bir kutu, butonun bozuk olduğunu düşünen bir müşteri demektir.

Kimsenin okumadığı zorunlu alanlar

Varsayılan adres formu ad, soyad, firma, iki adres satırı, şehir, posta kodu, ülke ve bölge ister; misafir adımında bunlara e-posta ve telefon eklenir. Sonra mağazalar Sistem → Müşteriler → Özel Alanlar altından yeni alanlar ekleyip zorunlu yapar — genellikle depoların sonradan bir e-postayla sorabileceği bir şey için.

Posta kodu kendi paragrafını hak ediyor, çünkü OpenCart bunu çoğu kişinin sandığından iyi yönetiyor. Zorunluluk ülke bazında ve ülke kaydının kendi içinde tutuluyor:

SELECT country_id, name, postcode_required, status
FROM oc_country
WHERE iso_code_2 IN ('TR','DE','GB','AE');

-- ve müşteriye gösterilen adres düzeni:
SELECT name, address_format FROM oc_country WHERE country_id = 215;

Bunu SQL’den değil, Sistem → Yerelleştirme → Ülkeler ekranından düzenleyin ve gerçekten gönderim yaptığınız ülkeler için address_format alanını doldurun. Alışık olmadığı bir forma Türkiye biçiminde adres yazmaya çalışan bir Alman müşteri, ayrılmak için bahane arayan bir müşteridir.

• Gönderim ve fatura için gerekeni sorun; gerisi bekleyebilir.
• Telefon ve posta kodunda sayısal klavye açılsın diye doğru input tiplerini kullanın.
• Ad, adres ve e-posta alanlarına autocomplete öznitelikleri koyup tarayıcı otomatik doldurmasını çalışır hâle getirin.
• Özel alanları yılda bir gözden geçirin; çoğu, biteli çok olmuş bir kampanya için eklenmiştir.

“Kargo seçeneği bulunmuyor”

Bu mesaj ve ödeme yöntemindeki ikizi, hiçbir tasarım kararının götüremeyeceği kadar çok checkout’u bitirir. Anlamı, OpenCart’ın müşterinin adresine uyan bir yöntem bulamamış olmasıdır ve sebepler bir elin parmaklarını geçmez.

En yaygını coğrafi bölgeler. Her kargo ve ödeme eklentisi Eklentiler altında bir coğrafi bölgeyle sınırlandırılır; bölgelerin kendisi de Sistem → Yerelleştirme → Coğrafi Bölgeler’de durur. Mağazaya yeni bir ülke ekleyip coğrafi bölgeyi unutursanız, oradaki müşteriler bu mesajı hiçbir açıklama olmadan görür. İkinci sebep ağırlıktır: ağırlığa göre kargo, tartamadığı bir sepeti fiyatlandıramaz.

SELECT product_id, model, weight, weight_class_id
FROM oc_product
WHERE status = 1 AND weight = 0
LIMIT 50;

Ağırlığa göre yöntemde tarifeler ağırlık:ücret çiftleri olarak girilir — 5:10.00,10:15.00 ifadesi 5 birime kadar 10.00, 10 birime kadar 15.00 demektir. Sepet en üst bandın üstüne çıkarsa tarife de yoktur, yöntem de. En ağır gerçekçi siparişinizi kapsayan bir üst bant her zaman tanımlayın.

Ödeme sayfasından dönüş

Daha sessiz bir arıza: müşteri ödemeyi başarıyla yapar, bankadan geri döner ve boş bir sepete ya da giriş ekranına düşer. Para hesabından çıkmıştır; sipariş 0 durumunda kalır.

Bugün bunun olağan sebebi oturum çerezi. Tarayıcılar çerezleri varsayılan olarak SameSite=Lax kabul eder; yani çerez siteler arası bir POST isteğinde gönderilmez — 3D Secure dönüşü ise tam olarak budur. Çerez tutulur, OpenCart karşısında yepyeni bir ziyaretçi görür ve sepet kaybolur. Çözüm, oturum çerezini dönüşten sağ çıkacak şekilde SameSite=None ve Secure ile göndermek ya da dönüşü bir GET yönlendirmesine düşürmektir.

Aynı anda yapılacak iki kontrol daha var. Mağazanın SSL ayarı ile sağlayıcıya kayıtlı dönüş adresinin aynı şemayı ve aynı alan adını kullandığından emin olun — bir www uyuşmazlığı oturumu en az onun kadar iyi düşürür. Bir de başarısız bir test ödemesinden sonra system/storage/logs/error.log dosyasını okuyun; sağlayıcı entegrasyonları sebebi genellikle oraya yazar.

Hangi sırayla çalışıyoruz

İlk hamle olarak checkout’u yeniden tasarlamıyoruz. On vakanın dokuzunda iş şöyle ilerliyor:

1. 1Tamamlanmayan siparişleri sayıp GA4 olaylarını kuruyoruz; böylece sonraki her değişiklik ölçülebilir oluyor.
2. 2Her ülke ve para biriminde, her ödeme yöntemiyle, mobilden gerçek test siparişleri veriyoruz.
3. 3Önce sert arızaları düzeltiyoruz: eksik kargo yöntemi, ödeme dönüşü, oturum kaybı.
4. 4Yerini artık hak etmeyen zorunlu alanları ve adımları kaldırıyoruz.
5. 5Kalan formu hızlı ve klavye dostu hâle getirip yeniden ölçüyoruz.

İlk iki adım birkaç saat sürüyor ve genellikle kimsenin bozuk olduğunu bilmediği bir şeyi buluyor. Buton fikirlerinden önce gelmelerinin sebebi bu.

Ne zaman bize yazın

Bu denetimi mağazanızda birinin yapmasını istiyorsanız, sınırları belli bir iş olarak yapıyoruz: checkout’u uçtan uca test ediyor, bozuk olanı kanıtıyla raporluyor ve düzeltmeleri ayrı fiyatlıyoruz; neyin yapılmaya değer olduğuna siz karar veriyorsunuz. Saatlik 10 $ + KDV lansman ücretiyle faturalanır, ilk yanıtı iki saat içinde veriyoruz, Pazartesi–Cumartesi 09:00–22:00 (GMT+3).