अपने इंटिग्रेशन में 3DS1 / 3DS2 को जोड़ने का तरीका

Reserve with Google के इंटिग्रेशन के लिए, 3DS1 और 3DS2, दोनों की सुविधा उपलब्ध है. आप अपने इंटिग्रेशन पर, इनमें से किसी एक (या दोनों) को लागू कर सकते हैं.

3DS1 या 3DS2 में PSD2 की 'ग्राहक की पुष्टि' से जुड़ी कड़ी शर्तों को पूरा किया जाता है. हालांकि, दोनों में कुछ खास अंतर हैं:

  • 3DS1: जब आपके पास शुल्क धोखाधड़ी होने का सिग्नल हो, तो किसी लेन-देन के लिए 3DS1 ट्रिगर करने का फ़ैसला लिया जा सकता है.
    • 3DS1 को लागू करने के लिए, आपके बुकिंग सर्वर में बदलाव करना ज़रूरी है.
  • 3DS2: 3DS2 का इस्तेमाल सिर्फ़ उन लेन-देन के लिए किया जाएगा जहां PSD2 लागू होता है (उपयोगकर्ता हासिल करने वाले बैंक और ईईए में मौजूद ग्राहक का बैंक).
    • 3DS2 को लागू करने के लिए, आपके व्यापारी फ़ीड में बदलाव करना ज़रूरी है.

3DS2 को लागू करना

3DS को लागू करने के लिए, आपको TokenizationConfig मैसेज में व्यापारी फ़ीड में दूसरे फ़ील्ड जोड़ने होंगे. अगर सभी पेमेंट एक ही खाते में जाते हैं, तो आपको हर व्यापारी/कंपनी की एंट्री में वह वैल्यू दोहरानी होगी. पेमेंट अलग-अलग खातों में जाने की स्थिति में, हर व्यापारी/कंपनी की एंट्री में, लेन-देन की रकम पाने वाले खाते की वैल्यू होनी चाहिए.

व्यापारी फ़ीड में होने वाले बदलाव

  • merchant_of_record_name: मर्चेंट ऑफ़ रिकॉर्ड (एमओआर) का नाम. यह दिखने वाला नाम, 3DS2 चैलेंज में दिखाया जाएगा.
  • payment_country_code: वह देश जहां ISO 3166-1 ऐल्फ़ा-2 फ़ॉर्म में लेन-देन प्रोसेस किया जाएगा.
  • CardNetworkParameters मैसेज: यह मैसेज अलग-अलग नेटवर्क के लिए खास वैल्यू के साथ दोहराया जाता है (सिर्फ़ Visa और American Express के लिए ज़रूरी)
    • card_network: वह नेटवर्क (Visa, American Express) जिस पर ये वैल्यू लागू होती हैं
    • acquirer_bin: कार्ड को प्रोसेस करने के लिए इस्तेमाल होने वाले बैंक का बैंक आइडेंटिफ़िकेशन नंबर.
    • acquirer_merchant_id: व्यापारी का वह आइडेंटिफ़ायर जिसे लेन-देन की अनुमति देने के लिए, व्यापारी/कंपनी को लेन-देन की अनुमति देने के लिए असाइन किया जाता है (Visa और American Express लेन-देन के लिए).

अपने व्यापारी फ़ीड में ये फ़ील्ड जोड़ने पर, आपको unparsed_payment_method_token में 3DS2 क्रिप्टोग्राम मिलेगा. जब भी लेन-देन पर PSD2 लागू होता है, तो इसे आपके बुकिंग सर्वर पर मिलता है. आपको अपने पार्टनर के बताए गए तरीके के हिसाब से, unparsed_payment_method_token और उसके एम्बेड किए गए क्रिप्टोग्राम की पुष्टि करनी होगी.

3DS1 को लागू करना

बुकिंग सर्वर में बदलाव

हम CreateBooking का अनुरोध करेंगे. अगर आपको लगता है कि लेन-देन के लिए 3DS1 की ज़रूरत पड़ेगी, तो CreateBooking वाले तरीके से Booking Failure वापस करें. साथ ही, वजह के तौर पर PAYMENT_REQUIRES_3DS1 की जानकारी दें. इस गड़बड़ी के रिस्पॉन्स में, आपको PaymentFailureInformation मैसेज में ThreeDS1Parameters मैसेज के बारे में भी बताना होगा:

  • acs_url = वह यूआरएल जिससे उपयोगकर्ता को पुष्टि के लिए फ़ॉर्म दिखाया जाता है.
  • pa_req = पुष्टि करने के लिए पेमेंट का अनुरोध. ACSUrl फ़ॉर्म पर पोस्ट किया जाना है.
  • transaction_id = ऐसा आइडेंटिफ़ायर जिसका इस्तेमाल ACS की सेवा देने वाली कंपनी करती है. ACSUrl फ़ॉर्म पर पोस्ट किए जाने के लिए.
  • md_merchant_data = अगर रिज़र्व किया गया डेटा, ACS की सेवा देने वाली कंपनी के साथ शेयर किया जाएगा, तो उसे Google के साथ शेयर किया जाएगा.

इसके बाद, हम मूल अनुरोध CreateBooking को फिर से भेज देंगे. इसके लिए, PaymentInfo मैसेज में दिए गए pa_response का इस्तेमाल करें. pa_response फ़ील्ड में, वह पेलोड होता है जो हमें ACS की सेवा देने वाली कंपनी से मिलता है. साथ ही, इसका इस्तेमाल आप अपने प्रोसेसर के साथ लेन-देन की पुष्टि करने के लिए करते हैं.

यहां 3DS1 फ़्लो का ब्यौरा देने वाला डायग्राम दिया गया है:

इमेज 1: 3DS1 प्रोसेस डायग्राम
पहली इमेज: 3DS1 प्रोसेस का डायग्राम