मुख्य सामग्री पर जाएं
हर सत्यापन सत्र कई स्थितियों से होकर गुजरता है। इन्हें समझने से आप उपयोगकर्ता की प्रगति पर नज़र रख सकते हैं, अनुपालन निर्णयों को स्वचालित कर सकते हैं और कन्वर्ज़न दर को बेहतर बना सकते हैं। यह एनम GET /v3/session/<id>/decision/ और हर Didit webhook द्वारा लौटाई गई स्ट्रिंग्स का एकमात्र स्रोत है।

सभी स्थिति मान

हर स्थिति Didit API और webhooks द्वारा लौटाई गई एक सटीक स्ट्रिंग है। अपने कोड में हमेशा सख़्त स्ट्रिंग मिलान का उपयोग करें (जैसे === "In Review")। ये मान केस-सेंसिटिव हैं और इनमें स्पेस शामिल हैं। Kyc Expired मान में केवल पहला अक्षर K बड़ा है, बाकी अक्षर छोटे हैं (KYC नहीं)।

सत्र स्थितियाँ

API मान: "Not Started"सत्र API के ज़रिए बनाया गया है, लेकिन उपयोगकर्ता ने अभी सत्यापन लिंक नहीं खोला है।
  • क्या करें: उपयोगकर्ता के शुरू करने का इंतज़ार करें, या अगर काफ़ी समय बीत जाए तो अनुस्मारक भेजें।
  • इनमें बदलता है: "In Progress", "Expired"
API मान: "In Progress"उपयोगकर्ता ने लिंक खोल लिया है और वह सक्रिय रूप से सत्यापन चरण पूरे कर रहा है (दस्तावेज़ कैप्चर, लाइवनेस आदि)।
  • क्या करें: कोई कार्रवाई ज़रूरी नहीं है, उपयोगकर्ता प्रक्रिया पूरी कर रहा है।
  • इनमें बदलता है: "Approved", "Declined", "In Review", "Abandoned"
API मान: "Approved"सभी सत्यापन जाँचें सफलतापूर्वक पास हो गई हैं। उपयोगकर्ता की पहचान सत्यापित हो गई है।
  • क्या करें: उपयोगकर्ता को पहुँच दें, उसकी प्रोफ़ाइल अपडेट करें, और निर्णय का डेटा संग्रहीत करें।
  • webhook में शामिल है: सभी सुविधा परिणामों वाला पूरा decision ऑब्जेक्ट।
  • इनमें बदलता है: "Kyc Expired" (जब सत्यापित दस्तावेज़ की समाप्ति तिथि निकल जाती है)। यही डिफ़ॉल्ट व्यवहार है, जब तक उस देश और दस्तावेज़ प्रकार के लिए Expiration mode Allow expired पर सेट न हो। कोई समीक्षक या update-status endpoint इसे "Declined" या "Resubmitted" पर भी सेट कर सकता है।
API मान: "Declined"एक या अधिक सत्यापन जाँचें विफल हो गई हैं। उपयोगकर्ता सत्यापन पास नहीं कर पाया।
  • क्या करें: उपयोगकर्ता को सूचित करें। अगर समस्या ठीक की जा सकती है, तो वैकल्पिक रूप से पुनः जमा करने का अनुरोध करें।
  • webhook में शामिल है: विफलता की व्याख्या करने वाली चेतावनियों के साथ पूरा decision ऑब्जेक्ट।
  • इनमें बदलता है: "Resubmitted" (अगर कोई समीक्षक इसका अनुरोध करे)। कोई समीक्षक या update-status endpoint इसे "Approved" पर भी सेट कर सकता है।
API मान: "In Review"स्वचालित जाँचों ने मानवीय समीक्षा की ज़रूरत वाली चेतावनियाँ चिह्नित की हैं। अंतिम निर्णय एक अनुपालन समीक्षक को लेना होगा।
  • क्या करें: समीक्षक को Console में सत्र खोलकर उसे स्वीकृत करना, अस्वीकृत करना, या पुनः जमा करने का अनुरोध करना चाहिए।
  • webhook में शामिल है: चेतावनियों वाला पूरा decision ऑब्जेक्ट।
  • इनमें बदलता है: "Approved", "Declined", "Resubmitted"
API मान: "Awaiting User"व्यवसाय सत्यापन (KYB) सत्रों में इसका उपयोग होता है, जब Key People चरण ने पक्षों की सूची जमा कर दी हो और चाइल्ड KYC / KYB सत्र बन गए हों। पैरेंट सत्र तब तक प्रतीक्षा करता है जब तक सभी आवश्यक पक्ष अपना अलग सत्यापन पूरा नहीं कर लेते।
  • क्या करें: चाइल्ड KYC सत्रों की स्थिति पर नज़र रखें। जब सभी आवश्यक पक्षों के सत्र पूरे हो जाएँ (स्वीकृत, अस्वीकृत या समय-सीमा समाप्त स्थिति में पहुँच जाएँ), तो पैरेंट सत्र अपनी अंतिम स्थिति के अनुसार परिणामों को स्वतः फिर से समेकित करता है।
  • webhook में शामिल है: पक्षों की वर्तमान सूची और उनके चाइल्ड सत्रों की स्थितियाँ।
  • इनमें बदलता है: "Approved", "Declined", "In Review" (जब सभी चाइल्ड सत्र अंतिम स्थिति में हों)
  • इनसे बदलता है: "In Progress" (Key People चरण जमा होने के बाद)
  • नोट: अगर किसी चाइल्ड KYC सत्र को पुनः जमा किया जाता है, तो पैरेंट तब तक "Awaiting User" पर लौट आता है जब तक पुनः जमा किया गया सत्र पूरा न हो। "Declined" KYB Registry Check, "Awaiting User" पर प्राथमिकता रखता है।
API मान: "Resubmitted"एक समीक्षक ने अनुरोध किया है कि उपयोगकर्ता कुछ विशेष सत्यापन चरण दोबारा करे (जैसे धुंधले दस्तावेज़ की फ़ोटो दोबारा लेना)।
  • क्या करें: उपयोगकर्ता के पुनः जमा किए गए चरण पूरे होने का इंतज़ार करें। सिस्टम स्वचालित रूप से दोबारा मूल्यांकन करेगा।
  • webhook में शामिल है: उन सुविधाओं और कारणों की सूची वाला resubmit_info ऑब्जेक्ट जिन्हें दोबारा करना है।
  • इनमें बदलता है: "Approved", "Declined", "In Review", या "Abandoned" (जब व्यक्ति चरण दोबारा पूरे करने से पहले सत्र की अवधि समाप्त हो जाए)।
API मान: "Expired"उपयोगकर्ता द्वारा सत्यापन लिंक खोलने से पहले ही सत्र का समय समाप्त हो गया।
  • क्या करें: नया सत्र बनाएँ और उपयोगकर्ता को ताज़ा लिंक भेजें।
  • अंतिम स्थिति: इसके आगे कोई बदलाव नहीं होता।
API मान: "Abandoned"उपयोगकर्ता ने सत्यापन शुरू किया, लेकिन तय समय-सीमा के भीतर उसे पूरा नहीं किया।
  • क्या करें: अनुस्मारक भेजें या नया सत्र बनाएँ।
  • कोई स्वचालित बदलाव नहीं। कोई समीक्षक, या PATCH /v3/session/{sessionId}/update-status/, इसे अब भी "Approved", "Declined" या "Resubmitted" पर सेट कर सकता है।
API मान: "Kyc Expired"सत्र के दौरान सत्यापित किया गया दस्तावेज़ अपनी समाप्ति तिथि पार कर चुका है। ट्रिगर वह तिथि है, स्वीकृति से मापी गई कोई अवधि नहीं, और पहले से कोई चेतावनी नहीं भेजी जाती।
  • क्या करें: उपयोगकर्ता से नए सत्र के ज़रिए पुनः सत्यापन करने को कहें। status.updated यह बदलाव भेजता है, और पहचान सत्यापन परिणाम में DOCUMENT_EXPIRED चेतावनी होती है।
  • नियंत्रित होता है: पहचान सत्यापन → देश और दस्तावेज़ प्रकार के अनुसार अतिरिक्त सेटिंग्स में उस देश और दस्तावेज़ प्रकार की Expiration mode से। Reject expired (डिफ़ॉल्ट) दस्तावेज़ की निगरानी करता है, जबकि Allow expired का अर्थ है कि सत्र कभी इस स्थिति में नहीं जाता।
  • कोई स्वचालित बदलाव नहीं। कोई समीक्षक, या PATCH /v3/session/{sessionId}/update-status/, इसे अब भी "Approved", "Declined" या "Resubmitted" पर सेट कर सकता है।

स्थिति परिवर्तन

जीवनचक्र आरेख


टर्मिनल बनाम गैर-टर्मिनल


आपके कोड में स्थितियों को संभालना

स्थिति परिवर्तनों पर प्रतिक्रिया देने के लिए webhook या Retrieve Session API का उपयोग करें।
स्थितियाँ सटीक, केस-संवेदी स्ट्रिंग हैं जिनमें रिक्त स्थान होते हैं। उदाहरण के लिए, "In Review" ("in_review" या "IN_REVIEW" नहीं)। मिलान करते समय हमेशा सख़्त समानता (===) का उपयोग करें।

पुनः सबमिशन

पुनः सबमिट की गई स्थिति आपकी अनुपालन टीम को नया सत्र बनाए बिना उपयोगकर्ताओं को दूसरा मौका देने देती है।
1

समीक्षक पुनः सबमिशन शुरू करता है

Console से In Review या Declined सत्र खोलें और पुनः सबमिशन का अनुरोध करें पर क्लिक करें। वे चरण चुनें जिन्हें दोबारा करना है।
2

पिछला डेटा संग्रहीत किया जाता है

सिस्टम चुनी गई सुविधाएँ रीसेट करता है और पिछले डेटा को previous_attempt के रूप में चिह्नित करता है, ताकि पूरा ऑडिट ट्रेल सुरक्षित रहे।
3

उपयोगकर्ता को सूचित किया जाता है

यदि ईमेल उपलब्ध है, तो उपयोगकर्ता को स्थानीयकृत ईमेल मिलता है जिसमें जारी रखने के लिए सीधा लिंक होता है।
4

उपयोगकर्ता विशेष चरण दोबारा करता है

उपयोगकर्ता केवल वही चरण दोहराता है जिन्हें चिह्नित किया गया था, पूरा सत्यापन नहीं।
5

सिस्टम दोबारा मूल्यांकन करता है

पूरा होने पर, सत्र अपने आप "Approved", "Declined", या "In Review" में बदल जाता है।

पुनः सबमिशन webhook payload

reasons हर पुनः सबमिट किए गए node_id को उस चरण के सबसे प्रासंगिक लॉग के चेतावनी कोड से मैप करता है (निर्णय द्वारा दिए गए समान कोड), ताकि आप इसे अपने स्वयं के पाठ से मैप कर सकें। यही वह कोड है जिसे होस्टेड फ़्लो की पुनः सबमिशन स्क्रीन और पुनः सबमिशन ईमेल उपयोगकर्ता के लिए स्थानीयकृत करते हैं। इसका अपवाद वे चेतावनियाँ हैं जो स्क्रीनिंग या धोखाधड़ी संकेत प्रकट कर सकती हैं (डुप्लिकेट, AML, ब्लॉकलिस्ट, संगठनों के बीच जाँच, स्थान अखंडता और इसी तरह की): इनके लिए व्यक्ति को एक सामान्य कारण दिखाई देता है, और आपके webhook में resubmit_info.reasons हमेशा असली कोड रखता है। जिस चरण पर कोई चेतावनी दर्ज नहीं हुई, उसकी कोई प्रविष्टि नहीं होती।

किन सुविधाओं को पुनः सबमिट किया जा सकता है?

कोई भी सुविधा जिसकी स्थिति स्वीकृत नहीं है: अस्वीकृत, समीक्षाधीन, पूरी नहीं हुई, शुरू नहीं हुई, या समय-सीमा समाप्त।
आप एक ही सत्र पर कई बार पुनः सबमिशन का अनुरोध कर सकते हैं। हर चक्र पिछले प्रयास का डेटा संग्रहीत करता है, जिससे उपयोगकर्ता के सत्यापन इतिहास की पूरी जानकारी मिलती है।

सर्वोत्तम अभ्यास

समीक्षाधीन स्थिति पर नज़र रखें

जब सत्रों को मैन्युअल समीक्षा की ज़रूरत हो, तब सूचित होने के लिए अपने Didit Console में अलर्ट (ईमेल या Slack) सेट करें।

पुनः सबमिशन को प्राथमिकता दें

अगर समस्या ठीक की जा सकती है (धुंधली फ़ोटो, दस्तावेज़ का गलत पक्ष), तो अस्वीकार करने के बजाय पुनः सबमिशन का अनुरोध करें। इससे कन्वर्ज़न में सुधार होता है।

ड्रॉप-ऑफ़ पर नज़र रखें

छोड़े गए या समय-सीमा समाप्त हुए सत्रों की ऊँची दरें UX में बाधा का संकेत हो सकती हैं। सत्र TTL समायोजित करने या उपयोगकर्ता मार्गदर्शन बेहतर बनाने पर विचार करें।

आइडेम्पोटेंट हैंडलर

webhook को पुनः प्रयास किया जा सकता है। हर स्थिति बदलाव को केवल एक बार प्रोसेस करने के लिए session_id को यूनिक कुंजी के रूप में इस्तेमाल करें।
payload प्रोसेस करने से पहले हमेशा webhook हस्ताक्षर सत्यापित करें। Didit तीन तरीके देता है: X-Signature, X-Signature-V2 (अनुशंसित), और अप्रचलित X-Signature-Simple, जो केवल एनवेलप को प्रमाणित करता है और decision के मुख्य भाग को कभी प्रमाणित नहीं करता। विवरण के लिए Webhooks देखें।
अंतिम संशोधन 7 नवंबर 2026