एक सेशन रिज़ल्ट एक स्टेटस, हर चेक का एक रिज़ल्ट, और warnings की एक लिस्ट है - warnings ही वह हिस्सा है जो बताता है कि असल में क्या हुआ।

संक्षिप्त उत्तर

इसे इसी क्रम में पढ़ें: पहले overall status, फिर per-check statuses, फिर warnings। warnings ही अकेला हिस्सा है जो क्यों बताता है - बाकी सब सिर्फ़ क्या बताता है।

Business Console में Verifications से कोई भी सेशन खोलें और आपको वही तीन परतें मिलती हैं, चाहे आप कंसोल देख रहे हों, कोई webhook पेलोड, या कोई API रिस्पॉन्स।

Didit कंसोल में सत्र का विवरण, जिसमें समग्र निर्णय, हर जाँच के परिणाम और निकाला गया डेटा है
एक सेशन, तीन परतें: overall status, per-check रिज़ल्ट, और उनके पीछे की warnings।

#परत 1 - overall status

सेशन के लिए एक अकेला वर्डिक्ट: Approved, Declined, In Review, वगैरह। ज़्यादातर इंटीग्रेशन इसी पर काम करते हैं। यह एक कुल योग है: यह इस बात से मिलता है कि आपकी वर्कफ़्लो कैसे कॉन्फ़िगर की गई है, उसके हिसाब से हर चेक के नतीजे को जोड़कर, इसलिए यह कभी नहीं बताता कि कौन सा चेक ज़िम्मेदार था।

#परत 2 - हर चेक का एक रिज़ल्ट

जो भी चेक चला उसका अपना स्टेटस और अपना डेटा होता है। जो आप सबसे ज़्यादा देखेंगे:

चेकक्या देखें
ID verificationनिकाले गए फ़ील्ड (नाम, डॉक्यूमेंट नंबर, तारीखें), डॉक्यूमेंट टाइप और देश, और MRZ वैलिडेट हुआ या नहीं
पैसिव / एक्टिव लाइवनेसकोई जीवित इंसान पहचाना गया या नहीं, और कोई अटैक सिग्नल
फेस मैच 1:1सेल्फ़ी और डॉक्यूमेंट फ़ोटो के बीच समानता स्कोर
फेस सर्च 1:Nक्या यह चेहरा किसी पहले से वेरिफाई किए यूज़र या ब्लॉकलिस्ट एंट्री से मैच करता है
AML स्क्रीनिंगहिट, हर एक के साथ एक मैच स्कोर और एक रिस्क स्कोर
डिवाइस और IP एनालिसिसदेश, VPN या प्रॉक्सी सिग्नल, ब्लॉकलिस्ट किए एड्रेस
प्रूफ़ ऑफ़ एड्रेसनिकाला गया एड्रेस और वह आपके दिए हुए एड्रेस से कितना मैच हुआ
NFCचिप पढ़ी गई या नहीं और इसका सिग्नेचर किसी भरोसेमंद इशूअर तक चेन हुआ या नहीं
फ़ोन / ईमेलOTP की पुष्टि हुई या नहीं, साथ ही नंबर या एड्रेस पर रिस्क सिग्नल

एक चेक Approved हो सकता है जबकि सेशन Declined हो, और उल्टा भी। यह सामान्य है - सेशन स्टेटस एक कुल योग है, सबसे बुरा केस नहीं।

#परत 3 - warnings

Warnings ही वह परत है जो असल में नतीजे को समझाती है। हर एक उस चेक से जुड़ा एक खास नाम वाला कोड होता है जिसने इसे उठाया - उदाहरण के लिए:

  • DOCUMENT_EXPIRED - ID की एक्सपायरी तारीख निकल चुकी है।
  • MRZ_VALIDATION_FAILED - मशीन-रीडेबल ज़ोन का चेकसम मेल नहीं खाया। छेड़छाड़ का एक मज़बूत संकेत।
  • LOW_FACE_MATCH_SIMILARITY - सेल्फ़ी और डॉक्यूमेंट फ़ोटो का स्कोर आपके थ्रेशहोल्ड से कम रहा।
  • LIVENESS_FACE_ATTACK - सेल्फ़ी के दौरान एक प्रेजेंटेशन अटैक पकड़ा गया।
  • POSSIBLE_MATCH_FOUND - AML को एक कैंडिडेट हिट मिला जिसे सुलझाना ज़रूरी है।
  • NFC_DATA_DOES_NOT_MATCH_OCR - चिप और छपा हुआ डेटा आपस में मेल नहीं खाते।
  • IP_ADDRESS_IN_BLOCKLIST - कनेक्शन किसी ऐसे एड्रेस से आया जिसे आप ब्लॉक करते हैं।
सुझाव

जब आप किसी खास सेशन को डीबग कर रहे हों, तो सीधे warnings पर जाएं। स्टेटस निष्कर्ष बताता है; warnings सबूत बताती हैं। हर फीचर की warning कैटलॉग core technology के तहत डॉक्यूमेंट की गई है।

#निकाला गया डेटा बनाम आपकी अपेक्षा

अगर आपने सेशन बनाते समय expected_details पास किया था - एक नाम, जन्मतिथि, डॉक्यूमेंट नंबर जो आपके पास पहले से है - तो रिज़ल्ट यह भी बताता है कि डॉक्यूमेंट उससे मेल खाया या नहीं। वहां मिसमैच होना आमतौर पर आपकी तरफ़ की डेटा-एंट्री समस्या है, धोखाधड़ी वाला डॉक्यूमेंट नहीं, इसलिए किसी को डिक्लाइन करने से पहले इसे जांचना ज़रूरी है।

महत्वपूर्ण

निकाले गए नाम ट्रांसलिटरेट किए जा सकते हैं। सिरिलिक, अरबी, या ग्रीक स्क्रिप्ट वाला डॉक्यूमेंट एक लैटिन-स्क्रिप्ट नाम देता है जो एक ही व्यक्ति होने पर भी आपके रिकॉर्ड से अक्षर-दर-अक्षर मेल न खाए। किसी नाम के मिसमैच को धोखाधड़ी मानने से पहले डॉक्यूमेंट नंबर या जन्मतिथि पर भी तुलना करें।

#सैंडबॉक्स के रिज़ल्ट थोड़े अलग दिखते हैं

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

#यही चीज़ प्रोग्रामेटिकली पाना

webhook पेलोड और GET /v3/session/{id}/decision/ एक ही decision ऑब्जेक्ट में तीनों परतें लेकर आते हैं। webhook को अपना सोर्स ऑफ़ ट्रुथ मानें और सिर्फ़ मेल बिठाने के लिए ही पोल करें - कुछ इवेंट, जैसे किसी रिव्यूअर द्वारा किए गए डेटा एडिट, सिर्फ़ webhook से ही आते हैं। देखें वेबहुक से रिज़ल्ट पाना।

#अपने रिकॉर्ड के लिए एक कॉपी पाना

ऑडिट और रेगुलेटरी फ़ाइलिंग के लिए, सेशन को PDF के तौर पर डाउनलोड करें - इसमें हर स्टेप, निकाला गया डेटा, बायोमेट्रिक स्कोर, AML रिज़ल्ट, और अंतिम डिसीज़न बंडल होते हैं। देखें वेरिफिकेशन रिपोर्ट डाउनलोड करना।

अभी भी अटके हैं? किसी व्यक्ति से बात करें।

अपने संगठन की ID और जिस सेशन के बारे में पूछ रहे हैं उसकी ID शामिल करें।

सपोर्ट से संपर्क करें