SDK

वेब उपयोग के लिए, अनुशंसित तरीका निम्नलिखित कारणों से Unico SDK का उपयोग करना है:

• अधिक सुरक्षा;
• आपके फ्लो के साथ इंटीग्रेटेड एक्सपीरियंस;
• SDK का उपयोग करते समय अधिक कन्वर्ज़न रेट;
• आसान इम्प्लीमेंटेशन।

चेतावनी

इस दस्तावेज़ में स्थापित स्टैंडर्ड का पालन न करने वाले इंटीग्रेशन का उपयोग सिस्टम की फंक्शनैलिटी में अनपेक्षित व्यवधान का परिणाम हो सकता है, जिसे कार्ड नॉट प्रेजेंट सत्यापन द्वारा कवर या सपोर्ट नहीं किया जाएगा।

उदाहरण के लिए: एक webview के भीतर Unico by iFrame को इम्प्लीमेंट करना, एक HTML टैग के माध्यम से iFrame को इम्प्लीमेंट करना, आदि।

सामान्य दिशानिर्देश

अपने ऑपरेशन के परफॉर्मेंस को ऑप्टिमाइज़ करने, कन्वर्ज़न रेट में सुधार करने, और एक स्मूथ उपयोगकर्ता एक्सपीरियंस प्रदान करने के लिए, अपने एप्लिकेशन में Unico SDK को फुल-स्क्रीन मोड में इम्प्लीमेंट करना अनिवार्य है।

शुरू कैसे करें

कार्ड नॉट प्रेजेंट सत्यापन SDK के माध्यम से कार्ड नॉट प्रेजेंट सत्यापन का उपयोग करने के लिए, पहला चरण उन डोमेन को रजिस्टर करना है जिनका उपयोग उपयोगकर्ता जर्नी एक्सपीरियंस को प्रदर्शित करने के लिए होस्ट के रूप में किया जाएगा।

खतरा

इस कॉन्फ़िगरेशन को करने के लिए अपने इंटीग्रेशन प्रोजेक्ट के लिए जिम्मेदार व्यक्ति या Unico सपोर्ट टीम को सूचित करें।

SDK का उपयोग शुरू करने के लिए, हमें Unico वेब SDK के इंस्टॉलेशन से शुरुआत करनी चाहिए:

npm install idpay-b2b-sdk

टिप

Unico SDK पैकेज को इंस्टॉल करते समय, जिस वर्ज़न का आप उपयोग कर रहे हैं उसे निर्दिष्ट किए बिना डिप्लॉय करें ताकि आपका डिपेंडेंसी मैनेजर हमेशा नवीनतम वर्ज़न में minors और patches को अपडेट करे।

पिछले वर्ज़न देखने के लिए, npmjs.com/package/idpay-b2b-sdk पर जाएं।

उपलब्ध मेथड्स

init(options)

यह मेथड SDK को लेनदेन ID की परवाह किए बिना इनिशियलाइज़ करने की अनुमति देता है, जिससे end-user एक्सपीरियंस स्मूथ बनता है। ऐसा इसलिए है क्योंकि जब लेनदेन ID और token उपलब्ध होते हैं, तो एप्लिकेशन इस मेथड के माध्यम से पहले से ही प्री-लोड हो चुका होगा। यदि यह मेथड सीधे एप्लिकेशन द्वारा कॉल नहीं किया जाता है, तो जब पहली बार SDK खोला जाएगा तो end user को लंबा लोड समय अनुभव होगा।

पैरामीटर:

• options — कॉन्फ़िगरेशन प्रॉपर्टीज़ के साथ एक ऑब्जेक्ट प्राप्त करता है:
  • type — उस फ्लो का प्रकार जिसे इनिशियलाइज़ किया जाएगा। वर्तमान में, हम IFRAME प्रकार प्रदान करते हैं। नए एप्लिकेशन के लिए, हम IFRAME प्रकार का उपयोग करने की सलाह देते हैं, जो end-user एक्सपीरियंस को बहुत अधिक स्मूथ और कम फ्रिक्शन के साथ बनाता है, क्योंकि यह checkout स्क्रीन को छोड़ने की आवश्यकता से बचाता है, और एक्सपीरियंस को प्री-लोड किया जा सकता है।

import { IDPaySDK } from "idpay-b2b-sdk";

IDPaySDK.init({
  type: 'IFRAME',
  env: 'uat' // Only needed for the test environment.
});

open({ transactionId, token, onFinish? })

यह मेथड इनिशियलाइज़ेशन फ़ंक्शन में पहले चुने गए फ्लो प्रकार के अनुसार कार्ड नॉट प्रेजेंट सत्यापन एक्सपीरियंस खोलता है। REDIRECT फ्लो के लिए, यह फ़ंक्शन कार्ड नॉट प्रेजेंट सत्यापन कैप्चर फ्लो रूट पर एक सरल रीडायरेक्ट करता है। IFRAME फ्लो के लिए, यह फ़ंक्शन प्री-लोडेड iframe प्रदर्शित करता है और ग्राहक के पेज और कार्ड नॉट प्रेजेंट सत्यापन एक्सपीरियंस के बीच मैसेजिंग फ्लो शुरू करता है।

पैरामीटर:

• options — कॉन्फ़िगरेशन प्रॉपर्टीज़ के साथ एक ऑब्जेक्ट प्राप्त करता है:
  • transactionId — बनाए गए लेनदेन की ID प्राप्त करता है। लेनदेन विवरण प्राप्त करने और फ्लो को सही ढंग से पूरा करने के लिए यह ID महत्वपूर्ण है (यह API के माध्यम से लेनदेन निर्माण के दौरान प्राप्त की जा सकती है)।
  • token — बनाए गए लेनदेन के लिए token प्राप्त करता है। यह token लेनदेन को प्रमाणित करने और यह सुनिश्चित करने के लिए महत्वपूर्ण है कि केवल अधिकृत डोमेन ही इसका उपयोग करें (यह API के माध्यम से लेनदेन निर्माण के दौरान प्राप्त किया जा सकता है)।
  • onFinish(transaction, type) (वैकल्पिक) — एक कॉलबैक फ़ंक्शन प्राप्त करता है जो कार्ड नॉट प्रेजेंट सत्यापन कैप्चर फ्लो के अंत में एक्ज़ीक्यूट किया जाएगा, दो आर्ग्युमेंट पास करते हुए: लेनदेन ऑब्जेक्ट ({ captureConcluded, concluded, id }), और प्रतिक्रिया प्रकार — जिन मामलों में फ्लो सफलतापूर्वक पूरा हुआ उनके लिए FINISH, या जिन मामलों में फ्लो किसी त्रुटि के कारण बाधित हुआ उनके लिए ERROR। फ्लो में त्रुटि की स्थिति में, लेनदेन की स्थिति नहीं बदली जाएगी, और यदि कॉन्फ़िगर किया गया हो तो webhook के माध्यम से कोई कॉलबैक ट्रिगर नहीं होगा।

const transactionId = '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf';
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

const transaction = {
  id: '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf',
  concluded: true,
  captureConcluded: true
};

const onFinish = (transaction, type) => {
  console.log('response', transaction, type);
}

IDPaySDK.open({
  transactionId,
  token,
  onFinish
});

// You can also close the SDK explicitly using the method below
IDPaySDK.close();

सुरक्षा

आवश्यकताओं और चुनौतियों का सावधानीपूर्वक विश्लेषण करने के बाद, हमने Content Security Policy (CSP) को इम्प्लीमेंट करने के बजाय authentication tokens के साथ iFrames पर आधारित एक समाधान अपनाने का निर्णय लिया। यह निर्णय सुरक्षा से संबंधित कई विचारों और हमारे ग्राहकों की मांगों को पूरा करने के लिए आवश्यक लचीलेपन से प्रेरित था।

CSP के साथ संदर्भ और चुनौतियां

Content Security Policy (CSP) वेब एप्लिकेशन को Cross-Site Scripting (XSS) और कोड इंजेक्शन जैसे विभिन्न प्रकार के हमलों से बचाने के लिए एक शक्तिशाली टूल है। हालांकि, CSP पॉलिसी को कॉन्फ़िगर करते समय, विश्वसनीय डोमेन की एक सख्त सूची परिभाषित करना आवश्यक है। यह तरीका तब अच्छी तरह से काम करता है जब डोमेन निश्चित और अनुमानित हों। हालांकि, हमारे उन ग्राहकों के लिए जो अक्सर डायनामिक और परिवर्तनशील डोमेन का उपयोग करते हैं, यह कठोर कॉन्फ़िगरेशन महत्वपूर्ण चुनौतियां प्रस्तुत करता है।

डायनामिक डोमेन के साथ भेद्यता

CSP का उपयोग करते समय डायनामिक डोमेन एक महत्वपूर्ण सुरक्षा जोखिम पैदा करते हैं। जब किसी ग्राहक के डोमेन अक्सर बदलते हैं या डायनामिक रूप से बनाए जाते हैं, तो इन नए डोमेन को शामिल करने के लिए CSP पॉलिसी को लगातार अपडेट करना आवश्यक होगा। इससे न केवल मेंटेनेंस प्रयास बढ़ता है, बल्कि यह उन डोमेन को भी उजागर करता है जिन पर CSP पॉलिसी लागू होती है। CSP पॉलिसी में जोड़ा गया प्रत्येक डोमेन, यदि ठीक से मैनेज नहीं किया गया, तो संभावित रूप से भेद्यता का एक बिंदु है।

iFrame और Auth Token के साथ समाधान

इन जोखिमों को कम करने और हमारे ग्राहकों द्वारा आवश्यक लचीलेपन को पूरा करने के लिए, हमने authentication tokens के साथ मिलकर iFrames का उपयोग करने का विकल्प चुना। यह समाधान सुरक्षा की एक अतिरिक्त परत प्रदान करता है और डोमेन की एक व्यापक और डायनामिक सूची को उजागर करने या मैनेज करने की आवश्यकता को समाप्त करता है।

यह कैसे काम करता है

• सुरक्षित प्रमाणीकरण: प्रत्येक iframe को प्रत्येक लेनदेन के लिए एक यूनीक authentication token के साथ लोड किया जाता है, यह सुनिश्चित करते हुए कि केवल अधिकृत उपयोगकर्ता ही कंटेंट तक पहुंच सकें। इस token को रीयल-टाइम में सत्यापित किया जाता है, जो सुरक्षा और नियंत्रण की एक अतिरिक्त परत प्रदान करता है।
• कंटेंट आइसोलेशन: iFrames का उपयोग कंटेंट को एक अलग संदर्भ में आइसोलेट करने की अनुमति देता है, जिससे विभिन्न origins के बीच हस्तक्षेप का जोखिम कम होता है और संभावित हमलों को कम किया जाता है।
• डायनामिक डोमेन के लिए लचीलापन: एक स्टैटिक CSP पॉलिसी पर निर्भर न रहते हुए, हमारा समाधान सुरक्षा पॉलिसियों में लगातार अपडेट की आवश्यकता के बिना आसानी से ग्राहकों के डायनामिक डोमेन के अनुकूल हो जाता है।