Mobile और web SDK

iOS, Android, React Native और Flutter के लिए native SDK पूरे flow को आपकी app के अंदर लाते हैं और सिर्फ ये ही NFC सपोर्ट करते हैं। Web SDK इसे आपके frontend में embed करते हैं।

Didit सपोर्ट द्वारा लिखित · अपडेट किया गया 19 अगस्त 2026

#Redirect की जगह SDK क्यों

एक hosted redirect सबसे कम मेहनत वाला रास्ता है और ज़्यादातर flows के लिए वाकई ठीक है। SDK तब काम आता है जब:

• आपको NFC चाहिए। Passport या ID के अंदर मौजूद chip को browser पेज से नहीं पढ़ा जा सकता। Native SDK ही एकमात्र रास्ता है। देखें NFC chip verification।
• आप नहीं चाहते कि यूज़र आपकी app छोड़े। Mobile पर बाहर जाकर वापस आना drop-off का असली मौका होता है।
• आपको सबसे अच्छा camera व्यवहार चाहिए। Native camera access, browser के मुकाबले ज़्यादा भरोसेमंद है, खासकर पुराने devices पर।

#क्या उपलब्ध है

12

1. अपना platform चुनें और पेज आपको उस stack का snippet दे देगा।
2. Native और web SDK, हर एक अपने quickstart के साथ, यहां लिंक किए गए हैं।

Version की ज़रूरतें और platform के minimum हर release के साथ बदलते रहते हैं, इसलिए किसी help पेज के snapshot के बजाय मौजूदा SDK documentation देखें - और अगर आप किसी खास framework version पर हैं (जैसे कोई खास Expo SDK), तो किसी sprint में इसे तय करने से पहले अपने Didit contact से compatibility पक्की कर लें।

#WebView, native SDK नहीं है

Hosted web flow को WebView में लपेटना ऐसा दिखता है मानो यह in-app अनुभव दे रहा हो। यह सिर्फ उसका आभास देता है:

• NFC नहीं। Chip अब भी नहीं पढ़ा जा सकता।
• Camera permissions और मुश्किल हो जाती हैं। WebView की camera access host-app की configuration पर निर्भर करती है, और इसे गलत करने से बिल्कुल वही "camera कभी खुला ही नहीं" वाली रिपोर्ट्स आती हैं जिनका ज़िक्र liveness और face match समस्याएं ठीक करना में है।
• Locale app का होता है, यूज़र का नहीं। WebView host app का locale रिपोर्ट करता है, इसलिए session बनाते समय language साफ़ तौर पर पास करें। देखें verification की भाषा सेट करना।

अगर आप in-app flow के लिए इतनी मेहनत कर ही रहे हैं, तो native SDK इस्तेमाल करें।

#नतीजे अब भी webhook से आते हैं

यहां लोग अक्सर चूक जाते हैं: SDK आपकी app को बताता है कि यूज़र ने flow पूरा कर लिया। यह verification के फैसले का आधिकारिक स्रोत नहीं है।

फैसला checks चलने के बाद server-side पर बनता है, और वह आपको webhook से मिलता है। सिर्फ SDK के completion callback के आधार पर कभी access न दें - client-side signal को आसानी से forge किया जा सकता है, और जब वह callback आता है तब तक checks पूरे भी नहीं हुए हो सकते।

#एक consumer app, या आपकी अपनी?

कोई अलग consumer Didit app नहीं है जिसे hosted session किसी step (जैसे NFC) के लिए यूज़र्स को सौंप दे। अगर आप सब कुछ - NFC और non-NFC - एक ही app अनुभव में चाहते हैं, तो वह app आपकी अपनी है, जिसमें SDK embedded होगा।

#Distribution और dependency conflicts

Native SDK integration कभी-कभी किसी host app की दूसरी dependencies से टकरा जाता है - कोई shared transitive library, या कोई subspec जो वही version pin करता है जो कुछ और भी pin करता है। अगर आपको ऐसा कुछ मिले, तो यह अपने dependency manifest के साथ रिपोर्ट करने लायक एक ठोस, reproducible समस्या है, न कि किसी पुरानी चीज़ को pin करके काम चलाने वाली - सही fix आमतौर पर SDK में ही होना चाहिए।

#किसी device पर टेस्ट करना

Sandbox किसी SDK के ज़रिए भी वैसे ही काम करता है जैसे और कहीं करता है - app को किसी sandbox application की key पर पॉइंट करें और हर check mock और unbilled हो जाता है। किसी mobile flow को रिहर्स करने का यही सही तरीका है, क्योंकि जिन SDK व्यवहारों (permission prompts, camera lifecycle, capture के बीच में background होना) को सबसे ज़्यादा टेस्ट करने की ज़रूरत होती है, वे device के व्यवहार हैं जिन्हें बार-बार आज़माना आपको कुछ भी खर्च नहीं करता। देखें sandbox में टेस्ट करना।