मुख्य सामग्री पर जाएं

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

मान लें कि एक उपयोगकर्ता A ने Service X में उपयोगकर्ता सत्यापन पास कर लिया है और अब वह पार्टनर Service Y पर पंजीकरण कर रहा है। यदि Service X, A के बारे में जानकारी Service Y के साथ साझा करने के लिए सहमत होता है, तो इसे निम्नानुसार किया जा सकता है:
  1. शेयर token जनरेट करें (Service X): Service X किसी विशिष्ट उपयोगकर्ता के सत्यापन सत्र के लिए एक सुरक्षित, अल्पकालिक share_token जनरेट करने के लिए एक API कॉल करता है। यह token केवल Service Y द्वारा उपयोग के लिए निर्दिष्ट है। API संदर्भ देखें: Share Session API।
  2. पार्टनर को token पास करें (Service X -> Service Y): Service X जनरेट किए गए share_token को पहले से व्यवस्थित बैकएंड चैनल के माध्यम से सुरक्षित रूप से Service Y को प्रेषित करता है।
  3. सत्र इंपोर्ट करें (Service Y): Service Y उपयोगकर्ता के डेटा को इंपोर्ट करने के लिए प्राप्त share_token का उपयोग करके एक API कॉल करता है। यह Service Y के अपने एनवायरनमेंट के भीतर सभी दस्तावेज़ों और जांचों सहित सत्यापन सत्र की एक पूरी प्रतिलिपि बनाता है। API संदर्भ देखें: Import Shared Session API।

​
इंपोर्ट विकल्प

सत्र इंपोर्ट करते समय, Service Y के पास परिणामों को संभालने के तरीके पर नियंत्रण होता है:
  • trust_review: यह बूलियन पैरामीटर निर्धारित करता है कि क्या Service Y, Service X की समीक्षा और अंतिम स्थिति (Approved/Declined) पर भरोसा करता है।
    • true: सत्र मूल स्थिति के साथ कॉपी किया जाता है। उपयोगकर्ता को तुरंत Service Y पर ऑनबोर्ड (या अस्वीकार) कर दिया जाता है।
    • false: सत्र डेटा कॉपी किया जाता है, लेकिन स्थिति स्वचालित रूप से In Review पर सेट हो जाती है। यह Service Y को एकत्रित दस्तावेज़ों और डेटा का उपयोग करने की अनुमति देता है, लेकिन अंतिम निर्णय लेने के लिए अपनी स्वयं की आंतरिक समीक्षा प्रक्रिया करने की सुविधा देता है।
  • workflow_id: Service Y को यह निर्दिष्ट करना होगा कि उसके अपने सत्यापन वर्कफ़्लो में से किसे इंपोर्ट किए गए सत्र के साथ संबद्ध किया जाए।
  • vendor_data: Service Y इंपोर्ट किए गए सत्र को अपना आंतरिक उपयोगकर्ता पहचानकर्ता निर्दिष्ट कर सकता है।

​
महत्वपूर्ण विचार

  • केवल पूर्ण सत्र: शेयर token केवल उन सत्रों के लिए जनरेट किया जा सकता है जिनकी स्थिति पूर्ण (Approved, Declined, In Review) हो।
  • कोई डुप्लिकेट नहीं: किसी विशिष्ट सत्र को किसी दिए गए पार्टनर एप्लिकेशन में केवल एक बार ही इंपोर्ट किया जा सकता है। बाद के प्रयासों को अस्वीकार कर दिया जाएगा।

​
पुनः प्रयोज्य KYC बनाम API के माध्यम से KYC साझा करना

यद्यपि दोनों सुविधाएँ पहचान के पुन: उपयोग की सुविधा प्रदान करती हैं, वे अलग-अलग उद्देश्यों को पूरा करती हैं:

​
❗️ महत्वपूर्ण: डेटा शेयरिंग प्रतिबंध

विभिन्न संगठनों के बीच व्यक्तिगत उपयोगकर्ता डेटा साझा करना सख्त कानूनी और नियामक आवश्यकताओं के अधीन है। इस सुविधा का उपयोग करने से पहले, आपका संगठन यह सुनिश्चित करने के लिए ज़िम्मेदार है कि आप सभी लागू डेटा सुरक्षा कानूनों, जैसे कि यूरोपीय संघ में GDPR और यूनाइटेड किंगडम में UK GDPR का पूरी तरह से अनुपालन कर रहे हैं। आपको यह अवश्य करना चाहिए:
  1. एक कानूनी आधार स्थापित करें: सुनिश्चित करें कि आपके पास डेटा साझा करने के लिए एक वैध कानूनी आधार है। इसके लिए अक्सर आपके और आपके पार्टनर संगठन के बीच एक स्पष्ट डेटा शेयरिंग समझौते की आवश्यकता होती है।
  2. उपयोगकर्ता की सहमति सुनिश्चित करें: पुष्टि करें कि आपके उपयोगकर्ताओं को ठीक से सूचित किया गया है और उन्होंने आपके पार्टनर्स के साथ अपने डेटा को साझा करने के लिए सहमति दी है, जैसा कि आपकी सेवा की शर्तों और गोपनीयता नीति में उल्लिखित है।
  3. अंतर्राष्ट्रीय स्थानांतरण को उचित तरीके से संभालें: यदि डेटा सीमाओं के पार स्थानांतरित किया जा रहा है (उदाहरण के लिए, EU से गैर-EU देश में), तो आपको कानून द्वारा अपेक्षित उचित सुरक्षा उपाय सुनिश्चित करने होंगे।
Didit डेटा साझा करने की तकनीकी क्षमता प्रदान करता है, लेकिन आपका संगठन और आपके पार्टनर आपके द्वारा साझा किए जाने वाले डेटा से संबंधित सभी कानूनी और अनुपालन दायित्वों के लिए पूरी तरह ज़िम्मेदार हैं। हम इस सुविधा को लागू करने से पहले अपने कानूनी सलाहकार से परामर्श करने की दृढ़ता से अनुशंसा करते हैं।
अंतिम संशोधन 7 नवंबर 2026