Müsaitlik bir teklif, kesin rezervasyon değildir
Misafir bir restoran, tarih ve kişi sayısı seçtiğinde uygulamanızdaki müsaitlik bilgisi o andaki uygun seçenekleri gösterir. Bu bilgi tek başına masa ayrıldığı veya rezervasyonun kesinleştiği anlamına gelmez. Rezervasyon akışını kendi uygulamasına ekleyen ekip önce partnerin erişebildiği restoranları listeler, mekanın rezervasyon kurallarını bootstrap üzerinden alır, ardından tarih, saat ve alan seçimlerini sorgular.
Örneğin kullanıcı cumartesi akşamı dört kişi için yer arıyorsa, daha önce gördüğü bir saat seçim sırasında dolmuş olabilir. Bu nedenle eski bir ekran görüntüsünü veya önbelleğe alınmış sonucu garantili masa gibi sunmayın; istek sonucuna göre kullanılabilir seçenekleri yeniden gösterin.
Hold, seçimi geçici olarak korur
Uygun seçenek seçildiğinde hold çağrısı rezervasyon akışı için geçici bir oturum oluşturur. Hold süresi sınırlıdır; misafir bilgisi ve sonraki adımlar bu oturumla ilişkilendirilir. Hold tamamlandığında kullanıcıya ‘rezervasyon onaylandı’ mesajı göstermeyin.
Geliştirici ekip hold yanıtındaki oturum kimliğini saklamalı, sürenin dolmasını ve tekrar denemeleri yönetmelidir. Süresi geçmiş veya farklı mekana ait oturumda akışa kaldığı yerden devam etmek yerine yeni müsaitlik kontrolü gerekir.
Confirm sonucunu ödeme modeline göre yorumlayın
Confirm, misafir bilgileriyle rezervasyon akışını ilerletir; ancak her zaman nihai rezervasyon anlamına gelmez. Ödeme gerekmeyen senaryoda rezervasyon bu adımda oluşabilir. Ertelenmiş ön ödeme modelinde finansal durumu bekleyen bir rezervasyon oluşur ve misafir ödeme bağlantısından işlemi tamamlar.
Anında ödeme veya ön provizyon modelinde Confirm, ödeme gerekli yanıtı döndürebilir. Bu durumda kart ve 3D Secure işlemi tamamlanır; ardından Finalize çağrısı yapılarak rezervasyon oluşturulur. Finalize tamamlanmadan yalnızca ödeme başarısına bakarak ‘rezervasyon kesinleşti’ demeyin. Her işlemde dönen yanıtın durumunu esas alın.
Ödeme alındı ama Finalize tamamlanmadıysa
Anında ödeme akışında misafir ödeme yaptıktan sonra uygulamaya dönemeyebilir veya ağ bağlantısı kesilebilir. Bu durumda ödeme başarılı olduğu hâlde rezervasyon henüz oluşmamış olabilir. Partner API, eksik kesinleştirmeleri izlemek için ilgili bildirim ve sorgu uçları sunar; bunları kullandığınız senaryoda test edin.
Aynı oturum kimliğiyle Finalize tekrarlandığında ikinci bir rezervasyon üretilmemesi için idempotent davranış tasarlanmıştır. Yine de başarısız veya belirsiz ödeme sonucunda kullanıcıya kesin bir durum göstermeden önce ödeme durumunu sorgulayın. Ücretli ve ücretsiz akışları aynı başarı ekranıyla yönetmeyin.
Webhook'u bildirim, GET yanıtını güncel kayıt olarak kullanın
Rezervasyon oluşturma, onay, iptal ve yayınlanan diğer olaylar için webhook kullanılabilir. Her olay türünün abone olunabilir olması, o olayın mutlaka yayımlandığı anlamına gelmez. Webhook gövdesi güncel rezervasyonun bütün durum veya misafir alanlarını taşımaz. Olayı aldığınızda imzayı doğrulayın, tekrar gelen bildirimi idempotent ele alın ve gerekli izinle rezervasyon detayını yeniden okuyun.
Bildirimler her zaman oluşma sırasıyla gelmeyebilir. Örneğin onaydan hemen sonra iptal gerçekleştiyse en son aldığınız webhook'u kesin durum olarak kabul etmek hatalıdır. Kullanıcıya göstereceğiniz metni rezervasyonun güncel API yanıtına göre hazırlayın.
Canlıya geçmeden önce hangi senaryolar denenmeli?
Başarılı bir rezervasyonun yanında dolu saat, hold süresi dolması, eksik misafir bilgisi, 3D Secure'dan geri dönememe, çift gönderim, webhook'un tekrar teslimi ve izinsiz restoran erişimi için ayrı testler yapın. Kullanıcıya verilen rezervasyon numarasının Rezervem'deki kayda karşılık geldiğini doğrulayın.
Rezervasyon ve masa operasyonunu restoran içinden yürütmek isteyen işletmeler için Rezervem Manager uygun başlangıçtır. Kendi uygulaması üzerinden rezervasyon oluşturan yetkili ortaklar ise Rezervem Partner API kapsamında senaryo ve izinlerini belirlemelidir.
