القدرات الأربعة المهمة
Section titled “القدرات الأربعة المهمة”| القدرة | ماذا تعني | لماذا تتوقف المنتجات بدونها |
|---|---|---|
| أسعار وتوافر مباشر | الأسعار الحالية وما هو قابل للحجز فعليًا، حسب نطاق التواريخ | الأسعار المخزنة مؤقتًا تفشل عند التأكيد وتقلل الثقة |
| إنشاء الحجز | إنشاء حجز حقيقي يستلمه الفندق | بدونها أنت مجرد رابط إحالة، وليس منتجًا |
| الدفع | استلام المال كجزء من الحجز | التحويل إلى موقع آخر هو حيث تموت معدلات التحويل |
| التأكيد وwebhooks | إبلاغ الضيف، الفندق ونظامك بما حدث | دعم الحمل والفجوات في التسوية وإلا |
معظم “واجهات برمجة تطبيقات الفنادق” التي يجدها المطور تغطي الأولى وأحيانًا الثانية. المعاملة هي الجزء الصعب، وهو الجزء الذي يحدد ما إذا كان لديك منتج.
من هو مزود العرض الذي تدمجه؟
Section titled “من هو مزود العرض الذي تدمجه؟”هذا السؤال يشكل كل شيء لاحقًا. العرض المعاد بيعه عبر سلسلة يصل مع زيادة في السعر داخل السعر، وتوافر أقل حداثة، ولا يوجد طريق للعودة إلى الفندق لسؤال عن الحجز. العرض الذي يأتي من الفندق مباشرة يحمل سعر الفندق الخاص، وتوافر مباشر، وفندق يعرف أن الحجز موجود.
في أي شيء سيقارن فيه المسافر مع موقع الفندق الخاص — وهو معظم الحالات — العرض الذي يتحكم فيه الفندق يتجنب اللحظة المحرجة عندما يكون سعرك أسوأ.
من هو التاجر المسجل
Section titled “من هو التاجر المسجل”إذا بنيت حجز الفنادق بنفسك، فإن أن تصبح التاجر المسجل يعني تحمل مسؤولية الدفع، المرتجعات، الاستردادات، التعامل مع الضرائب وغالبًا ترخيص وكالة سفر في كل سوق.
في Wink، يبقى الفندق هو التاجر المسجل ويتم جمع الدفع للفندق، لذلك لا يرث المدمج تلك المسؤولية. ترتيبات التاجر المسجل متاحة في تكاملات API حيث يحتاج الشريك فعليًا إلى استلام الدفع بنفسه، وهذا المسار يحمل متطلبات ترخيص خاصة به.
ثلاثة مستويات من التكامل
Section titled “ثلاثة مستويات من التكامل”- مكونات الويب. أضف بحثًا قابلاً للحجز، قائمة غرف أو إتمام شراء إلى صفحة موجودة. لا حاجة لعمل خلفي؛ أقل تحكم في التخطيط.
- REST API. تحكم كامل في البحث، الأسعار، إنشاء الحجز والتأكيد، مع المصادقة عبر OAuth2. استخدمه عندما يكون تدفق الحجز جزءًا من تجربة منتجك.
- خادم MCP. نفس القدرات متاحة لوكلاء الذكاء الاصطناعي، بحيث يمكن للمساعد البحث، التسعير وإتمام الحجز بدلاً من تحويل المستخدم إلى موقع ويب.
الثلاثة ليست حصرية — غالبًا ما يستخدم المنتج المكونات لواجهة تسويقية وAPI لتدفقه الأساسي.
ماذا تبني أولاً
Section titled “ماذا تبني أولاً”- البحث والتسعير لمدينة واحدة ونطاق تاريخ واحد. احصل على أسعار حقيقية متدفقة قبل تصميم أي شيء.
- إنشاء حجز اختبار واحد من البداية للنهاية، بما في ذلك الدفع والتأكيد.
- اشترك في
booking.createوأحداث الإلغاء قبل بناء أي واجهة مستخدم فوقها. - قرر نموذج النسبة الخاص بك مبكرًا — يجب أن ينتقل سياق المصدر مع الحجز، وإلا سيكون تقريرك تخمينًا لاحقًا.
- تعامل مع حالات الفشل: فقدان التوافر بين العرض والحجز، رفض الدفع، الاستردادات الجزئية.
التسعير الذي يجب أن يعرفه المطور
Section titled “التسعير الذي يجب أن يعرفه المطور”واجهات برمجة التطبيقات للمستهلك ومحرك الحجز مجانية. تتضمن واجهة برمجة تطبيقات الشريك بدلًا شهريًا مجانيًا قدره 10,000 ليلة فندقية، ثم يتم الفوترة لكل وحدة. الحجوزات المؤكدة تحمل رسوم منصة الفندق بنسبة 1.5% بالإضافة إلى تكلفة معالجة البطاقة، وتطبق عمولة افتراضية بنسبة 10% عندما يقود منتجك الحجز — وهذا هو كيف يكسب المدمج بدلاً من أن يدفع.
الأخطاء الشائعة
Section titled “الأخطاء الشائعة”- البناء على أسعار مخزنة مؤقتًا. تبدو جيدة في التطوير وتفشل في الإنتاج.
- ترك الدفع لإعادة التوجيه. كل تحويل يفقد حجوزات.
- تجاهل webhooks حتى الإطلاق. تصبح التسوية وظيفة يدوية.
- أن تصبح التاجر المسجل بدون حاجة. هو قرار ترخيص ومسؤولية، وليس مجرد قرار تقني.
- عدم تمرير سياق المصدر. لا يمكن إعادة بناء النسبة بعد ذلك.