سياسات الدمج الشاملة للحجوزات
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تنطبق سياسات الدمج التالية على دمج الحجوزات الشاملة.
السياسات الشاملة
يُرجى قراءة معايير الأهلية التالية للدمج قبل
بدء عملية دمج. يجب أن يستوفي الشركاء المتطلبات التالية
والسياسات ليكونوا مؤهّلين للدمج مع التكامل الشامل للحجوزات في "مركز الإجراءات".
على الرغم من أنّ المتطلبات التالية هي مكوّنات ضرورية للأهلية للانضمام إلى برنامج "مركز الإجراءات"، لا يضمن استيفاء هذه المتطلبات أن يكون الشريك مؤهلاً لدمج "مركز الإجراءات" أو نشره.
قد يؤدي عدم استيفاء المتطلبات والسياسات إلى تعليق عملية الدمج أو تعليق التاجر أو الخدمات أو إزالتها من المنصة.
المتطلبات العامة للنظام الأساسي
- على الشركاء جمع جميع بيانات التجّار والمستخدمين ومعالجتها، بما في ذلك أي معلومات تحديد الهوية الشخصية، بطريقة تتوافق مع "اللائحة العامة لحماية البيانات" (GDPR) وأي قوانين خصوصية أخرى سارية.
- يجب أن يكون الشركاء مفوَّضين بإجراء الحجوزات نيابةً عن التجّار.
يجب أن يتمكّن الشركاء من الوصول مباشرةً إلى معلومات مدى التوفّر أو الفترات الزمنية المتاحة للتجّار في الوقت الفعلي (أي أنّه يجب أن يتمكّن الشركاء من الردّ على طلبات مدى التوفّر الواردة من Google في أقل من ثانية واحدة).
- حالة خاصة: نوفّر الحجوزات التي تتطلّب تأكيدًا غير متزامن من التاجر، ولكن يجب أن تستند عملية الحجز إلى خانة زمنية متاحة. يجب أن يكون لدى الشركاء معلومات حول مدى التوفّر في الوقت الفعلي، أي من خلال أنظمة التاجر على الإنترنت، حتى إذا كان ذلك يتطلّب تأكيدًا من التاجر لإنهاء الحجز.
يجب أن يكون لدى الشركاء مستودعًا شاملاً للتجّار. قد لا يكون التجار الذين لديهم مستودع سلع جزئي أو مستودع سلع متعلّقة بتصفية البضائع مؤهّلين.
يجب أن يكون لدى الشركاء 30 يومًا أو أكثر من معلومات توفّر التجّار.
يجب أن يتيح الشركاء إلغاء الحجوزات على الإنترنت.
على الشركاء الذين يطلبون الدفعات مسبقًا الالتزام بسياسة الدفع في "مركز الإجراءات"، ويجب أن تكون معالجات الدفعات الخاصة بهم مُدرَجة في القائمة المسموح بها التالية وأن تقبل الدفعات الرمزية.
يجب أن يتمكّن الشركاء من تقديم بيانات أسعار دقيقة لتكلفة الخدمات والالتزام بسياسة الأسعار في "مركز الإجراءات".
يجب أن يكون بإمكان الشركاء استيفاء المتطلبات الفنية لميزة "مركز الإجراءات" المتعلّقة بتكامل الحجوزات من البداية إلى النهاية.
على الشركاء الالتزام بمتطلبات أهلية التجار والخدمات في "مركز الإجراءات".
يجب أن يلتزم الشركاء بإرشادات الدعم والصيانة في "مركز الإجراءات".
على الشركاء الحفاظ على معدّلات أخطاء مقبولة محدّدة في
إرشادات الإطلاق والمراقبة.
يجب تأكيد جميع الحجوزات تلقائيًا في الوقت الفعلي باستثناء الحجوزات التي تتم من خلال عملية دمج غير متزامنة. يجب أن تكون الحجوزات التي تتم من خلال عملية دمج غير متزامنة متوافقة مع
إرشادات عمليات الدمج غير المتزامنة.
على الشركاء الالتزام بالسياسات الخاصة بميزة أو مجال معيّن في "مركز الإجراءات" (العروض والدفع والخدمات على الإنترنت والشراء في المطاعم).
على الشريك الحفاظ على محتوى بجودة عادية لاسم التاجر وعنوانه واسم الخدمات ووصفها وفقًا للإرشادات.
translation: human page_type: lcat
سياسة العروض
الصفحة المقصودة (الصفحة والتطبيق المتوافقَين مع الأجهزة الجوّالة)
- يجب أن تكون جميع العروض الترويجية التي تتم مشاركتها مع Google لأي مطعم مرئية مع كل
المعلومات ذات الصلة على الأقل في الصفحة المقصودة للأجهزة الجوّالة.
- يجب أن تكون قيمة العرض ونص الوصف مرئيَين على الصفحة المقصودة
بشكل مباشر.
- يجب أن توضّح الصفحات المقصودة بوضوح وشمول متطلبات أهلية كل عرض. ويشمل ذلك القيود المتعلقة بتصنيفات
المستخدمين وطرق الدفع وأيّ أيام أو أوقات محدّدة والحدّ الأدنى لمبلغ
الإنفاق وعدد المرات التي يمكن فيها استخدام العرض.
- يجب أن تكون جميع القيود الأخرى المفروضة على العرض (مثل شروط الأهلية وتعليمات الاستفادة
والأحكام …) مرئية على الصفحة المقصودة أو يمكن الوصول إليها
بنقرة واحدة من الصفحة المقصودة (مثل مربّع حوار منبثق).
- بالنسبة إلى جميع العروض باستثناء عروض
OFFER_MODE_WALK_IN
، يجب أن يسمح تسلسل الإجراءات
المرتبط بالعرض (مثل حجز طاولة) للمستخدم بتحديد العروض السارية المرتبطة بخياره (مثل بالنسبة إلى
الحجز، تنطبق العروض على خانة الوقت وعدد الأشخاص في المجموعة المحدّدَين)
- يجب أن تكون تعليمات الاستفادة من العرض وطرقه واضحة وقابلة للتنفيذ
(على سبيل المثال، إذا كان الاستفادة من العرض يتطلّب دفع الفاتورة على نظام الشريك
عند الدفع، يجب ذكر تعليمات الدفع على النظام
ويجب أن يتمكّن المستخدم من دفع الفاتورة على نظام الشريك عند الدفع).
- عندما يعيد عنوان URL للعرض توجيه المستخدمين إلى تطبيق مُثبَّت على جهاز جوّال تابع للشريك، يجب أن تستوفي
الصفحة المقصودة للتطبيق جميع المتطلبات الموضّحة في
هذا القسم للصفحات المقصودة للعروض.
- عند الرجوع (مثلاً، باستخدام زر الرجوع أو التنقل بالإيماءات)
بعد التفاعل مع عرض في تجربة Google مباشرةً،
يجب إعادة المستخدمين إلى تجربة Google الأصلية.
بيانات العروض وتنسيقها
- على الشركاء الالتزام بالمتطلبات الفنية المحدّدة وتنسيقات البيانات
الموضّحة في المستندات ذات الصلة. وقد يؤدي عدم استيفاء هذه
المتطلبات إلى حدوث أخطاء أو تأخيرات في معالجة الخلاصة.
- يجب أن يكون العرض متاحًا بشكل عام لأي مستخدم. قد تتطلّب العروض الترويجية اشتراكًا مدفوعًا، شرط أن يكون بإمكان أي مستخدم الاشتراك.
- يجب أن تكون جميع البيانات الوصفية المقدَّمة دقيقة وحديثة في وقت تحميل الخلاصات (يجب تحميلها يوميًا على الأقل). يجب أن تكون العروض المدرَجة نشطة و
متاحة للمستخدمين فورًا أو مسبقًا كما هو موضّح باستخدام
ValidityPeriod
، ويجب إزالة العروض القديمة أو التي نفدت أو انتهت صلاحيتها
من الخلاصة.
- يجب أن يستخدم الشركاء تنسيقات عروض متسقة على جميع المنصات. يُحظر وجود اختلافات
بين تفاصيل العرض في الخلاصة والتفاصيل المعروضة على تطبيق
أو موقع إلكتروني الشريك.
- على الشركاء تقديم تفاصيل واضحة وموجزة عن العرض في حقل
offer_display_text
، مع الإشارة بدقة إلى قيمة العرض وأي
قيود.
- على الشركاء الإشارة بوضوح إلى فئة العرض (عرض أساسي أو عرض تكميلي
) وأوضاع العرض السارية (
OFFER_MODE_FREE_RESERVATION
،
OFFER_MODE_PAID_RESERVATION
، OFFER_MODE_WALK_IN
) لكل عرض.
- على الشركاء التأكّد من تعيين أنواع وسائل الدفع بدقة لكل
عرض.
سياسة قائمة الطعام ومتطلباتها
يُرجى قراءة معايير الأهلية التالية للدمج قبل بدء عملية دمج. على الشركاء الالتزام بسياسات قوائم الطعام واستيفاء
المتطلبات التالية ليكونوا مؤهّلين للدمج. يُرجى العِلم أنّ Google
تحتفظ بالحق في عرض بيانات القائمة والأطباق بطرق مفيدة للمستخدمين.
قد يؤدي عدم استيفاء المتطلبات والسياسات إلى تعليق عملية الدمج أو تعليق التجار
أو الخدمات أو إزالتها من المنصة.
السياسات والمتطلبات
- يجب ألا يرسل الشركاء معلومات محظورة (راجِع التفاصيل)
في خلاصة القائمة، مثل اللغة النابية أو الصور المحظورة أو معلومات تحديد الهوية الشخصية
أو المحتوى الذي ينشئه المستخدمون.
- يجب ألا يستخدم الشركاء خلاصة القائمة لمشاركة عناصر غير مدرجة في القائمة، مثل الخدمات
(مثل خدمة استلام الطلبات من السيارة والرموز الترويجية وما إلى ذلك).
- على الشركاء تقديم جميع البيانات المطلوبة في مواصفات قائمة الحجوزات من البداية إلى النهاية أو مواصفات قائمة إعادة التوجيه للطلب
(الحد الأقصى لحجم الملف هو 2 ميغابايت). يتمّ تناول المتطلبات الفنية في مواصفات قائمة الحجوزات من البداية إلى النهاية أو مواصفات قائمة إعادة التوجيه للطلبات
من خلال وضع علامة على الحقول على أنّها اختيارية/مطلوبة.
- يجب أن يوفّر الشركاء عناصر القائمة المتوفّرة في مواقع المطاعم المعنيّة فقط.
- على الشركاء إرسال قائمة طعام كاملة لكل موقع جغرافي. قد لا يكون التجار الذين لديهم قوائم طعام غير مكتملة مؤهّلين للعرض.
- على الشركاء والتجّار التأكّد من دقة قوائم الطعام ويجب
إجراء التعديلات عليها يوميًا.
- يجب أن تكون صور عناصر القائمة مُضاءة جيدًا وأن تعرض عنصرًا واحدًا واضحًا في القائمة، ويجب ألا
تتضمّن صورًا لأشخاص أو صورًا أخرى غير غذائية، ويجب أن تكون متوافقة مع مواصفات الصور (اطّلِع على إرشادات الصور).
- يجب عرض الأسعار لكل عنصر في القائمة بدون إضافة مبالغ إضافية مثل الإكراميات أو الضرائب أو الرسوم، ما لم يكن ذلك مطلوبًا بموجب القوانين واللوائح المحلية. على الشركاء تقديم العملة المحلية صراحةً.
- تتوفّر قوائم الطعام الخاصة، ويجب إزالتها عندما لا تكون متاحة
(مثل قائمة الطعام الثابتة أو القائمة الموسمية أو القائمة الخاصة بفترة محدودة).
سياسات إعادة التوجيه للدفعات
يحدّد هذا القسم السياسات العامة والخاصة بالميزات لتطبيق إعادة توجيه الدفعات في "مركز الإجراءات". لضمان تقديم تجربة متّسقة
للمستهلكين والتجار والشركاء الذين يستخدمون "مركز الإجراءات"، يجب أن يلتزم المستودع الذي يتطلب الدفع بالإرشادات المناسبة. سيؤدي عدم الالتزام بهذه السياسات إلى تعليق عملية الدمج.
بنود عامة
تنطبق هذه السياسات على جميع معاملات الدفعات والمستودع الإعلاني في ميزة "الحجز من خلال Google":
- يجب أن يكون المبلغ الذي يتم تحصيله من المستخدم هو المبلغ نفسه المحدّد في بنود
المعاملة، بما يتوافق مع القوانين السارية.
- يتحمّل الشركاء مسؤولية تعديل مدى التوفّر باستخدام ميزة "التعديل في الوقت الفعلي"
(RTU) أو التأكّد من أنّ المكالمات إلى
BatchAvailabilityLookup
تعكس مدى توفّر الفترات
بدقة.
- يجب عدم تحصيل أي رسوم من المستخدم مقابل أي معاملات تتطلّب استخدام بطاقة الائتمان.
- يجب عدم تحصيل أي رسوم من المستخدم بدون موافقته الصريحة عند
الدفع، وذلك وفقًا لما هو موضّح في عملية ضبط الدفع.
- لا تستوفي بنود الدفع الواردة في صفحة بنود الخدمة المرتبطة هذا الشرط.
- بالنسبة إلى الخدمات التي تُقدَّم وجهًا لوجه1، يجب إجراء جميع الدفعات عند الحجز أو
شخصيًا فقط. ويُحظر بشدة طلب الدفع بأي وسيلة أخرى.
- يجب عرض المعاملة وتحصيل رسومها بعملة الموقع الجغرافي
للتاجر (يتم تحديد العملة باستخدام عملية
إعداد الدفعات). قد لا يتم إجراء أي عمليات تحويل عملات.
1. جميع الخدمات التي تُقدَّم شخصيًا، باستثناء الخدمات المقدَّمة من خلال عملية التكامل هذه، مثل الدفعات المسبقة والودائع
متطلبات الصفحة المقصودة
- يجب أن تكون الصفحة المقصودة هي بداية عملية الحجز مع تحديد حجم المجموعة
ووقت الحجز مسبقًا.
- يجب ألا تكون الصفحة المقصودة هي الصفحة الرئيسية لمقدّم المنصة أو أي صفحات
أخرى.
- لا يمكن أن تكون الخطوة الأولى من الصفحة المقصودة التي يتم الوصول إليها من خلال رابط يؤدي إلى صفحة في التطبيق أو الموقع الإلكتروني هي جدار دفع،
حيث لا يمكن للمستخدمين الاطّلاع على البيانات الوصفية ذات الصلة بحجزهم ما لم يتم
تقديم تفاصيل الدفع.
- لا يمكن أن تكون الخطوة الأولى للصفحة المقصودة المرتبطة بصفحة معيّنة هي صفحة تسجيل الدخول.
يجب أن تتضمّن عملية الحجز خيار الدفع كضيف، حيث يمكن للمستخدمين إكمال
الحجز بدون تسجيل الدخول أو إنشاء حساب.
- لا يمكن أن يتطلّب الرابط والصفحة المقصودة من المستخدم تنزيل تطبيق لإكمال عملية الحجز.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-03-27 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-03-27 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003ePartners must adhere to data privacy regulations, possess real-time merchant availability, and support online cancellations to integrate with the Actions Center.\u003c/p\u003e\n"],["\u003cp\u003ePartners need comprehensive merchant inventory, including 30+ days of availability, and comply with payment and pricing policies.\u003c/p\u003e\n"],["\u003cp\u003eAll bookings must be confirmed in real-time (except for asynchronous integrations) and partners must meet technical, support, and maintenance guidelines.\u003c/p\u003e\n"],["\u003cp\u003eOffer details must be clearly displayed, generally available, and menu feeds must exclude prohibited content and adhere to specified requirements.\u003c/p\u003e\n"],["\u003cp\u003ePayments must align with transaction terms, respect user consent, occur at booking or in-person (for in-person services), and landing pages must facilitate seamless booking flows without login or app download requirements.\u003c/p\u003e\n"]]],["Partners integrating with Actions Center's Reservations End-to-End must adhere to specific policies. Key actions include: managing user data compliantly with GDPR, having real-time access to merchant availability, and providing comprehensive inventory with at least 30 days of availability. Online cancellation, accurate pricing, and meeting technical requirements are mandatory. Partners must present offers clearly on landing pages, ensure offers are widely accessible, and use consistent data formats. Menu feeds require accurate, complete information and adherence to content guidelines. Payment transactions must be transparent and in the local currency. Landing pages for bookings must start with preselected details and include a guest checkout option.\n"],null,["# Reservations End-to-End Integration Policies\n\nThe following integration policies apply to the Reservations End-to-End\nintegration.\n\nEnd-to-End Policies\n-------------------\n\nPlease read through the following integration eligibility criteria before\nbeginning an integration. Partners must meet the following requirements and\npolicies to be eligible to integrate with the Actions Center's\n[Reservations End-to-End integration](/actions-center/verticals/reservations/e2e/policies/platform-policies#merchant_and_service_eligibility).\n\nWhile the following requirements are necessary components of eligibility for the Actions Center program, meeting the requirements does not guarantee a partner will be eligible to integrate or go live with the Actions Center.\n\nFailure to meet the requirements and policies may result in integration, merchant or services being suspended or removed from the platform.\n\n### General Platform Requirements\n\n1. Partners must collect and handle all merchant and user data, including any personally identifiable information, in a manner compliant with the General Data Protection Regulation (GDPR) and any other applicable privacy laws.\n2. Partners must be authorized to make bookings on behalf of their merchants.\n3. Partners must have direct access to merchants' availability/time slots in real time (ie. partners must be able to respond to availability requests from Google in less than 1 second).\n\n - *Special case*: We do support reservations that require asynchronous confirmation from the merchant, but the reservation flow must be based on an available time slot. Partners must have real time availability, i.e. through merchant online systems, even if it requires confirmation from the merchant to finalize the reservation.\n4. Partners must have comprehensive inventory for their merchants. Merchants with partial or distressed inventory may not be eligible.\n\n5. Partners must have 30 days or more of merchants' availability.\n\n6. Partners must support online cancellation of bookings.\n\n7. Partners requiring pre-payments must abide by the Actions Center's [payment policy](/actions-center/verticals/reservations/e2e/policies/integration-policies#payments-policies), their payment processors must be in the following [supported list](/pay/api) and accept tokenized payments.\n\n8. Partners must be able to provide accurate pricing data for the cost of services and abide by the Actions Center's [pricing policy](/actions-center/verticals/reservations/e2e/policies/integration-policies#pricing-policies).\n\n9. Partners must be able to meet the Actions Center technical\n [Reservations End-to-End integration](/actions-center/verticals/reservations/e2e/overview)\n requirements.\n\n10. Partners must abide by the Actions Center's [merchant and services eligibility requirements](/actions-center/verticals/reservations/e2e/policies/platform-policies#merchant_and_service_eligibility).\n\n11. Partners must abide by the Actions Center's [support and maintenance guidelines](/actions-center/verticals/reservations/e2e/policies/platform-policies#support_and_maintenance_guidelines).\n\n12. Partners must maintain acceptable error rates defined in\n [Launch and Monitoring guidelines](/actions-center/verticals/reservations/e2e/integration-steps/launch-and-monitoring).\n\n13. All bookings must be confirmed automatically in real time with the exception of bookings made with an async integration. Bookings made through an async integration must adhere to the\n [Async guideline](/actions-center/verticals/reservations/e2e/add-ons/add-async).\n\n14. Partners must abide by the Actions Center's vertical or feature specific policies ([Offers](/actions-center/verticals/reservations/e2e/policies/integration-policies#offers-policy), [Payment](/actions-center/verticals/reservations/e2e/policies/integration-policies#payments-policies), [Online services](/actions-center/policies/virtual-policy) and [Dining](/actions-center/verticals/reservations/e2e/policies/integration-policies#dining-policies)).\n\n15. Partner must maintain standard quality content for merchant name, address, services name and description per [guideline](/actions-center/verticals/reservations/e2e/policies/platform-policies#content_quality_standards).\n\nFood Menu Policy and Requirements\n---------------------------------\n\nPlease read through the following integration eligibility criteria before beginning\nan integration. Partners must adhere to the food menu policies and meet the\nfollowing requirements to be eligible to integrate. Please note that Google\nreserves the right to display menu \\& dish data in ways that are helpful to users.\n\nFailure to meet the requirements and policies may result in integration, merchants\nor services being suspended or removed from the platform.\n\n### Policy and Requirements\n\n1. Partners must not send prohibited information (see [details](https://support.google.com/contributionpolicy/answer/7400114?ref_topic=7422769)) in menu feed such as foul language, prohibited images, personally identifiable information (PII) or user generated content.\n2. Partners should not use the menu feed to share non-menu items such as [services](/actions-center/verticals/reservations/e2e/reference/feeds/services-feed) (ex: curbside, promotion codes, etc.).\n3. Partners are required to provide all required data in [Reservations E2E menu spec](/actions-center/verticals/reservations/e2e/add-ons/add-menus/menu-feed) or [Ordering Redirect menu spec](/actions-center/verticals/reservations/e2e/reference/menu-feeds/menus-feed) (max file size 2MB). The technical requirements are addressed in the [Reservations E2E menu spec](/actions-center/verticals/reservations/e2e/add-ons/add-menus/menu-feed) or [Ordering Redirect menu spec](https://developers.google.com/actions-center/verticals/reservations/e2e/reference/menu-feeds/menus-feed) by marking fields as optional/required.\n4. Partners should only provide menu items available for the corresponding restaurant locations.\n5. Partners must send a complete menu for each location. Merchants with incomplete menus may not be eligible for display.\n6. Partners and merchants are required to ensure menus are accurate and should provide updates on a daily basis.\n7. Menu items photos should be well-lit, feature one in-focus menu item, must not include people or other non-food images, and must conform to image spec (see [photo guidelines](https://support.google.com/business/answer/6103862#photo-guidelines&zippy=%2Cphoto-guidelines)).\n8. Prices should be shown, per menu item, without tips, taxes or fees; unless required by local laws and ordinances. Partners must explicitly provide local currency.\n9. Specialty menus are supported and should be removed when no longer available (ex: prix fixe, seasonal, limited time specials).\n10. Merchants are required to provide menus in a text-based format, enabling users to select and add items to their order. Menus presented solely as images are not permitted.\n\nPayments Redirect Policies\n--------------------------\n\nThis section specifies the general and feature-specific policies for\nimplementing [payments redirect](https://developers.google.com/actions-center/verticals/reservations/e2e/add-ons/add-payments-redirect/overview) on the Actions Center. To create a consistent\nexperience for consumers, merchants, and partners using the Actions Center,\ninventory requiring payment must adhere to the appropriate guidelines. Failure\nto adhere to these policies will lead to suspension of your integration.\n\n### General\n\nThese policies apply to all payment dependent inventory on Reserve with Google:\n\n1. The amount charged to a user must be the same amount specified in the terms of the transaction, in compliance with applicable laws.\n2. Partners are responsible for updating availability using a real-time update (RTU) or ensuring `BatchAvailabilityLookup` calls reflect accurate slot availability.\n3. No charges should be made to a user that are not explicitly agreed to at checkout, as articulated using our payments configuration process.\n - Payment terms contained within the linked Terms of Service page do not satisfy this requirement.\n - No charges should be made to the user for any 'credit-card required' transactions that are solely meant to authenticate a user.\n4. For in-person services^1^, all payments must occur at the time of booking or in-person only. Solicitation of payment by any other means is strictly prohibited.\n5. The transaction must be displayed and charged in the currency of the location of the merchant (currency is specified using the payments configuration process). No currency conversions may take place.\n\n^1. All in-person services, not counting those provided through this\nintegration such as prepayments and deposits^\n\n### Landing Page Requirements\n\n1. The landing page must be the start of the booking flow with the party size and time slot preselected.\n - If the table slot selected is no longer available, this should be clearly communicated to the user upfront, prior to any required step for checkout or account login.\n2. The landing page must not be the platform provider's homepage, a login page, or any other pages.\n3. The first step of the deep linked landing page cannot be a paymentwall, where users cannot view related metadata of their reservation unless they provide payment details.\n4. To provide an optimal and seamless user experience, within the booking flow we recommend providing a Guest Checkout option when possible.\n5. The linkout and landing page cannot require that the user download an app to complete the booking flow."]]