बुकिंग के लिए एंड-टू-एंड इंटिग्रेशन की नीतियां

नीचे दी गई इंटिग्रेशन की नीतियां, बुकिंग के लिए एंड-टू-एंड इंटिग्रेशन पर लागू होती हैं.

एंड-टू-एंड नीतियां

इंटिग्रेशन शुरू करने से पहले, कृपया इंटिग्रेशन की इन ज़रूरी शर्तों को पढ़ें. ऐक्शन सेंटर के बुकिंग का डेटा एंड-टू-एंड इंटिग्रेशन के साथ इंटिग्रेट करने के लिए, पार्टनर को ये ज़रूरी शर्तें और नीतियां पूरी करनी होंगी.

नीचे दी गई शर्तें, Actions Center प्रोग्राम में शामिल होने के लिए ज़रूरी हैं. हालांकि, इन शर्तों को पूरा करने से यह गारंटी नहीं मिलती कि पार्टनर, Actions Center को इंटिग्रेट कर पाएगा या लाइव कर पाएगा.

ज़रूरी शर्तों और नीतियों को पूरा न करने पर, इंटिग्रेशन, व्यापारी/कंपनी या सेवाओं को निलंबित किया जा सकता है या प्लैटफ़ॉर्म से हटाया जा सकता है.

प्लैटफ़ॉर्म से जुड़ी सामान्य ज़रूरी शर्तें

  1. पार्टनर को कारोबारी और उपयोगकर्ता का सारा डेटा इकट्ठा और मैनेज करना चाहिए. इसमें, व्यक्तिगत पहचान से जुड़ी जानकारी भी शामिल है. यह डेटा, जनरल डेटा प्रोटेक्शन रेगुलेशन (जीडीपीआर) और लागू होने वाले अन्य निजता कानूनों का पालन करता है.
  2. पार्टनर के पास, कारोबारियों या कंपनियों की ओर से बुकिंग करने की अनुमति होनी चाहिए.
  3. पार्टनर के पास रीयल टाइम में, कारोबारियों या कंपनियों की उपलब्धता/टाइम स्लॉट का सीधा ऐक्सेस होना चाहिए. इसका मतलब है कि पार्टनर के पास, Google से एक सेकंड से कम समय में खरीदारी के लिए उपलब्धता के अनुरोधों का जवाब देने की सुविधा होनी चाहिए.

    • खास मामला: हम ऐसी बुकिंग की सुविधा देते हैं जिनके लिए व्यापारी/कंपनी की पुष्टि की ज़रूरत नहीं होती. हालांकि, बुकिंग की प्रोसेस, उपलब्ध समय स्लॉट के आधार पर होनी चाहिए. पार्टनर के पास, बुकिंग की जगह की असल समय में उपलब्धता की जानकारी होनी चाहिए.जैसे, कारोबारी या कंपनी के ऑनलाइन सिस्टम से. भले ही, बुकिंग की प्रक्रिया पूरी करने के लिए, कारोबारी या कंपनी की पुष्टि की ज़रूरत हो.
  4. पार्टनर के पास अपने कारोबारियों या कंपनियों के लिए पूरी इन्वेंट्री होनी चाहिए. ऐसे कारोबारियों या कंपनियों को इस सुविधा का फ़ायदा नहीं मिल सकता जिनकी इन्वेंट्री में प्रॉडक्ट के सिर्फ़ कुछ हिस्से या प्रॉडक्ट की परफ़ॉर्मेंस खराब है.

  5. पार्टनर के पास कारोबारियों या कंपनियों की उपलब्धता की जानकारी 30 दिन या उससे ज़्यादा समय से होनी चाहिए.

  6. पार्टनर के पास, बुकिंग को ऑनलाइन रद्द करने की सुविधा होनी चाहिए.

  7. जिन पार्टनर को पेमेंट पहले से करना होता है उन्हें ऐक्शन सेंटर की पेमेंट से जुड़ी नीति का पालन करना होगा. साथ ही, उनके पेमेंट प्रोसेसर को यहां दी गई काम करने वाली सूची में शामिल होना होगा और टोकन के ज़रिए किए जाने वाले पेमेंट स्वीकार करने होंगे.

  8. पार्टनर के पास, सेवाओं की कीमत के लिए कीमत से जुड़ा सटीक डेटा उपलब्ध होना चाहिए. साथ ही, कार्रवाई केंद्र की कीमत तय करने की नीति का पालन करना भी ज़रूरी है.

  9. पार्टनर को, ऐक्शन सेंटर के तकनीकी बुकिंग के लिए एंड-टू-एंड इंटिग्रेशन की ज़रूरी शर्तें पूरी करनी होंगी.

  10. पार्टनर को Actions Center की व्यापारी/कंपनी और सेवाओं से जुड़ी ज़रूरी शर्तों का पालन करना होगा.

  11. पार्टनर को Actions Center के सहायता और रखरखाव से जुड़े दिशा-निर्देशों का पालन करना होगा.

  12. पार्टनर को लॉन्च और निगरानी से जुड़े दिशा-निर्देशों में बताई गई गड़बड़ी की दरें स्वीकार करनी होंगी.

  13. एसिंक इंटिग्रेशन की मदद से की गई बुकिंग को छोड़कर, रीयल टाइम में सभी बुकिंग की पुष्टि अपने-आप होनी चाहिए. एक साथ काम नहीं करने वाले इंटिग्रेशन की मदद से की गई बुकिंग, एक साथ काम नहीं करने वाले इंटिग्रेशन के दिशा-निर्देश के मुताबिक होनी चाहिए.

  14. पार्टनर को ऐक्शन सेंटर के वर्टिकल या किसी सुविधा के लिए तय की गई नीतियों (ऑफ़र, पेमेंट, ऑनलाइन सेवाएं, और डाइनिंग) का पालन करना होगा.

  15. पार्टनर को हर दिशा-निर्देश के हिसाब से, व्यापारी/कंपनी/कारोबारी के नाम, पते, सेवाओं के नाम, और ब्यौरे के लिए, स्टैंडर्ड क्वालिटी का कॉन्टेंट बनाकर रखना चाहिए.

ऑफ़र की नीति

लैंडिंग पेज

  • किसी भी रेस्टोरेंट के लिए Google के साथ शेयर किए गए सभी ऑफ़र, लैंडिंग पेज पर पूरी जानकारी के साथ दिखने चाहिए.
    • ऑफ़र की वैल्यू और ब्यौरे का टेक्स्ट, लैंडिंग पेज पर सीधे तौर पर दिखना चाहिए.
    • ऑफ़र से जुड़ी पाबंदियां, लैंडिंग पेज पर सीधे तौर पर दिखनी चाहिए. जैसे, बिल की कम से कम रकम, छूट की ज़्यादा से ज़्यादा वैल्यू, और सदस्यता की ज़रूरत.
    • ऑफ़र से जुड़ी अन्य सभी पाबंदियां (जैसे, ज़रूरी शर्तें, रिडीम करने के निर्देश, नियम वगैरह) लैंडिंग पेज पर दिखनी चाहिए या लैंडिंग पेज पर एक क्लिक में ऐक्सेस की जानी चाहिए. जैसे, पॉप-अप डायलॉग.
  • OFFER_MODE_WALK_IN ऑफ़र के अलावा, सभी ऑफ़र के लिए, ऑफ़र से जुड़े ऐक्शन फ़्लो (उदाहरण के लिए, टेबल बुक करना) में उपयोगकर्ता को, अपनी पसंद के हिसाब से लागू होने वाले ऑफ़र चुनने की अनुमति होनी चाहिए. उदाहरण के लिए, बुकिंग के लिए, चुने गए समय स्लॉट और पार्टी में शामिल होने वाले लोगों की संख्या के हिसाब से ऑफ़र
  • ऑफ़र रिडीम करने के निर्देश और तरीके साफ़ तौर पर बताए जाने चाहिए और उन पर कार्रवाई की जानी चाहिए. उदाहरण के लिए, अगर ऑफ़र रिडीम करने के लिए, चेकआउट के समय पार्टनर सिस्टम पर बिल का पेमेंट करना ज़रूरी है, तो सिस्टम पर पेमेंट करने का निर्देश दिया जाना चाहिए. साथ ही, उपयोगकर्ता को चेकआउट के समय पार्टनर सिस्टम पर बिल का पेमेंट करने की सुविधा मिलनी चाहिए.
  • अगर ऑफ़र का यूआरएल, पार्टनर ऐप्लिकेशन (अगर इंस्टॉल हो) पर रीडायरेक्ट कर सकता है, तो ऊपर बताई गई ज़रूरी शर्तें, मोबाइल ऐप्लिकेशन पेज पर भी लागू होंगी.

ऑफ़र

  • आम तौर पर, यह ऑफ़र हर उपयोगकर्ता के लिए उपलब्ध होना चाहिए. ऑफ़र के लिए, पैसे चुकाकर ली जाने वाली सदस्यता की ज़रूरत पड़ सकती है. हालांकि, यह ज़रूरी है कि कोई भी व्यक्ति सदस्यता ले सके.
  • फ़ीड अपलोड करते समय, दिया गया सारा मेटाडेटा सटीक और अप-टू-डेट होना चाहिए.
    • फ़ीड अपलोड करते समय, बिक चुके ऑफ़र, फ़ीड में शामिल नहीं किए जाने चाहिए.

खाने के मेन्यू से जुड़ी नीति और ज़रूरी शर्तें

इंटिग्रेशन शुरू करने से पहले, कृपया इंटिग्रेशन की ज़रूरी शर्तें पढ़ें. पार्टनर को फ़ूड मेन्यू की नीतियों का पालन करना होगा. साथ ही, इंटिग्रेशन की ज़रूरी शर्तें पूरी करनी होंगी. कृपया ध्यान दें कि Google के पास, मेन्यू और डिश का डेटा ऐसे तरीके से दिखाने का अधिकार सुरक्षित है जिससे उपयोगकर्ताओं को मदद मिल सके.

ज़रूरी शर्तों और नीतियों का पालन न करने पर, इंटिग्रेशन, व्यापारी/कंपनी/कारोबारी या सेवाओं को निलंबित किया जा सकता है या उन्हें प्लैटफ़ॉर्म से हटाया जा सकता है.

नीति और ज़रूरी शर्तें

  1. पार्टनर को मेन्यू फ़ीड में आपत्तिजनक भाषा, पाबंदी वाली इमेज, व्यक्तिगत पहचान से जुड़ी जानकारी (पीआईआई) या यूज़र जनरेटेड कॉन्टेंट जैसी पाबंदी वाली जानकारी (जानकारी देखें) नहीं भेजनी चाहिए.
  2. पार्टनर को मेन्यू फ़ीड का इस्तेमाल, मेन्यू में शामिल नहीं किए गए आइटम शेयर करने के लिए नहीं करना चाहिए. जैसे, सेवाएं (उदाहरण के लिए, curbside, प्रमोशन कोड वगैरह).
  3. पार्टनर को रिज़र्वेशन E2E मेन्यू की खास बातों या ऑर्डरिंग रीडायरेक्ट मेन्यू की खास बातों (ज़्यादा से ज़्यादा फ़ाइल का साइज़ 2 एमबी) में सभी ज़रूरी डेटा देना होगा. तकनीकी ज़रूरी शर्तों के बारे में बुकिंग के लिए E2E मेन्यू स्पेसिफ़िकेशन या ऑर्डर करने के लिए रीडायरेक्ट मेन्यू स्पेसिफ़िकेशन में बताया गया है. इसके लिए, फ़ील्ड को ज़रूरी/ज़रूरी नहीं के तौर पर मार्क किया जाता है.
  4. पार्टनर को सिर्फ़ रेस्टोरेंट की जगहों के मेन्यू आइटम देने चाहिए.
  5. पार्टनर को हर जगह के लिए पूरा मेन्यू भेजना होगा. जिन व्यापारियों/कंपनियों/कारोबारियों के मेन्यू अधूरे हैं वे शायद अपने प्रॉडक्ट नहीं दिखा पाएं.
  6. पार्टनर और व्यापारियों/कंपनियों/कारोबारियों को यह पक्का करना ज़रूरी है कि मेन्यू सटीक हों और उन्हें हर दिन अपडेट दिए जाने चाहिए.
  7. मेन्यू आइटम की फ़ोटो ऐसी होनी चाहिए जिनमें अच्छी रोशनी हो. साथ ही, फ़ोटो में एक मेन्यू आइटम फ़ोकस में होना चाहिए. इसमें लोगों या खाने से जुड़ी चीज़ों के अलावा कोई और चीज़ नहीं होनी चाहिए. साथ ही, यह इमेज स्पेसिफ़िकेशन के मुताबिक होनी चाहिए. फ़ोटो से जुड़े दिशा-निर्देश देखें.
  8. मेन्यू में मौजूद हर आइटम की कीमत, टिप, टैक्स या शुल्क के बिना दिखाई जानी चाहिए. हालांकि, अगर स्थानीय कानूनों और नियमों के मुताबिक ऐसा करना ज़रूरी है, तो ऐसा किया जा सकता है. पार्टनर को स्थानीय मुद्रा की जानकारी साफ़ तौर पर देनी होगी.
  9. खास मेन्यू की सुविधा काम करती है. जब ये मेन्यू उपलब्ध न हों, तब इन्हें हटा दिया जाना चाहिए. उदाहरण के लिए, प्रिक्स फ़िक्स, सीज़नल, और सीमित समय के लिए उपलब्ध खास मेन्यू.

पेमेंट रीडायरेक्ट से जुड़ी नीतियां

इस सेक्शन में, ऐक्शन सेंटर पर पेमेंट रीडायरेक्ट करने की सुविधा को लागू करने के लिए, सामान्य और सुविधा से जुड़ी नीतियों के बारे में बताया गया है. Actions Center का इस्तेमाल करने वाले उपभोक्ताओं, व्यापारियों/कंपनियों, और पार्टनर को एक जैसा अनुभव देने के लिए, शुल्क के साथ दिखाई जाने वाली इन्वेंट्री के लिए, सही दिशा-निर्देशों का पालन करना ज़रूरी है. इन नीतियों का पालन न करने पर, आपके इंटिग्रेशन को निलंबित कर दिया जाएगा.

सामान्य

ये नीतियां, Reserve with Google पर किए जाने वाले सभी पेमेंट लेन-देन और इन्वेंट्री पर लागू होती हैं:

  1. किसी उपयोगकर्ता से लिया गया शुल्क, लागू कानूनों के मुताबिक लेन-देन की शर्तों में बताई गई रकम के बराबर होना चाहिए.
  2. यह पार्टनर की ज़िम्मेदारी है कि वे रीयल-टाइम अपडेट (आरटीयू) का इस्तेमाल करके, उपलब्धता की जानकारी अपडेट करें या यह पक्का करें कि BatchAvailabilityLookup कॉल में स्लॉट की उपलब्धता की सटीक जानकारी दिखे.
  3. क्रेडिट कार्ड से किए जाने वाले किसी भी लेन-देन के लिए, उपयोगकर्ता से कोई शुल्क नहीं लिया जाना चाहिए.
  4. ऐसे उपयोगकर्ता से कोई शुल्क नहीं लिया जाना चाहिए जिसके लिए चेकआउट करते समय साफ़ तौर पर सहमति नहीं दी गई है. ऐसा, पेमेंट से जुड़े कॉन्फ़िगरेशन की हमारी प्रोसेस का इस्तेमाल करके किया गया है.
    • लिंक की गई सेवा की शर्तों वाले पेज पर दी गई पेमेंट की शर्तें, इस ज़रूरी शर्त को पूरा नहीं करती हैं.
  5. व्यक्तिगत सेवाओं1 के लिए, सभी पेमेंट बुकिंग के समय या सिर्फ़ व्यक्तिगत तौर पर किए जाने चाहिए. किसी भी दूसरे तरीके से पेमेंट का अनुरोध करने पर, आपके चैनल पर पाबंदी लगा दी जाएगी.
  6. लेन-देन की जानकारी और शुल्क, व्यापारी/कंपनी की जगह की मुद्रा में दिखना चाहिए. मुद्रा की जानकारी, पेमेंट कॉन्फ़िगरेशन की प्रोसेस का इस्तेमाल करके दी जाती है. मुद्रा बदलने की सुविधा काम नहीं करेगी.

1. व्यक्तिगत तौर पर मिलने वाली सभी सेवाएं. इसमें इस इंटिग्रेशन से मिलने वाली सेवाएं शामिल नहीं हैं, जैसे कि रिफ़ंड और डिपॉज़िट

लैंडिंग पेज की ज़रूरी शर्तें

  1. लैंडिंग पेज, बुकिंग फ़्लो की शुरुआत होना चाहिए. इसमें पहले से ही, मेहमानों की संख्या और समय स्लॉट चुना गया होना चाहिए.
  2. लैंडिंग पेज, प्लैटफ़ॉर्म देने वाली कंपनी का होम पेज या कोई दूसरा पेज नहीं होना चाहिए.
  3. डीप लिंक किए गए लैंडिंग पेज का पहला चरण, पेमेंट वॉल नहीं हो सकता. यहां उपयोगकर्ताओं को अपने बुकिंग के मेटाडेटा की जानकारी तब तक नहीं दिखती, जब तक वे पेमेंट की जानकारी नहीं देते.
  4. डीप लिंक किए गए लैंडिंग पेज का पहला चरण, लॉगिन पेज नहीं हो सकता. बुकिंग फ़्लो में, मेहमान के तौर पर चेकआउट करने का विकल्प होना चाहिए. इसकी मदद से, उपयोगकर्ता लॉग इन किए बिना या खाता बनाए बिना बुकिंग कर सकते हैं.
  5. लिंकआउट और लैंडिंग पेज पर, उपयोगकर्ता को बुकिंग की प्रोसेस पूरी करने के लिए ऐप्लिकेशन डाउनलोड करने की ज़रूरत नहीं होनी चाहिए.