मुख्य सामग्री पर जाएं
vendor_data वह पहचानकर्ता है जो आप हर सत्र और लेन-देन के साथ भेजते हैं ताकि उसे उपयोगकर्ता या व्यवसाय इकाई से जोड़ा जा सके। इकाई एकत्रीकरण के लिए यह सबसे महत्वपूर्ण फ़ील्ड है। इसे सही रखने पर, प्रोफ़ाइल इतिहास, लेन-देन निगरानी, ब्लॉकलिस्ट प्रवर्तन और सतत AML निगरानी जैसी इसके बाद की सभी सुविधाएँ सहजता से काम करती हैं।

यह क्या है

vendor_data एक स्ट्रिंग है जिसे आप चुनते हैं। Didit इसे एक अपारदर्शी पहचानकर्ता मानता है और इसकी सामग्री की व्याख्या नहीं करता। सामान्य मान इस प्रकार हैं:
vendor_data में कभी PII (ईमेल, फ़ोन नंबर, कच्ची कर पहचान संख्याएँ) सीधे न डालें। उन्हें हैश करें या प्रीफ़िक्स लगाएँ। vendor_data webhook payload में दिखता है और जब तक इकाई मौजूद है, तब तक अनिश्चित काल तक संग्रहीत रहता है।

यह चीज़ों को कैसे जोड़ता है

जब आप vendor_data मान के साथ सत्र या लेन-देन सबमिट करते हैं:
  1. Didit आपके एप्लिकेशन में उस vendor_data वाली इकाई को खोजता है।
  2. यदि वह मौजूद है, तो नई वस्तु उस इकाई से जुड़ जाती है।
  3. यदि वह मौजूद नहीं है, तो Didit इकाई बनाता है (status: ACTIVE के साथ) और नई वस्तु को उससे जोड़ता है।
यह इन पर लागू होता है:
  • POST /v3/session/: KYC और व्यवसाय सत्यापन (KYB) सत्र
  • POST /v3/transactions/: लेन-देन (आवेदक और प्रतिपक्ष, दोनों के लिए)
  • लेन-देन payloads के भीतर applicant.vendor_data / counterparty.vendor_data फ़ील्ड

विशिष्टता और दायरा

vendor_data प्रति एप्लिकेशन अद्वितीय है, न कि Didit में वैश्विक रूप से: इसका अर्थ है कि आप स्टेजिंग एप्लिकेशन और प्रोडक्शन एप्लिकेशन में एक ही vendor_data का उपयोग बिना टकराव के कर सकते हैं। और आप एक उपयोगकर्ता user-42 और एक व्यवसाय user-42 रख सकते हैं, बिना टकराव के, हालाँकि स्पष्टता के लिए इसकी सलाह नहीं दी जाती।

यदि आप vendor_data छोड़ देते हैं तो क्या होता है

आप vendor_data के बिना सत्र बना सकते हैं। ऐसे में:
  • सत्र के लिए कोई इकाई नहीं बनती।
  • सत्र अलग-थलग रहता है और किसी भी उपयोगकर्ता या व्यवसाय प्रोफ़ाइल में नहीं दिखेगा।
  • आप बाद में vendor_data से सत्र नहीं खोज सकते, केवल session_id से।
इस पैटर्न का उपयोग केवल उन गुमनाम या एक-बार किए जाने वाले सत्यापनों के लिए करें जहाँ इकाई एकत्रीकरण की ज़रूरत नहीं है। हर उस इंटीग्रेशन के लिए जिसमें पुनः सत्यापन, लेन-देन या सतत निगरानी शामिल है, हमेशा vendor_data दें।

उदाहरण: पहले इकाई बनाएँ, फिर सत्र चलाएँ

तीनों कॉल एक ही उपयोगकर्ता इकाई से जुड़ी हैं। जब आप बाद में GET /v3/users/user-42/ कॉल करेंगे, तो आपको सत्र गणना, स्वीकृत/अस्वीकृत काउंटर, जुड़े लेन-देन और नवीनतम प्रोफ़ाइल डेटा दिखेगा।

बाहरी ID का माइग्रेशन

यदि आप किसी मौजूदा KYC विक्रेता से Didit पर आ रहे हैं, तो पहले दिन से अपनी मौजूदा स्थिर उपयोगकर्ता ID को vendor_data के रूप में भेजें। इससे यह आसान होता है:
  • Didit डेटा को अपने आंतरिक डेटाबेस से मिलाना।
  • कोई भी सत्र चलाने से पहले कंसोल CSV इंपोर्ट के ज़रिए ऐतिहासिक उपयोगकर्ताओं को बल्क में लोड करना।
  • बाद में लेन-देन निगरानी के लिए Didit पर माइग्रेट करते समय संबंध बनाए रखना।

नियम, परंपराएँ और सर्वोत्तम अभ्यास

अगले चरण

उपयोगकर्ता अवलोकन

उपयोगकर्ता इकाइयों और संचालन की विस्तृत जानकारी।

व्यवसाय अवलोकन

व्यवसाय इकाइयों और संचालन की विस्तृत जानकारी।

सत्र बनाएँ

किसी vendor_data के लिए सत्यापन शुरू करें।

लेन-देन बनाएँ

किसी इकाई से जुड़ा लेन-देन सबमिट करें।
अंतिम संशोधन 7 नवंबर 2026