Misafirler, belirsizlik yaratan bir sipariş akışındansa dolu bir salonu daha kolay affedebilir. Pratik soru şudur: ödeme akışı sepet durumunu, operasyon kurallarını ve ödeme durumunu senkron tutuyor mu, yoksa misafiri sürtünme yaratıp güveni zayıflatabilecek kopuk bir ödeme akışına mı gönderiyor?
Restoranlar için bu aynı zamanda bir mimari sorusudur: POS entegrasyonu, dönüşüm oranı optimizasyonu (CRO) ve ödeme adımı terk oranı, sepetin ödemeye nasıl aktarıldığına bağlıdır.
Ödeme mimarisi, doğrudan siparişin bel kemiğidir: sepet, gel-al ve teslimat, ekstralar ve seçenekler, vergiler, bahşişler, ödeme yöntemleri ve onay — hepsi kendi markanız altında, ödeme anında hiçbir pazar yeri uygulaması markası görünmeden.
Genel mağaza eklentileri restoranlarda neden başarısız olur
Restoran ödeme akışı sıradan bir online mağaza değildir. Bir kitap, müşterinin sepetinde beklerken tükenmez; bir yemek tükenebilir. Kitabın ekstrası, hazırlık süresi ya da çalışma saati yoktur. Genel mağaza sistemleri tam da bu restorana özgü detaylarda başarısız olur — mutfağın karşılayamayacağı siparişleri sessizce kabul eder:
Restoran ödeme akışının dört temel bileşeni
Güvenilir bir ödeme akışı dört sütuna dayanır. Biri eksikse, cuma akşamı bunu ortaya çıkarır:
Aşağıdaki bölümlerde her birini tek tek ele alıyoruz.
Ekranlardan daha önemlisi: durum yönetimi
Cilalı bir arayüz yeterli değildir. Önemli olan güvenilir sepet durumudur. Sipariş sürerken bir yemek tükendiğinde, misafir teslimat bölgesini değiştirdiğinde ya da gel-al ile teslimat arasında geçiş yaptığında ne olur? Sistem, canlı menüyü — stok durumu, süreler ve kapasite — sayfayı yeniden yüklemeden sepete bağlamalıdır.
Bunun çalışabilmesi için genel menü ve sepet aynı kaynaktan okunmalıdır. Aksi halde bir fiyat değişikliği ya da tükenen bir yemek ödeme adımıyla çelişir ve yanlış siparişler ekranda değil mutfakta fark edilir. Misafir geri döndüğünde kendini "unutan" bir sepet, kaybedilen gelirin en sessiz halidir.
Menü doğruluğu: yalnızca mutfağın karşılayabileceğini vaat edin
İkinci sütun en az görünen ama en çok sonuç doğuran sütundur. Sipariş sayfası menünün kendi güncelliğini yitirmiş kopyasını tutuyorsa, er ya da geç mutfağın karşılayamayacağı bir şeyi vaat eder: tükenen bir yemek, artık var olmayan bir seçenek ya da dolmuş bir zaman dilimi. Misafir bunu çok geç öğrenir ve ekip durumu servis sırasında düzeltmek zorunda kalır.
Bu yüzden ödeme adımı, bir şablonun içindeki ikinci bir varsayımlar bütünü değil, mutfakla aynı kuralları kullanmalıdır. Stok durumu, servis süreleri ve kapasite hepsi tek bir kaynaktan gelir. İşte bu, siparişi kabul eden bir sistemle yalnızca gerçekten karşılayabileceği siparişleri kabul eden bir sistem arasındaki farktır.
Markayı bozmadan ödeme
Sertifikasyon ve tokenizasyon uzman ödeme sağlayıcılarının işidir — ancak sipariş kanalı ve deneyimi restoranınızdan başlamalıdır. 3-D Secure gerektiğinde misafir bankasının kimlik doğrulama adımını görebilir; yine de bir pazar yerine aktarılmadan restoranın doğrudan sipariş akışında kalır. Markalı ödeme akışı restoranın ham kart verilerini saklamasını gerektirmemelidir; tokenizasyon ve düzenlemeye tabi ödeme işlemleri sağlayıcıda kalır.
Bu hem bir güvenlik hem de bir dönüşüm meselesidir: öde butonundaki güven, tezgahtaki güven gibi hissettirmelidir. Sonrasında gelen şey — tekrar ziyaret — sizin kontrolünüzdeki bir uygulama, e-posta ya da sadakat programı gibi bir sebebe bağlıdır. Başkasının ödeme sayfasında ilişki işlemle birlikte biter; kendi sayfanızda ise tam da o noktada başlar.
Yoğunlukta da güvenilir
Cuma akşamı saat 19:00 gerçek yük testidir. Güvenilir bir akış; ödeme başlatıldı, kimlik doğrulama gerekli, ödeme yetkilendirildi, tahsil edildi, sipariş alındı, kabul edildi, reddedildi veya iade edildi durumlarını birbirinden ayırır. Idempotency, benzersiz sipariş kimlikleri ve doğrulanmış ödeme olayları, istekler tekrarlandığında mükerrer tahsilat ve sipariş riskini azaltır. Sunucu ödeme ve sipariş durumlarını eşleştirmeli, tekrarlanan veya geciken webhook'ları güvenle işlemelidir.
Mimarinin sahibi olun, geri dönüşü elinizde tutun
Şeffaf olmayan üçüncü taraf sistemler, başkasının kesintisi ve başkasının ücretleri demektir. Kendi sitenizdeki şeffaf bir ödeme akışı, doğrudan sipariş ekonomisini işletmenizle uyumlu tutar: ödeme markanızın ve sipariş yolculuğunuzun bir parçası kalırken, sertifikalı sağlayıcılar güvenli işlemi yürütür. Kimin sipariş verdiğini görebilir, marjın daha büyük kısmını elinizde tutabilir ve başkasının akışını kabul etmek yerine her adımı dönüşüm için iyileştirebilirsiniz.
En sık yapılan 7 ödeme hatası
- Genel bir mağaza eklentisi kullanmak, restorana özgü ihtiyaçları karşılayamaz.
- İki ayrı menü kaynağı tutmak; sipariş sayfası ve mutfak farklı bilgiler gösterir.
- Çok fazla zorunlu alan istemek ya da misafiri satın almadan önce hesap oluşturmaya zorlamak.
- Maliyetleri yalnızca sonda göstermek, ücretleri ve teslimat masraflarını baştan netleştirmek yerine.
- Ödemeyi başka bir siteye yönlendirmek, hem markayı hem güveni zedelemek.
- Çift dokunuşa karşı koruma olmaması, tek dokunuşun iki tahsilata dönüşmesine izin vermek.
- Misafir geri döndüğünde ya da ağ değiştirdiğinde sepeti kaybetmek.
Ödeme mimarisi kontrol listesi
Sıkça sorulan sorular
Hazır bir mağaza eklentisi restoran siparişleri için yeterli mi?+
En sık yapılan ödeme hatası nedir?+
Ödeme akışı kendi markamı taşırsa ödeme güvenliğinden ödün mü veririm?+
Tek bir menü kaynağı neden bu kadar önemli?+
Ödeme sırasında bağlantı koparsa ne olur?+
Ödeme, sahip olduğunuz en değerli alandır
Arayüz, misafirlerin ödeme adımını beğenip beğenmeyeceğine karar verir; mimari ise verilen sözlerin tutulup tutulmayacağına karar verir. Bir arada — tek kaynak, kendi siteniz üzerinden ödeme ve güvenli sipariş aktarımı — güzel görünen bir sipariş sayfasını, marjı ve misafir ilişkisini sizde tutan bir sisteme dönüştürür. Ödeme adımının sahibi olun, misafir ilişkisinin de sahibi olursunuz — uzun vadeli gelirin en güçlü kaldıracı.
