मुख्य सामग्री पर जाएं
आपके एप्लिकेशन से किसी व्यक्ति का सत्यापन करने के लिए एक समर्पित वॉलेट endpoint का उपयोग करें। इसके लिए आपको वर्कफ़्लो बनाने या प्रकाशित करने की ज़रूरत नहीं है, और न ही workflow_id देने की। आपका बैकएंड सत्यापन शुरू करता है और उसका परिणाम प्राप्त करता है; आपका इंटरफ़ेस उस व्यक्ति को वॉलेट के आवश्यक प्रमाणीकरण से गुज़ारता है।
API इंटीग्रेशन में भी व्यक्ति को प्रमाणीकरण करना और अपनी पहचान साझा करने को स्वीकृति देना आवश्यक है। इस इंटरैक्शन के बिना आप किसी के व्यक्तिगत पहचानकर्ता को जमा करके उसका सत्यापन नहीं कर सकते।

सत्यापन कैसे काम करता है

  1. आपका बैकएंड वॉलेट कैटलॉग की जाँच करता है, फिर अपनी एप्लिकेशन की API कुंजी का उपयोग करके किसी उपलब्ध वॉलेट के आरंभ endpoint को कॉल करता है।
  2. Didit एक सत्यापन संदर्भ और वह कार्रवाई लौटाता है जो व्यक्ति को करनी है।
  3. आपकी एप्लिकेशन प्रमाणीकरण पेज खोलती है या वॉलेट के स्वीकृति निर्देश दिखाती है।
  4. व्यक्ति अपने वॉलेट से प्रमाणीकरण करता है।
  5. आपका बैकएंड सत्यापित परिणाम प्राप्त करता है और पूरा होने की सूचनाएँ संभालता है।
वॉलेट प्रमाणीकरण एसिंक्रोनस होता है। सफल आरंभ अनुरोध का अर्थ है कि प्रमाणीकरण शुरू हो गया है; इसका अर्थ यह नहीं है कि पहचान सत्यापित हो चुकी है। किसी व्यक्ति को सत्यापित मानने से पहले हमेशा अंतिम परिणाम की जाँच करें।

बैकएंड इंटीग्रेशन

आपकी एप्लिकेशन के लिए वर्तमान endpoints, आवश्यक फ़ील्ड और उपलब्धता जानने के लिए डिजिटल ID वॉलेट सूचीबद्ध करें का उपयोग करें। अपनी x-api-key को अपने बैकएंड पर रखें। इसे ब्राउज़र बंडल या मोबाइल एप्लिकेशन में न रखें। हर नए सत्यापन प्रयास के लिए अलग Idempotency-Key का उपयोग करें, और एक ही आरंभ अनुरोध दोबारा भेजते समय वही कुंजी दोहराएँ। उसी कुंजी के साथ अनुरोध बदलना एक नया सत्यापन प्रयास नहीं, बल्कि टकराव है। हर वॉलेट का अपना आरंभ URL होता है, जैसे Finnish Trust Network के लिए /v3/id-verification/wallets/ftn/। request_id बाद के संचालनों के लिए स्टैंडअलोन सत्यापन की पहचान करता है। अपने संदर्भ के लिए vendor_data का उपयोग करें, जो 2,000 UTF-8 बाइट तक हो सकता है, और वैकल्पिक JSON ऑब्जेक्ट के लिए metadata। दोनों परिणाम और पूर्णता webhook में लौटाए जाते हैं। ये संचालन उस एप्लिकेशन की API कुंजी का उपयोग करते हैं जिसने सत्यापन शुरू किया था। पोलिंग और प्रमाणीकरण की उपलब्धता चुने गए वॉलेट पर निर्भर करती है। रद्द करने पर लंबित सत्यापन बिना शुल्क लिए अस्वीकृत हो जाता है, और पूरा हो चुका सत्यापन बिना बदले लौटाया जाता है। Smart-ID और Mobile-ID के लिए, यदि रद्द करने का अनुरोध उस समय आता है जब कोई पोल स्वीकृति की जाँच कर रहा हो, तो रद्द करने की प्रक्रिया उस पोल के लिए कुछ सेकंड प्रतीक्षा करती है। उसके बाद, यदि व्यक्ति ने पहले ही स्वीकृति दे दी थी तो सत्यापन को verified के रूप में लौटाया जाता है, अन्यथा उसे अस्वीकृत कर दिया जाता है। जो सत्यापन उसी समय व्यक्ति द्वारा पूरा किया जा रहा हो, उसे रद्द नहीं किया जा सकता: प्रतिक्रिया 409 होती है, जिसमें error: "verification_in_progress" और Retry-After हेडर होता है। पूरा हुआ परिणाम पढ़ने के लिए उतने सेकंड बाद पुनः प्रयास करें।

अपना रिटर्न गंतव्य पंजीकृत करें

रीडायरेक्ट वॉलेट प्रमाणीकरण के बाद व्यक्ति को आपकी एप्लिकेशन पर वापस भेजते हैं। सत्यापन शुरू करने से पहले सटीक होस्टनेम पंजीकृत करें:
फिर आरंभ अनुरोध में HTTPS return_url भेजें, जैसे https://app.example.com/identity/complete। allowed_return_hosts में केवल बेयर होस्टनेम का उपयोग करें, जिसमें स्कीम, पाथ या वाइल्डकार्ड न हो। आपके द्वारा उपयोग किए जाने वाले प्रत्येक सबडोमेन को अलग से पंजीकृत करें, अधिकतम 20 होस्टनेम। allowed_return_hosts को अपडेट करने से पंजीकृत सूची प्रतिस्थापित हो जाती है, इसलिए वे सभी होस्टनेम शामिल करें जिन्हें आप रखना चाहते हैं। GET /v3/webhook/ वर्तमान सूची लौटाता है; देखें Webhook कॉन्फ़िगरेशन। रिटर्न गंतव्य पंजीकृत करने के लिए आपको वर्कफ़्लो या व्हाइट लेबल डोमेन की ज़रूरत नहीं है। गंतव्य एक ब्राउज़र रिटर्न पेज है; पूर्णता webhook को अपने बैकएंड के लिए अलग से कॉन्फ़िगर करें।

उदाहरण: Finnish Trust Network

अपना रिटर्न होस्टनेम पंजीकृत करने के बाद, एक Finnish Trust Network सत्यापन शुरू करें:
लौटाया गया request_id सहेजें, और जब type redirect हो तो व्यक्ति के ब्राउज़र को wallet_verification.next_action.url पर भेजें। व्यक्ति के लौटने के बाद, अपने बैकएंड से परिणाम प्राप्त करें:
wallet_verification.outcome की जाँच करें: पहचान की वास्तविक जाँच के लिए पहचान का उपयोग तभी करें जब परिणाम verified हो और simulated false हो। लंबित प्रतिक्रिया में अगली कार्रवाई हो सकती है; अंतिम प्रतिक्रियाओं में कोई अगली कार्रवाई नहीं होती।

प्रमाणीकरण अनुभव

रिडायरेक्ट वॉलेट वापस एक प्रमाणीकरण URL देते हैं। उस URL को व्यक्ति के ब्राउज़र में खोलें, उन्हें वॉलेट की प्रमाणीकरण प्रक्रिया पूरी करने दें और फिर उन्हें आपके पंजीकृत गंतव्य पर वापस भेजें। पहचान के प्रमाण के रूप में वापसी URL के पैरामीटर पर भरोसा करने के बजाय परिणाम अपने बैकएंड से पढ़ें। Smart-ID और Mobile-ID व्यक्ति के फ़ोन पर एक अनुमोदन प्रॉम्प्ट का उपयोग करते हैं। आपका इंटरफ़ेस आवश्यक व्यक्तिगत पहचानकर्ता एकत्र करता है; Mobile-ID को संबंधित फ़ोन नंबर भी चाहिए। तुलना कोड दिखाएँ और व्यक्ति से तभी अनुमोदन करने को कहें जब वह उनके फ़ोन पर दिखाए गए कोड से मेल खाए। उनका PIN वॉलेट या फ़ोन के प्रॉम्प्ट में रहना चाहिए, आपके फ़ॉर्म या किसी API अनुरोध में कभी नहीं। प्रॉम्प्ट का फ़ीडबैक पाने के लिए अपने backend से लौटाए गए poll_interval_seconds पर पोल करें। Didit लंबित फ़ोन अनुमोदनों की जाँच पृष्ठभूमि में भी करता है, इसलिए व्यक्ति के आपका पेज बंद करने के बाद भी पूर्णता की सूचना आपके webhook तक पहुँच सकती है। Google Wallet को आपके अपने पेज या ऐप से Digital Credentials API के माध्यम से पूछा जाता है, किसी redirect के बिना; देखें Digital Credentials वॉलेट (Google Wallet)। उपलब्ध इंटरैक्शन चुने गए वॉलेट पर निर्भर करता है। यह मान न लें कि हर वॉलेट एम्बेडेड फ़ॉर्म, QR कोड या बिना ब्राउज़र के प्रमाणीकरण का समर्थन करता है।

Digital Credentials वॉलेट (Google Wallet)

आपका वेब पेज या Android ऐप W3C Digital Credentials API का उपयोग करके सीधे Google Wallet से अनुरोध करता है। इसमें कोई redirect नहीं है, Didit का होस्ट किया हुआ कोई पेज नहीं है और Didit का कोई QR कोड नहीं है। यह प्रोडक्शन और सैंडबॉक्स दोनों में उपलब्ध है। Sandbox एप्लिकेशन को पंजीकरण की ज़रूरत नहीं होती; हर प्रोडक्शन एप्लिकेशन को Google Wallet का उपयोग करने से पहले कंसोल से एक बार पंजीकरण करना होता है (पहचान सत्यापन चरण, Google Wallet वाली पंक्ति, Google के साथ पंजीकरण करें)। आपका एप्लिकेशन अभी क्या शुरू कर सकता है, यह जानने के लिए डिजिटल ID वॉलेट की सूची देखें।
1

अपने origin से शुरू करें

आपका backend व्यक्ति के country (USA, GBR, BRA, SGP या TWN) और उस origin के साथ POST /v3/id-verification/wallets/google-wallet/ को कॉल करता है, जो वॉलेट से पूछेगा। origin आपके पेज का HTTPS origin है, जैसे https://app.example.com, जिसका होस्ट आपके पंजीकृत रिटर्न होस्टनेम में से एक होना चाहिए या आपका व्हाइट लेबल डोमेन। Android ऐप के लिए यह android:apk-key-hash: है, जिसके बाद आपके ऐप के साइनिंग सर्टिफ़िकेट का base64 SHA-256 आता है, बिना padding के। वॉलेट किसी दूसरे origin से आए अनुरोध को अस्वीकार करता है। यहाँ कोई return_url नहीं है।
2

उपयोगकर्ता के इशारे के भीतर वॉलेट से पूछें

रिस्पॉन्स में wallet_verification.interaction = "digital_credentials" और next_action.type = "request_digital_credential" होते हैं। next_action.digital_credentials.request को ब्राउज़र या Android Credential Manager को दें, आपने जिस origin से शुरुआत की थी, वहाँ टैप या क्लिक करके। डेस्कटॉप पर, जब वॉलेट किसी दूसरे डिवाइस पर हो, तो ब्राउज़र अपना QR कोड दिखाता है।
3

वॉलेट से मिला उत्तर जमा करें

वॉलेट से मिला {protocol, data} अपने backend को भेजें और वहाँ से POST /v3/id-verification/wallets/verifications/{request_id}/response/ को {"response": {...}} के रूप में भेजें। अनुरोध एक बार ही जमा किया जा सकता है; दूसरी बार जमा करने पर पहले से निर्णय लिया गया सत्यापन लौटता है।
4

परिणाम पढ़ें

जमा करने का रिस्पॉन्स निर्णय लिया गया सत्यापन है। आप इसे GET /v3/id-verification/wallets/verifications/{request_id}/ से भी पढ़ सकते हैं या completion webhook में प्राप्त कर सकते हैं।
ब्राउज़र में, क्लिक हैंडलर से वॉलेट से पूछें:
यह विकल्प केवल वहीं दें जहाँ ब्राउज़र इसका समर्थन करता है, उदाहरण के लिए जब "DigitalCredential" in window सत्य हो। navigator.credentials.get को उपयोगकर्ता के इशारे के भीतर चलना चाहिए, इसलिए इसे क्लिक हैंडलर से कॉल करें, किसी असिंक्रोनस चरण के बाद नहीं। Android पर, उसी अनुरोध के साथ Jetpack Credential Manager (androidx.credentials 1.5.0 या उसके बाद का) का उपयोग करें:
संभालने योग्य त्रुटियाँ: जो क्रेडेंशियल सत्यापन में विफल होता है, वह त्रुटि रिस्पॉन्स नहीं बल्कि failed परिणाम वाला निर्णय लिया गया सत्यापन है। वॉलेट से केवल वही फ़ील्ड बाहर आते हैं जिनके लिए सत्यापन अनुरोध किया गया है, और परिणाम में वे पहचान गुण होते हैं जो वॉलेट ने लौटाए। Google Wallet ID पास या US राज्य का मोबाइल ड्राइविंग लाइसेंस पोर्ट्रेट फ़ोटो नहीं लौटाता। सैंडबॉक्स एप्लिकेशन में यह प्रवाह उन्हीं चरणों के साथ सिम्युलेट किया जाता है और simulated: true लौटाता है। कोई भी जमा किया गया उत्तर sandbox_scenario के अनुसार सत्यापन का निर्णय करता है, इसलिए आप बिना असली क्रेडेंशियल के पूरा ब्राउज़र या ऐप प्रवाह बना सकते हैं।

पूर्णता webhook

webhook इंटिग्रेशन गाइड का उपयोग करके status.updated के लिए एक एप्लिकेशन webhook गंतव्य कॉन्फ़िगर करें। यहाँ बताई गई निर्णय संरचना के लिए webhook_version: "v3" का उपयोग करें। प्रोसेस करने से पहले अपने backend पर webhook के हस्ताक्षर को सत्यापित करें। webhook का session_id, वॉलेट API द्वारा लौटाए गए request_id से मेल खाता है। पूरा हुआ वॉलेट पहचान सत्यापन webhook के decision.id_verifications ऐरे में verification_method: "wallet" के साथ दिखता है। समर्पित वॉलेट API परिणाम पाने के लिए आप इस पहचानकर्ता का भी उपयोग कर सकते हैं। स्वीकृत और अस्वीकृत सूचनाएँ संभालें, जिनमें रद्द और समय-सीमा समाप्त सत्यापन भी शामिल हैं। अपने webhook हैंडलर को आइडेम्पोटेंट बनाएँ, क्योंकि विफल डिलीवरी फिर से भेजी जाती हैं। ब्राउज़र का वापस लौटना पूर्णता webhook नहीं है, और उसके क्वेरी पैरामीटर पहचान का प्रमाण नहीं हैं।

लौटाई गई पहचान

जब नाम और जन्म तिथि लौटाए जाएँ, तब सामान्यीकृत पहचान फ़ील्ड का उपयोग करें। वॉलेट-विशिष्ट विशेषताएँ उस पहचान जानकारी का वर्णन करती हैं जो चुने गए वॉलेट द्वारा साझा की गई है। उपलब्ध विशेषताएँ वॉलेट और देश के अनुसार अलग-अलग होती हैं। प्रमाणित पहचान का अर्थ यह नहीं है कि चेहरे की तस्वीर, पता या अनुरोध की गई कोई अन्य विशेषता उपलब्ध है।

सैंडबॉक्स में परीक्षण

Didit सैंडबॉक्स मोड में कोई एप्लिकेशन किसी वॉलेट प्रदाता से संपर्क किए बिना और क्रेडिट लिए बिना वॉलेट सत्यापन का सिम्युलेशन करता है। रिस्पॉन्स इन अनुरोधों की पहचान wallet_verification.simulated: true से करता है। सिम्युलेटेड स्वीकृति नमूना डेटा है, वास्तविक दुनिया की सत्यापित पहचान नहीं। रीडायरेक्ट वॉलेट के लिए, कॉलबैक का परीक्षण करने और अपने एप्लिकेशन पर लौटने के लिए लौटाए गए URL का अनुसरण करें। Smart-ID या Mobile-ID के लिए, सिम्युलेटेड स्वीकृति पूरी करने हेतु पोलिंग endpoint का उपयोग करें; फ़ोन पर कोई सूचना नहीं भेजी जाती। विफलता प्रबंधन का परीक्षण करने के लिए, अनुरोध शुरू करते समय sandbox_scenario को wallet_cancelled, wallet_timeout या wallet_provider_error पर सेट करें। लाइव एप्लिकेशन sandbox_scenario को अस्वीकार करते हैं। Didit सैंडबॉक्स सिम्युलेशन किसी प्रदाता के अपने टेस्ट एनवायरनमेंट के विरुद्ध परीक्षण से अलग है। सफल सिम्युलेशन से न तो लाइव प्रदाता तक पहुँच की पुष्टि होती है, न ही प्रोडक्शन में उपलब्धता की।

ConnectID प्रदाता सैंडबॉक्स

ConnectID का प्रदाता सैंडबॉक्स टेस्ट बैंकों का उपयोग करता है और Didit सैंडबॉक्स सिम्युलेशन से अलग है। जब आपके इंटीग्रेशन के लिए प्रदाता सैंडबॉक्स एक्सेस कॉन्फ़िगर किया गया हो, तब चुने गए बैंक का authorisation_server_id ConnectID प्रारंभ endpoint को पास करें। ConnectID बैंक चयनकर्ता से लौटाया गया ID उपयोग करें; बैंक URL या कोई मनमाना जारीकर्ता न भेजें। फ़ील्ड छोड़ देने पर डिफ़ॉल्ट टेस्ट बैंक चुना जाता है। यह फ़ील्ड ConnectID के लिए विशिष्ट है और अनुरोधित पहचान विशेषताओं को नहीं बदलता। प्रारंभिक बंडल में प्रथम नाम, पारिवारिक नाम और जन्म तिथि का अनुरोध किया जाता है। प्रमाणीकरण के लिए लौटाए गए next_action का पालन करें, और फिर सत्यापन परिणाम प्राप्त करें या उसके लिए पोल करें। केवल स्वीकृत स्थिति वाला पूर्ण परिणाम पुष्टि करता है कि सत्यापन सफल रहा; आपके एप्लिकेशन पर लौटना ऐसी पुष्टि नहीं करता। ऑनबोर्डिंग और प्रमाणन पूरे होने तक ConnectID प्रोडक्शन में जल्द आ रहा है के रूप में बना रहेगा।

उपलब्धता और मूल्य निर्धारण

endpoint कवरेज और प्रोडक्शन में वॉलेट सक्रियण अलग-अलग बातें हैं। किसी वॉलेट का API संदर्भ पेज हो सकता है और फिर भी लाइव प्रमाणीकरण के लिए वह उपलब्ध न हो। लाइव फ़्लो लागू करने से पहले वॉलेट का देश कवरेज और प्रोडक्शन स्थिति जाँच लें। प्रकाशित दरों और उपलब्धता के लिए डिजिटल ID वॉलेट मूल्य निर्धारण देखें। वॉलेट सत्यापन का बिल दस्तावेज़ कैप्चर से अलग बनता है।

इंटीग्रेशन चुनना

इन APIs का उपयोग तब करें जब आप संबंधित इंटरफ़ेस और एप्लिकेशन लॉजिक को स्वयं नियंत्रित करना चाहते हैं। जब आप Didit का होस्टेड सत्यापन फ़्लो, वर्कफ़्लो नियम और कॉन्फ़िगर किए गए फ़ॉलबैक चरण चाहते हैं, तब Sessions API का उपयोग करें। दोनों तरीकों में भी वॉलेट का प्रमाणीकरण और सहमति की प्रक्रिया आवश्यक है।
अंतिम संशोधन 7 नवंबर 2026