منصات الحجز لديها مشكلة لا تملكها معظم البرمجيات: المنتج الذي تبيعه ليس ملكك. أنت وسيط بين العميل والمزود — الفندق، شركة النقل، منظم الرحلات. مهمة منصتك جعل هذه الوساطة غير مرئية.
عندما جاءنا Omraty، أرادوا بالضبط ذلك: منصة حجز لرحلات العمرة حيث يرى العملاء تجربة بحث موحدة ونظيفة، لكن خلف الكواليس، النظام يسحب التوفر والأسعار من مزودين خارجيين متعددين، كل منهم بواجهات برمجة وهياكل تسعير وسياسات إلغاء مختلفة.
ستة أشهر وفريق من ثلاثة أشخاص لاحقًا، كانت المنصة تعمل.
التحدي الحقيقي لم يكن بناء نظام حجز
بناء تدفق حجز — بحث، اختيار، دفع، تأكيد — أمر مفهوم جيدًا. الصعوبة كانت كل ما وراءه.
مزودون متعددون بسلوكيات مختلفة. كل واجهة برمجة تعمل بشكل مختلف. واحدة تعيد الأسعار فوريًا. أخرى تخزنها وتحدثها كل ساعة. واحدة تدعم التأكيد الفوري. أخرى تتطلب خطوة يدوية. منصتنا كانت تحتاج تقديم تجربة متسقة بغض النظر عن المزود.
ثلاث بوابات دفع. Stripe للبطاقات الدولية. PayPal للعملاء الذين يفضلونه. مدى للمدفوعات المحلية السعودية. كل بوابة لها نمط تكامل وبنية webhooks وتدفق مطابقة خاص بها.
سياسات إلغاء يجب أن تكون شفافة. كل مزود له نوافذ إلغاء ونسب استرداد مختلفة. المنصة كانت تحتاج عرض هذه بوضوح أثناء تدفق الحجز، وليس دفنها في الشروط والأحكام.
المعمارية
بنينا طبقة خدمات لا تعرف المزود. محرك الحجز لا يعرف أي مزود ينفذ الحجز — يعمل مع نموذج داخلي موحد. كل مزود له محول يترجم بين واجهة برمجة المزود وصيغتنا الداخلية.
خلفية Laravel — تتولى محرك الحجز، تنسيق المدفوعات، أدوات الإدارة، وكل منطق العمل.
واجهة Next.js — تتولى البحث وتدفق الحجز وإدارة الحساب من جانب العميل. التقديم من الخادم كان مهمًا لـ SEO صفحات النتائج.
القرار الرئيسي كان معاملة المزودين كإضافات. إضافة مزود جديد = كتابة محول جديد، وليس تغيير محرك الحجز. هذا أثمر عندما أضاف العميل مزود فنادق ثانيًا بعد ثلاثة أشهر من الإطلاق.
ما جعل التكامل صعبًا
تخزين الأسعار والتوفر مؤقتًا
لا يمكن استدعاء واجهة برمجة المزود لكل استعلام بحث — ستصل لحدود المعدل فورًا. لكن لا يمكن تخزين الأسعار طويلًا وإلا يرى العملاء أسعارًا قديمة.
بنينا نظام مزامنة خلفي يسحب التوفر وفق جدول، يخزنه محليًا، ويضع علامة على عمر التخزين ليعرض الواجهة «الأسعار محدثة منذ X دقائق». عند الحجز، نجري تحققًا فوريًا مع المزود. إذا تغير السعر، يراه العميل قبل التأكيد — بدون مفاجآت.
مطابقة المدفوعات عبر البوابات
ثلاث بوابات = ثلاث صيغ webhooks، ثلاثة سلوكيات توقيت للتأكيدات، ثلاث مقاربات للاسترداد. وحّدنا كل شيء عبر خدمة دفع تترجم أحداث كل بوابة إلى حالات داخلية: معلق، مؤكد، فاشل، مسترد. محرك الحجز يعرف هذه الحالات فقط.
منطق الإلغاء والاسترداد
الإلغاء يبدو بسيطًا حتى تحسب نسب الاسترداد المختلفة حسب التوقيت، والإلغاءات الجزئية، والاسترداد لوسيلة الدفع الأصلية، ورسوم المزود التي لا تتطابق مع ما دُفع.
بنينا محرك إلغاء يحسب الاسترداد حسب سياسة المزود، يطبقه على المعاملة الصحيحة، ويتولى المحاسبة تلقائيًا.
ما تعلمناه
أخفِ تعقيد المزود وراء خدمات مستقرة. نمط المحول ليس معمارية غريبة — إنه بقاء. عندما يغير المزود واجهته، تحدّث ملفًا واحدًا، وليس تدفق الحجز بأكمله.
اعرض تفاصيل السياسات مبكرًا في رحلة العميل. قواعد الإلغاء عند الدفع تبدو كفخاخ. نفس المعلومات أثناء البحث تبدو كشفافية.
مهام المطابقة تبقي المالية نظيفة. المطابقة الآلية الليلية بين سجلاتنا وسجلات كل مزود تلتقط التباينات قبل أن تصبح مشاكل.
المزامنة الخلفية والتخزين المؤقت تقلل التأخيرات. استدعاءات فورية لكل بحث = صفحات بطيئة. خزّن بقوة، زامن في الخلفية، تحقق عند لحظة الالتزام.
النتيجة
Omraty أُطلق بتجربة حجز موحدة عبر المزودين، خيارات تسعير شفافة وقواعد إلغاء واضحة، وسير عمل إداري للمراجعة والاسترداد والتقارير.
لكل التفاصيل، اقرأ دراسة حالة Omraty الكاملة.
تبنون منصة بتكاملات معقدة؟
المنصات متعددة المزودين، تنسيق المدفوعات، وأنظمة الحجز تتشارك نفس التحدي الأساسي: جعل التعقيد غير مرئي للمستخدم النهائي. كتبنا عن كم تستغرق هذه المشاريع، كيف نسعّرها، وكيف تبدو الصيانة بعد الإطلاق.
لديكم منصة تحتاج التكامل مع مزودين خارجيين؟ لنتحدث عن المعمارية →