पेमेंट को कॉन्फ़िगर करना

Reserve with Google प्लैटफ़ॉर्म, पेमेंट लेने के लिए कई तरह के कॉन्फ़िगरेशन की सुविधा देता है. पेमेंट गाइड चालू करने में, इंटिग्रेशन के वे सभी पहलू शामिल होते हैं जो सभी पेमेंट्स इंटिग्रेशन के लिए आम हैं. इनमें ये बातें भी शामिल हैं:

  1. tokenization_parameter की जानकारी शामिल करने के लिए, फ़ीड कॉन्फ़िगर की जा रही हैं
  2. payment_method_token ऑब्जेक्ट स्वीकार करने के लिए बुकिंग सर्वर को अपडेट किया जा रहा है
  3. उपयोगकर्ता, Reserve with Google, पार्टनर / व्यापारी/कंपनी, और पेमेंट प्रोसेस करने वाली कंपनी के बीच हुई जानकारी की खास जानकारी.

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

  1. पैसे नहीं / आने पर पेमेंट करें
  2. पहले ही पूरा पेमेंट
  3. शो का शुल्क / रद्द करने का शुल्क
  4. जमा

पेमेंट के सभी उपयोग मामले, नो पेमेंट / पे-ऑन-अराइवल यूज़ केस (जो किसी पेमेंट कॉन्फ़िगरेशन की ज़रूरत नहीं होती है) के एक्सटेंशन होते हैं. इसलिए, यह ट्यूटोरियल उस कॉन्फ़िगरेशन के बारे में जानकारी से शुरू होगा और अन्य कॉन्फ़िगरेशन को एक्सटेंशन के तौर पर मानेगा.

हर सेक्शन, खास बुकिंग कॉन्फ़िगरेशन को स्वीकार करने के लिए, बुकिंग सर्वर में ट्रैक किए जाने वाले फ़ील्ड को भी कवर करेगा.

पैसे नहीं / आने पर पेमेंट करें

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

यह सेवा के लिए बेसलाइन कॉन्फ़िगरेशन है, जिसमें नाम, ब्यौरा, और कीमत होती है. यह ServiceFeed के अंदर एक सेवा मैसेज होगा:

JSON

{
    "merchant_id": "merchant-1",
    "service_id": "reservation",
    "name": "reservation",
    "description": "Food reservation"
}

आने वाले समय में पेमेंट करने की सुविधा देने के लिए, बुकिंग सर्वर पर सामान्य तरीके से ज़्यादा कॉन्फ़िगरेशन करने की ज़रूरत नहीं है.

नो-शो शुल्क

अगर वे बुकिंग के दौरान हिस्सा नहीं लेते हैं या उनसे रद्द करने की विंडो के बाद रद्द कर दिया जाता है, तो उनसे शुल्क नहीं लिया जा सकता. अगर कोई रद्द करने की विंडो तय नहीं की गई है, तो यह डिफ़ॉल्ट रूप से स्लॉट के शुरू होने के समय पर सेट होगी.

अगर विज्ञापन नहीं दिखाना है, तो सेवा फ़ीड में आपको no_show_fee फ़ील्ड शामिल करना होगा, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है:

JSON

{
    "merchant_id": "merchant-1",
    "service_id": "service-2-b",
    "name": "Spa Treatment",
    "description": "A full spa treatment",
    "price": {
        "price_micros": 200000000,
        "currency_code": "USD"
    }
    "scheduling_rules": {
        "min_advance_online_canceling": 14400,
    }
    "no_show_fee": {
        "fee": {
            "price_micros": 25000000,
            "currency_code": "USD"
        }
        "fee_type": "FIXED_RATE_DEFAULT"
    }
}

ऊपर दिए गए उदाहरण में, अगर पार्टनर ने अपॉइंटमेंट बुक नहीं किया है, तो पार्टनर या व्यापारी या कंपनी को no_show_fee.fee.price_micros फ़ील्ड में बताए गए, 25 डॉलर का तय शुल्क देना होगा. यह शुल्क भी तब लिया जा सकता है, जब उपयोगकर्ता अपॉइंटमेंट से चार घंटे (14,400 सेकंड) के अंदर सदस्यता रद्द कर दे. इसके बारे में scheduling_rules.min_advance_online_canceling फ़ील्ड में बताया गया है.

खरीदारी के लिए उपलब्धता के स्तर पर, शुल्क न दिखाने का तरीका जानने के लिए, यह सेक्शन देखें.

बिना शुल्क की सदस्यता के लिए, शुल्क को इस तरह से कॉन्फ़िगर किया जा सकता है कि बुकिंग के लिए, हर व्यक्ति से शुल्क लिया जाए. इस मामले में, no_show_fee.fee.fee_type को PER_PERSON पर सेट किया जा सकता है.

बुकिंग सर्वर

नो-शो शुल्क वाले अनुरोध को प्रोसेस करने पर, आपके बुकिंग सर्वर को payment_processing_parameters.unparsed_payment_method_token फ़ील्ड के ज़रिए CreateBooking को कॉल करने के लिए, पेमेंट टोकन पास किया जाता है. इस टोकन को उसी तरह से पास किया जाता है जिस तरह प्रीपेड मामले में पास किया जाता है. हालांकि, टोकन कुछ समय के लिए ही मान्य होता है. इसलिए, आपको इस टोकन को किसी ऐसे वर्शन में अपग्रेड करने के लिए, अपने पेमेंट प्रोसेस करने वाली कंपनी से जुड़े एपीआई को कॉल करना होगा. इसे बाद में इस्तेमाल करने के लिए जारी रखा जा सकता है. इसके बारे में नो-शो शुल्क टोकन फ़्लो पर, 'पैसे चुकाने की सुविधा चालू करें' सेक्शन में दिया गया है.

CreateBookingResponse देते समय, booking.payment_information फ़ील्ड को 'नहीं दिखाए जाने' की स्थिति में वापस लाने के लिए, ठीक से सेट किया जाना चाहिएCreateBookingResponse. इसका उदाहरण नीचे दिया गया है.

JSON

{
    "prepayment_status": "PREPAYMENT_PROVIDED",
    "payment_processed_by": "PROCESSED_BY_PARTNER",
    "payment_transaction_id": "[this-transaction-id]",
    "price": {
        "price_micros": "200000000",
        "currency_code": "USD"
    }
    "no_show_fee": {
        "fee": {
            "price_micros": 25000000,
            "currency_code": "USD"
        }
        "fee_type": "FIXED_RATE_DEFAULT"
    }
}

ध्यान दें कि no_show_fee कीमत और शुल्क की जानकारी देने के लिए सेट किया गया है. साथ ही, यह भी ध्यान रखें कि पहले से पैसे चुकाने के उदाहरण की तरह ही, इस मैसेज में भी transaction_id डालना ज़रूरी है.

यह भी ध्यान रखें कि CreateBookingResponse में सेट किया गया booking_id, रीयल-टाइम अपडेट के लिए ज़रूरी फ़ील्ड है. इसलिए, आपको यह शुल्क दिखाना होगा. यह आईडी, बुकिंग की जानकारी के साथ स्टोर होगा.

रीयल-टाइम अपडेट

अगर कोई उपयोगकर्ता, शेड्यूल की गई बुकिंग के लिए नहीं आता है या बुकिंग रद्द करने के बाद रद्द कर देता है (उदाहरण के लिए, सीधे आपसे संपर्क करके), तो इसके अलावा, पेमेंट के लिए जो जानकारी आपने नहीं दी है, उसका इस्तेमाल करके शुल्क लिया जा सकता है. अगर आप नहीं आए, तो आपको शुल्क देना होगा. इसके लिए, आपको रीयल-टाइम अपडेट भेजना होगा, जिसमें बताया गया होगा कि न पहुंचने का शुल्क लिया गया.

CreateBooking से की गई बुकिंग के लिए, notification.partners.bookings.patch पर अपडेट भेजा जाना चाहिए. इस अनुरोध के मुख्य हिस्से में अपडेट की गई बुकिंग होनी चाहिए. इसकी स्थिति NO_SHOW_PENALIZED पर सेट होनी चाहिए. इस जानकारी से Google को पता चलता है कि शुल्क लिया गया है.

उदाहरण के लिए, इसे अनुरोध भेजा जा सकता है:

PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status

अनुरोध के मुख्य हिस्से में:

JSON

{
    "name": "partners/12345678/bookings/123123123"
    "merchantId": "merchant-1"
    "serviceId": "service-2-b"
    "status": "NO_SHOW_PENALIZED"
}

जमा

डिपॉज़िट का इस्तेमाल, शुरुआती शुल्क लेने के लिए किया जाता है. डिपॉज़िट के लिए, बुकिंग करते समय या बाद में पैसे लिए जा सकते हैं. आपको इस बात की जानकारी देनी पड़ सकती है कि कौनसी रकम डिपॉज़िट के लिए रिफ़ंड की जा सकती है. साथ ही, आपको यह भी बताना होगा कि बुकिंग को ऑनलाइन कब रद्द किया जा सकता है.

डिपॉज़िट सबमिट करने के लिए, सेवा फ़ीड में deposit फ़ील्ड को शामिल करें, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है:

JSON

{
    "merchant_id": "merchant-1",
    "service_id": "service-2-b",
    "name": "Spa Treatment",
    "description": "A full spa treatment",
    "price": {
        "price_micros": 200000000,
        "currency_code": "USD"
    }
    "scheduling_rules": {
        "min_advance_online_canceling": 86400,
    }
    "deposit": {
        "deposit": {
            "price_micros": 25000000,
            "currency_code": USD,
            "min_advance_cancellation_sec": 14400,
        }
        "deposit_type": "FIXED_RATE_DEFAULT"
    }
}

इस उदाहरण में, min_advance_online_canceling रद्द करने की समयसीमा तय करता है और deposit.min_advance_cancellation_sec यह बताता है कि पैसे कब वापस किए जा सकते हैं. ध्यान दें कि ऊपर दिए गए उदाहरण में डिपॉज़िट राशि, रिफ़ंड की शर्तों से अलग एक रद्द करने का समय बता सकती है. ऐसे मामले में, उपयोगकर्ता इस सेवा को 24 घंटे पहले तक ऑनलाइन रद्द कर सकता है (86,400 सेकंड). इससे व्यापारी या कंपनी को, बुकिंग रद्द होने की सूचना सीधे दे दी जाती है. हालांकि, हो सकता है कि उपयोगकर्ता को रिफ़ंड मिल सके, लेकिन यह बुकिंग से चार घंटे पहले (14,400 सेकंड) तक जमा करने पर वापस मिल जाएगा. यह जानकारी चेकआउट के समय और पुष्टि करने वाले ईमेल में दी जाएगी.

खरीदारी के लिए उपलब्धता के लेवल को किस तरह तय किया जा सकता है, यह देखने के लिए यह सेक्शन देखें.

यह भी ध्यान रखें कि विज्ञापन न दिखाने की सुविधा की मदद से, डिपॉज़िट के लिए एक तय दर या हर व्यक्ति के हिसाब से शुल्क लिया जा सकता है. इस मामले में, "deposit_type": "FIXED_RATE_DEFAULT" के हिसाब से, डिपॉज़िट की दर 25 डॉलर है. अगर बुकिंग में पार्टी का साइज़ शामिल है, तो "deposit_type": "PER_PERSON" को सेट करके, इस डिपॉज़िट को हर व्यक्ति के लिए जमा की गई रकम के तौर पर दिखाया जा सकता है.

बुकिंग सर्वर

पैसे जमा करने के अनुरोध को प्रोसेस करते समय, payment_processing_parameters.unparsed_payment_method_token फ़ील्ड के ज़रिए आपके बुकिंग सर्वर को CreateBooking पर कॉल करने के लिए पेमेंट टोकन पास किया जाता है. यह टोकन पहले के केस की तरह ही पास किया जाता है. अगर बुकिंग के समय, पैसे जमा किए जाते हैं या कुछ समय के लिए पेमेंट पर रोक लगाई जाती है, तो इस अनुरोध के दौरान ऐसा किया जा सकता है.

अगर आपको बाद में पेमेंट जमा करना हो, क्योंकि टोकन की पुष्टि थोड़े समय के लिए ही की जाती है, तो आपको अपने पेमेंट प्रोसेस करने वाली कंपनी से जुड़े एपीआई को कॉल करके, इस टोकन को ऐसे वर्शन में अपग्रेड करना होगा जिसका इस्तेमाल बाद में किया जा सके. इस बारे में जमा टोकन फ़्लो पर, 'पेमेंट की सुविधा चालू करें' सेक्शन में दिया गया है.

CreateBookingResponse देते समय, booking.payment_information फ़ील्ड में सही तरीके से डिपॉज़िट की स्थिति बताई जानी चाहिए. जैसा कि नीचे दिए गए उदाहरण में बताया गया है.

JSON

{
    "prepayment_status": "PREPAYMENT_PROVIDED",
    "payment_processed_by": "PROCESSED_BY_PARTNER",
    "payment_transaction_id": "[this-transaction-id]",
    "price": {
        "price_micros": "200000000",
        "currency_code": "USD"
    }
    "deposit": {
        "deposit": {
            "price_micros": 25000000,
            "currency_code": USD,
            "min_advance_cancellation_sec": 28800,
        }
        "deposit_type": "FIXED_RATE_DEFAULT"
    }
}

ध्यान दें कि डिपॉज़िट को शुल्क या होल्ड किए गए डिपॉज़िट की कीमत और स्ट्रक्चर को दिखाने के लिए सेट किया गया है. साथ ही, यह भी ध्यान रखें कि पहले से पैसे चुकाने के उदाहरण की तरह ही, इस मैसेज में भी transaction_id डालना ज़रूरी है.

रीयल-टाइम अपडेट

अगर उपयोगकर्ता, डिपॉज़िट रद्द करने से पहले बुकिंग रद्द कर देता है, तो आपको उपयोगकर्ता के कार्ड से ऐसी किसी भी रकम का रिफ़ंड करना होगा जो आपने ली है. डिपॉज़िट का रिफ़ंड देते समय, आपको रीयल-टाइम अपडेट भेजना होगा, जिसमें बताया गया होगा कि डिपॉज़िट रिफ़ंड किया गया.

CreateBooking से की गई बुकिंग के लिए, notification.partners.bookings.patch पर अपडेट भेजा जाना चाहिए. इस अनुरोध के मुख्य हिस्से में अपडेट की गई बुकिंग होनी चाहिए. इसकी स्थिति CANCELED और paymentInformation.prepaymentStatus फ़ील्ड को PREPAYMENT_REFUNDED पर सेट किया जाना चाहिए. इससे Google को पता चलता है कि पैसे रिफ़ंड कर दिए गए हैं.

उदाहरण के लिए, इसे अनुरोध भेजा जा सकता है:

PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status

अनुरोध के मुख्य हिस्से में:

JSON

{
    "name": "partners/12345678/bookings/123123123"
    "merchantId": "merchant-1"
    "serviceId": "service-2-b"
    "status": "CANCELED"
    "paymentInformation": {
      "prepaymentStatus": "PREPAYMENT_REFUNDED"
    }
    
}

क्रेडिट कार्ड ज़रूरी है

किसी सेवा के लिए, उपयोगकर्ता की पहचान की पुष्टि करने के लिए, क्रेडिट कार्ड की ज़रूरत पड़ सकती है. हालांकि, इसका इस्तेमाल पहले से पैसे जमा करने, जमा करने या शो की फ़ीस न दिखाने के लिए नहीं किया जाना चाहिए. अगर इस्तेमाल के ये उदाहरण ज़रूरी हैं, तो उन्हें ऊपर दिए गए तरीके से साफ़ तौर पर कॉन्फ़िगर किया जाना चाहिए. कृपया यह भी ध्यान रखें कि अक्सर क्रेडिट कार्ड की ज़रूरत पड़ने पर, इस सेवा की बुकिंग में अहम कमी आ सकती है.

चेकआउट के दौरान क्रेडिट कार्ड देने के लिए, आपको require_credit_card फ़ील्ड को REQUIRE_CREDIT_CARD_ALWAYS पर सेट करना होगा.

JSON

{
    "merchant_id": "merchant-1",
    "service_id": "reservation",
    "name": "reservation",
    "description": "Food reservation",
    "require_credit_card": "REQUIRE_CREDIT_CARD_ALWAYS"
}

बुकिंग सर्वर

क्रेडिट कार्ड की ज़रूरी शर्त वाले अनुरोध को प्रोसेस करते समय, payment_processing_parameters.unparsed_payment_method_token फ़ील्ड के ज़रिए आपके बुकिंग सर्वर को CreateBooking पर कॉल करने के लिए पेमेंट टोकन पास किया जाता है. इस टोकन को उसी तरह से पास किया जाता है जिस तरह प्रीपेड मामले में पास किया जाता है. हालांकि, टोकन कुछ समय के लिए ही मान्य होता है. इसलिए, आपको इस टोकन को किसी ऐसे वर्शन में अपग्रेड करने के लिए, अपने पेमेंट प्रोसेस करने वाली कंपनी से जुड़े एपीआई को कॉल करना होगा. इसे बाद में इस्तेमाल करने के लिए जारी रखा जा सकता है.

बुकिंग सर्वर पर जवाब देने के लिए, पैसे चुकाने के अलावा और किसी जानकारी की ज़रूरत नहीं होती.

उपलब्धता के स्तर पर कीमत में बदलाव करना

ऊपर दिए गए सभी उदाहरणों में, कीमत / शुल्क वाले स्ट्रक्चर को सेवा के स्तर पर बताया गया है. ज़्यादातर मामलों में, सेवा स्तर की कीमतों का इस्तेमाल किया जाना चाहिए. हालांकि, कुछ मामलों में, उपलब्धता के कुछ स्लॉट के लिए, पैसे चुकाने के तरीके में बदलाव करना सही होता है. उदाहरण के लिए, उपलब्धता के स्तर पर कीमतों / शुल्कों को बदलकर इन स्थितियों को मैनेज किया जा सकता है:

  • मंगलवार को किराये कम हो जाते हैं और शनिवार को बढ़ जाते हैं.
  • शो के लिए, शाम 5 से 7 बजे के बीच शो का शुल्क नहीं लिया जाएगा.
  • पार्टी में छह से ज़्यादा लोगों को पैसे जमा करने होंगे.
  • किसी खास कमरे में बुकिंग करने के लिए क्रेडिट कार्ड की ज़रूरत होती है.

पैसे चुकाने / शुल्क के हर तरीके के बारे में जानने के लिए, नीचे दी गई टेबल में फ़ील्ड का इस्तेमाल किया गया है. साथ ही, इसमें सेवा लेवल की परिभाषा को बदलने के लिए उपलब्धता फ़ीड की जानकारी भी दी गई है.

पैसे चुकाने का तरीका शुल्क / कीमत की परिभाषा ओवरराइड करने वाला?
शो का शुल्क नहीं Service.no_show_fee Availability.no_show_fee
जमा Service.deposit Availability.deposit
क्रेडिट कार्ड ज़रूरी है Service.require_credit_card Availability.require_credit_card

ध्यान दें कि उपलब्धता के लेवल पर कीमत बदलने के लिए, आपको सबसे पहले पैसे चुकाने का कोई विकल्प तय करना होगा. इसके अलावा, उपलब्धता लेवल पर सदस्यताएं रद्द करने की विंडो जोड़ने के बारे में ज़्यादा जानकारी के लिए, कृपया सदस्यता रद्द करने वाले विंडो को जोड़ने का तरीका गाइड देखें.