ब्लॉग · 28 जुलाई 2026

फ़्लटर SDK: अपने ऐप में पहचान सत्यापन जोड़ें (HI)

डिडिट SDK के साथ फ़्लटर ऐप में पहचान सत्यापन जोड़ने के लिए एक डेवलपर गाइड: नेटिव सेटअप, बैकएंड-निर्मित सत्र, डार्ट परिणाम हैंडलिंग, टाइप की गई त्रुटियां, वेबहुक, परीक्षण, सुरक्षा और रिलीज़ संचालन।.

द्वारा Didit28 जुलाई 2026अपडेट किया गया 28 जुल॰ 2026

flutter-sdk-identity-verification-integration-guide.png

पहचान सत्यापन के लिए एक फ़्लटर SDK एकीकरण को आपके बैकएंड पर स्थायी क्रेडेंशियल और अंतिम प्राधिकरण रखना चाहिए, जबकि मोबाइल ऐप एक अल्पकालिक सत्र टोकन के साथ एक नेटिव कैप्चर फ़्लो लॉन्च करता है। डिडिट फ़्लटर SDK नेटिव iOS और Android सत्यापन SDKs पर एक डार्ट API को उजागर करता है, जो ऐप को टाइप किए गए पूर्णता, रद्दीकरण या विफलता परिणाम लौटाता है। पूरा निर्णय अभी भी बैकएंड वेबहुक या पुनर्प्राप्ति फ़्लो का होता है।

यह गाइड केवल डार्ट विधियों और परिणाम प्रकारों का उपयोग करती है जो वर्तमान स्थानीय SDK स्रोत और परीक्षणों के विरुद्ध सत्यापित हैं। रिलीज़ के साथ नेटिव निर्भरता विवरण बदलते रहते हैं, इसलिए प्लेटफ़ॉर्म कॉन्फ़िगरेशन को जिम्मेदारी से वर्णित किया गया है और संस्करण-संवेदनशील Podfile या Gradle ब्लॉक की प्रतिलिपि बनाने के बजाय प्रामाणिक SDK गाइड से जोड़ा गया है।

मुख्य बातें

बैकएंड पर उत्पादन सत्र बनाएं। API कुंजी को डिवाइस से दूर रखें और SDK द्वारा आवश्यक सत्र टोकन ही भेजें।
उपयोगकर्ता अनुभव के लिए टाइप किए गए डार्ट परिणाम का उपयोग करें, प्राधिकरण के लिए नहीं। VerificationCompleted का अर्थ है कि SDK फ़्लो समाप्त हो गया; प्रदर्शन के लिए स्थिति का निरीक्षण करें और आधिकारिक बैकएंड निर्णय की प्रतीक्षा करें।
रद्दीकरण, टाइप की गई विफलताओं और अप्रत्याशित प्लेटफ़ॉर्म त्रुटियों को अलग से संभालें। उन्हें विभिन्न पुनर्प्राप्ति और विश्लेषण की आवश्यकता होती है।
नेटिव सेटअप को रिलीज़ इन्फ्रास्ट्रक्चर के रूप में मानें। iOS गोपनीयता कुंजियाँ, नियर-फील्ड कम्युनिकेशन (NFC) अधिकार, परिनियोजन लक्ष्य, Android निर्भरताएँ, पैकेजिंग और अनुमतियाँ वास्तविक उपकरणों पर परीक्षण की जानी चाहिए।
पूरे जीवनचक्र को डिज़ाइन करें। सत्र निर्माण, ऐप हैंडऑफ़, कैप्चर, वेबहुक सत्यापन, आइडम्पोटेंट स्थिति परिवर्तन, समीक्षा, पुनः प्रयास और अवलोकन एक एकीकरण बनाते हैं।

डिडिट फ़्लटर SDK क्या करता है

didit_sdk पैकेज एक साझा डार्ट इंटरफ़ेस के पीछे नेटिव iOS और Android SDKs को लपेटता है। यह सत्यापन उपयोगकर्ता इंटरफ़ेस को एक नेटिव पूर्ण-स्क्रीन फ़्लो के रूप में लॉन्च करता है और जब उपयोगकर्ता पूरा करता है, रद्द करता है या कोई त्रुटि आती है तो वापस लौटता है।

SDK पहचान सत्यापन, लाइवनेस डिटेक्शन और अन्य कॉन्फ़िगर किए गए जांचों के साथ कार्यप्रवाह लॉन्च कर सकता है। कार्यप्रवाह निर्धारित करता है कि कौन से चरण दिखाई देते हैं; फ़्लटर कॉल उन्हें हार्ड-कोड नहीं करता है।

जीवनचक्र से संबंधित सार्वजनिक डार्ट सतह है:

DiditSdk.startVerification(token, config: ...)
DiditSdk.startVerificationWithWorkflow(workflowId, vendorData: ..., config: ...)

उत्पादन के लिए, बैकएंड-निर्मित टोकन के साथ startVerification को प्राथमिकता दें। कार्यप्रवाह-आईडी विधि सरल है लेकिन बैकएंड को उन्नत मापदंडों पर कम नियंत्रण देती है।

आर्किटेक्चर: बैकएंड, फ़्लटर ऐप, SDK और वेबहुक

उत्पादन फ़्लो में चार विश्वास सीमाएँ हैं:

घटक	मालिक	मालिक नहीं होना चाहिए
आपका बैकएंड	API कुंजी, कार्यप्रवाह चुनाव, ग्राहक संदर्भ, सत्र निर्माण, अंतिम ग्राहक स्थिति	कैमरा इंटरफ़ेस
फ़्लटर ऐप	हैंडऑफ़ अनुरोध, लोडिंग और पुनर्प्राप्ति UI, SDK लॉन्च, स्थानीय विश्लेषण	स्थायी API कुंजी या अंतिम प्राधिकरण
डिडिट फ़्लटर SDK	नेटिव कैप्चर और कॉन्फ़िगर किया गया सत्यापन फ़्लो	आपका उत्पाद अधिकार निर्णय
वेबहुक/पुनर्प्राप्ति कार्यकर्ता	प्रमाणित परिणाम अंतर्ग्रहण, डुप्लिकेशन हटाना, सुलह	अपुष्ट ग्राहक धारणाएँ

अनुक्रम है:

साइन-इन किया गया फ़्लटर ऐप आपके बैकएंड को सत्यापन शुरू करने के लिए कहता है।
आपका बैकएंड वांछित कार्यप्रवाह और स्थिर आंतरिक ग्राहक संदर्भ के साथ एक सत्यापन सत्र बनाता है।
बैकएंड ऐप को स्कोप किया गया session_token लौटाता है।
ऐप उस टोकन को DiditSdk.startVerification में पास करता है।
SDK नेटिव फ़्लो प्रस्तुत करता है और तत्काल उपयोगकर्ता अनुभव के लिए एक टाइप किया गया परिणाम लौटाता है।
आपका बैकएंड परिणाम इवेंट प्राप्त करता है और सत्यापित करता है, प्रामाणिक स्थिति का मिलान करता है, और आपकी नीति के तहत ग्राहक को अपडेट करता है।
ऐप पहुंच प्रदान करने या अंतिम अनुमोदन का दावा करने से पहले आपके बैकएंड की ग्राहक स्थिति पढ़ता है।

यह आर्किटेक्चर ऑन-डिवाइस सफलता स्क्रीन पर भरोसा नहीं करता है।

सर्वर-साइड अनुबंध और इवेंट सीमा के लिए, पहचान सत्यापन API एकीकरण गाइड देखें।

पैकेज स्थापित करें

पुराने हो सकने वाले संस्करण की प्रतिलिपि बनाने के बजाय पैकेज कमांड का उपयोग करें:

flutter pub add didit_sdk

फिर सार्वजनिक लाइब्रेरी आयात करें:

import 'package:didit_sdk/sdk_flutter.dart';

अपग्रेड करने से पहले, चेंजलॉग और आधिकारिक फ़्लटर SDK दस्तावेज़ पढ़ें। अपने ऐप और CI छवियों के विरुद्ध घोषित प्लेटफ़ॉर्म आवश्यकताओं की जाँच करें।

नेटिव निर्भरताओं के लिए फ़्लटर रिलीज़ निर्देशों का पालन करें; मनमाने संस्करणों को मिलाने से असंगति हो सकती है।

iOS और Android कॉन्फ़िगर करें

iOS जिम्मेदारियाँ

पहचान कैप्चर संरक्षित हार्डवेयर और डेटा का उपयोग कर सकता है। कॉन्फ़िगर किए गए कार्यप्रवाह और SDK वेरिएंट के आधार पर, iOS सेटअप को इसकी आवश्यकता हो सकती है:

एक उपयुक्त परिनियोजन लक्ष्य;
कैमरा और माइक्रोफ़ोन उपयोग विवरण;
फोटो-लाइब्रेरी उपयोग विवरण यदि अपलोड की अनुमति है;
NFC उपयोग विवरण और अधिकार जब चिप रीडिंग सक्षम हो;
संगत CocoaPods कॉन्फ़िगरेशन;
हस्ताक्षर क्षमताएं और प्रावधान जो NFC उपयोग से मेल खाते हैं;
पंजीकृत कस्टम फ़ॉन्ट यदि एक ऐप-विशिष्ट फ़ॉन्ट कॉन्फ़िगर किया गया है।

गोपनीयता-उद्देश्य स्ट्रिंग्स गायब होने से एक iOS ऐप समाप्त हो सकता है। भौतिक डिवाइस पर सटीक कार्यप्रवाह का परीक्षण करें।

NFC समर्थन न्यूनतम परिनियोजन लक्ष्य बढ़ा सकता है या नेटिव निर्भरताएं जोड़ सकता है। उस SDK वेरिएंट का चयन करें जो आपके कार्यप्रवाह से मेल खाता है और उसके Podfile कॉन्फ़िगरेशन के लिए वर्तमान डॉक्स का पालन करें।

Android जिम्मेदारियाँ

Android पर, जाँच करें:

न्यूनतम SDK और Java आवश्यकताएँ;
प्लगइन द्वारा जोड़े गए रिपॉजिटरी और निर्भरताएँ;
कैमरा, नेटवर्क और NFC मेनिफेस्ट प्रविष्टियाँ;
रनटाइम कैमरा-अनुमति व्यवहार;
Gradle और Kotlin संगतता;
नेटिव या क्रिप्टोग्राफिक निर्भरताओं के लिए पैकेजिंग नियम;
all, core, autodetection, या nfc SDK वेरिएंट;
रिलीज़-बिल्ड मिनिफिकेशन और संसाधन व्यवहार।

आपके उत्पाद को अभी भी अनुमति संदर्भ, अस्वीकृति पुनर्प्राप्ति, पहुंच और समर्थन निर्देशों की आवश्यकता है। अस्वीकृति, रुकावट, बैकग्राउंडिंग, रोटेशन और प्रक्रिया पुनर्निर्माण का परीक्षण करें।

बैकएंड पर सत्र बनाएं

आपके बैकएंड को सर्वर-साइड API कुंजी का उपयोग करके सत्र API को कॉल करना चाहिए। प्रत्येक सत्र को इससे संबद्ध करें:

आपका स्थिर ग्राहक पहचानकर्ता;
चयनित कार्यप्रवाह;
पर्यावरण;
जहाँ लागू हो, कॉलबैक या वापसी व्यवहार;
आवश्यक स्थानीय या संपर्क विवरण;
अपेक्षित ग्राहक विवरण जहाँ नीति उनका उपयोग करती है;
आंतरिक सहसंबंध और नीति मेटाडेटा।

डिडिट API कुंजी को कभी भी डार्ट, ऐप एसेट, पठनीय रिमोट कॉन्फ़िगरेशन या मोबाइल अनुरोध में एम्बेड न करें।

केवल सत्र टोकन और न्यूनतम लॉन्च स्थिति लौटाएँ। इसे विश्लेषण, क्रैश रिपोर्ट, लॉग, क्लिपबोर्ड उपयोग और दीर्घकालिक भंडारण से बाहर रखें।

प्रारंभ अनुरोधों को आइडम्पोटेंट बनाएं

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

आपके ऐप का लोडिंग बटन स्पष्ट दोहराए गए टैप को ब्लॉक करना चाहिए, लेकिन सर्वर-साइड आइडम्पोटेंसी आवश्यक बनी हुई है क्योंकि क्लाइंट पुनः प्रयास करते हैं और प्रक्रियाएं पुनरारंभ होती हैं।

डार्ट से सत्यापन शुरू करें

यह पूरा डार्ट उदाहरण केवल SDK आयात, विधि, परिणाम कक्षाओं, सत्र फ़ील्ड, स्थिति एनम और पैकेज स्रोत में सत्यापित त्रुटि फ़ील्ड का उपयोग करता है:

import 'package:didit_sdk/sdk_flutter.dart';

Future<void> runIdentityVerification(String sessionToken) async {
  try {
    final result = await DiditSdk.startVerification(
      sessionToken,
      config: const DiditConfig(
        loggingEnabled: false,
      ),
    );

    switch (result) {
      case VerificationCompleted(:final session):
        switch (session.status) {
          case VerificationStatus.approved:
            print('Flow completed with approved client status.');
          case VerificationStatus.pending:
            print('Flow completed and still needs a backend decision.');
          case VerificationStatus.declined:
            print('Flow completed with declined client status.');
        }
        print('Session ID: ${session.sessionId}');
        return;
      case VerificationCancelled():
        print('The user cancelled the verification flow.');
        return;
      case VerificationFailed(:final error):
        print('SDK error: ${error.type.name}: ${error.message}');
        return;
    }
  } catch (error, stackTrace) {
    print('Unexpected platform error: $error');
    print(stackTrace);
  }
}

उदाहरण प्रकार संरचना दिखाता है। एक वास्तविक ऐप को स्क्रीन स्थिति को अपडेट करना चाहिए और बैकएंड स्थिति को रीफ्रेश करना चाहिए, इस फ़ंक्शन से अकेले किसी खाते को कभी भी अनलॉक नहीं करना चाहिए।

`VerificationCompleted` हमेशा अनुमोदन क्यों नहीं है

VerificationCompleted में SessionData होता है, जिसकी status इनमें से एक है:

VerificationStatus.approved;
VerificationStatus.pending;
VerificationStatus.declined।

SDK फ़्लो समाप्त हो सकता है जबकि सत्यापन लंबित या अस्वीकृत रहता है। ऐप कॉल लौटने के बाद एक मानवीय समीक्षा या असमकालिक जाँच भी बैकएंड स्थिति को बदल सकती है। जब तक आपका बैकएंड नीति परिणाम की पुष्टि नहीं करता, तब तक अपनी स्थानीय UI स्थिति को “फ़्लो पूरा हो गया” के बजाय “पहचान स्वीकृत” नाम दें।

कोई फ़्लटर इनिशियलाइज़ कॉल नहीं है

सत्यापित सार्वजनिक फ़्लटर सतह कोई अलग आरंभीकरण विधि उजागर नहीं करती है। डार्ट में Android-नेटिव आरंभीकरण पैटर्न की प्रतिलिपि न करें। यदि Android फ़्लटर परिणाम के माध्यम से notInitialized रिपोर्ट करता है, तो इसे एक एकीकरण या नेटिव-ब्रिज समस्या के रूप में मानें और पैकेज सेटअप का निरीक्षण करें।

टाइप की गई त्रुटियों और पुनर्प्राप्ति को संभालें

SDK की सत्यापित त्रुटि प्रकार हैं:

त्रुटि प्रकार	ऐप नीति के लिए अर्थ	सुरक्षित पुनर्प्राप्ति
`sessionExpired`	टोकन अब इच्छित सत्र शुरू नहीं कर सकता है	बैकएंड से एक नया वैध सत्र माँगें
`networkError`	नेटिव फ़्लो नेटवर्क ऑपरेशन पूरा नहीं कर सका	संदर्भ को सुरक्षित रखें और एक सीमित पुनः प्रयास प्रदान करें
`cameraAccessDenied`	आवश्यक कैमरा एक्सेस अनुपलब्ध है	बताएँ कि इसकी आवश्यकता क्यों है और सेटिंग्स या वैकल्पिक मार्ग का मार्गदर्शन करें
`notInitialized`	Android नेटिव एकीकरण या ब्रिज तैयार नहीं है	रिलीज़ संदर्भ लॉग करें और सेटअप की जाँच करें
`apiError`	SDK या सेवा ने API-स्तर की विफलता लौटाई	केवल तभी पुनः प्रयास करें जब सुरक्षित हो; बैकएंड स्थिति का मिलान करें
`retryBlocked`	फ़्लो दूसरे स्वचालित प्रयास को रोकता है	लूप को रोकें और बैकएंड या समर्थन नीति का पालन करें
`unknown`	नेटिव त्रुटि ज्ञात डार्ट प्रकार से मैप नहीं हुई	एक सुरक्षित फ़ॉलबैक और सहसंबंध डेटा सुरक्षित रखें

नेटिव प्लेटफ़ॉर्म विभिन्न विवरण उजागर कर सकते हैं। एक unknown पथ रखें।

ग्राहक परिणामों से त्रुटियों को अलग करें

एक नेटवर्क विफलता एक अस्वीकृति नहीं है; कैमरा अस्वीकृति धोखाधड़ी नहीं है; रद्दीकरण विफल पहचान नहीं है। श्रेणियों को अलग-अलग रखें:

उपयोगकर्ता संदेश;
पुनः प्रयास नियम;
उत्पाद पहुंच;
समर्थन उपकरण;
विश्लेषण;
धोखाधड़ी और रूपांतरण रिपोर्टिंग।

बाउंड पुनः प्रयास

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

सत्य के स्रोत के रूप में बैकएंड इवेंट का उपयोग करें

SDK एक कॉम्पैक्ट क्लाइंट परिणाम देता है। पूर्ण प्रमाण और अंतिम स्थिति सर्वर-साइड एकीकरण के माध्यम से आती है। आपके वेबहुक हैंडलर को चाहिए:

दस्तावेज़ित हस्ताक्षर योजना द्वारा आवश्यक रूप में कच्चा अनुरोध प्राप्त करें;
इवेंट को प्रमाणित करें और ताजगी को मान्य करें;
अपने इवेंट पहचानकर्ता को डुप्लिकेट करें;
इसे अपेक्षित सत्र और ग्राहक से मैप करें;
पुराने इवेंट को बाद की टर्मिनल स्थिति को अधिलेखित करने से रोकें;
जब सुलह की आवश्यकता हो तो प्रामाणिक सत्र स्थिति पुनः प्राप्त करें;
अपनी नीति लागू करें और कारण को बनाए रखें;
प्रदाता के प्रतिक्रिया बजट के भीतर लौटें;
धीमे डाउनस्ट्रीम कार्य को असमकालिक रूप से संसाधित करें।

कम से कम एक बार डिलीवरी मान लें। डुप्लिकेट और आउट-ऑफ-ऑर्डर इवेंट सामान्य वितरित-सिस्टम व्यवहार हैं। प्रदाता इवेंट और आंतरिक संक्रमण को अलग से संग्रहीत करें ताकि एक ऑडिट दोनों का पुनर्निर्माण कर सके।

ऐप को केवल अपनी उत्पाद स्थिति के लिए आपके बैकएंड को पोल करना चाहिए या अपने सामान्य रीयल-टाइम चैनल का उपयोग करना चाहिए। इसे अंतिम रिकॉर्ड को सीधे पुनः प्राप्त करने के लिए एक प्रदाता API कुंजी को उजागर नहीं करना चाहिए।

एक लचीला फ़्लटर स्क्रीन जीवनचक्र बनाएं

स्पष्ट स्थानीय राज्यों का मॉडल करें

एक सत्यापन स्क्रीन का उपयोग कर सकती है:

निष्क्रिय;
सत्र का अनुरोध करना;
SDK लॉन्च करना;
SDK फ़्लो खुला;
बैकएंड निर्णय का मिलान करना;
समीक्षा की प्रतीक्षा में;
अनुमोदित;
अस्वीकृत;
पुनर्प्राप्त करने योग्य त्रुटि;
रद्द किया गया।

केवल वही बनाए रखें जो सुरक्षित है। प्रक्रिया मृत्यु के बाद, बैकएंड से पूछें कि क्या कोई सक्रिय या समाप्त सत्र पहले से मौजूद है। एक और प्रयास बनाने का निर्णय लेने के लिए इन-मेमोरी बूलियन पर भरोसा न करें।

विजेट जीवनचक्र का सम्मान करें

प्रतीक्षित कॉल के बाद, setState, डायलॉग या नेविगेशन से पहले mounted की जाँच करें। व्यावसायिक स्थिति को क्षणिक UI से बाहर रखें।

बैकग्राउंडिंग और रद्दीकरण को संभालें

ऐप स्विचिंग, स्क्रीन लॉक, नेविगेशन और प्रक्रिया समाप्ति का परीक्षण करें। फिर से शुरू करने, पुनरारंभ करने और सुलह व्यवहार को परिभाषित करें।

अनुमति पुनर्प्राप्ति डिज़ाइन करें

कैमरा या NFC की आवश्यकता समझाएँ। स्थायी अस्वीकृति के बाद, सेटिंग्स मार्गदर्शन या एक सुलभ वैकल्पिक मार्ग दिखाएँ।

नीति रिसाव के बिना कॉन्फ़िगरेशन

ऑफ़लाइन-सत्यापित फ़्लटर DiditConfig सतह languageCode, fontFamily, loggingEnabled, showCloseButton, showExitConfirmation, closeOnComplete, defaultDocumentCamera, defaultLivenessCamera, showDocumentCameraSwitchButton, और showLivenessCameraSwitchButton को उजागर करती है। कैमरा फ़ील्ड CameraLens.front या CameraLens.back का उपयोग करते हैं; सभी विकल्प डार्ट में टाइप किए गए हैं और नेटिव SDKs से मैप किए गए हैं।

तीन नियम रखें:

केवल विकास या नियंत्रित डायग्नोस्टिक बिल्ड के लिए वर्बोज़ लॉगिंग सक्षम करें;
बैकएंड नीति के विकल्प के रूप में UI कॉन्फ़िगरेशन का उपयोग न करें;
प्रत्येक समर्थित भाषा, कस्टम फ़ॉन्ट, क्लोज व्यवहार और कैमरा नीति का दोनों प्लेटफ़ॉर्म पर परीक्षण करें, जिसमें फ़ॉलबैक व्यवहार भी शामिल है जब अनुरोधित लेंस या संपत्ति अनुपलब्ध हो।

कार्यप्रवाह संरचना और उत्पाद ब्रांडिंग कंसोल या बैकएंड-प्रबंधित कार्यप्रवाह में होनी चाहिए बजाय मोबाइल फीचर फ्लैग के एक भूलभुलैया के। यह iOS, Android, वेब और समर्थन दृश्यों को संरेखित रखता है।

एकीकरण का परीक्षण करें

डार्ट और विजेट परीक्षण

एक एप्लिकेशन सेवा के पीछे SDK लॉन्च को लपेटें ताकि स्क्रीन परीक्षण वापस आ सकें:

पूरा और स्वीकृत;
पूरा और लंबित;
पूरा और अस्वीकृत;
रद्द किया गया;
प्रत्येक टाइप की गई विफलता;
एक अप्रत्याशित फेंका गया प्लेटफ़ॉर्म अपवाद।

लोडिंग-स्टेट क्लीनअप, माउंटेड चेक, पुनः प्रयास दृश्यता, बैकएंड रीफ्रेश और विश्लेषण श्रेणियों की पुष्टि करें। फिक्स्चर में वास्तविक सत्र टोकन न डालें।

नेटिव एकीकरण परीक्षण

भौतिक iOS और Android उपकरणों पर डिबग और रिलीज़ बिल्ड चलाएँ। कवर करें:

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

एक एमुलेटर स्थिति और त्रुटि परीक्षणों के लिए उपयोगी है लेकिन हर कैमरा, NFC, बायोमेट्रिक और डिवाइस-अखंडता की स्थिति का प्रतिनिधित्व नहीं कर सकता है।

एंड-टू-एंड बैकएंड परीक्षण

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

बायोमेट्रिक परीक्षण डिज़ाइन और हमले की सीमाओं के लिए, लाइवनेस परीक्षण गाइड देखें।

सुरक्षा और गोपनीयता चेकलिस्ट

रिलीज़ से पहले, पुष्टि करें कि:

स्थायी प्रदाता क्रेडेंशियल केवल बैकएंड पर मौजूद हैं;
ऐप को एक प्रमाणित चैनल पर एक स्कोप किया गया सत्र टोकन प्राप्त होता है;
लॉग, विश्लेषण, URL और क्रैश रिपोर्ट से टोकन और सबूत अनुपस्थित हैं;
बैकएंड बनाने के अनुरोध आइडम्पोटेंट हैं और एक स्थिर ग्राहक संदर्भ से बंधे हैं;
क्लाइंट पूर्णता कभी भी सीधे एक अधिकार प्रदान नहीं करती है;
वेबहुक हस्ताक्षर, ताजगी, डुप्लिकेट, ऑर्डरिंग और सुलह परीक्षण पास होते हैं;
iOS गोपनीयता विवरण और Android अनुमति यात्राएँ स्पष्ट उद्देश्य पाठ का उपयोग करती हैं;
NFC क्षमताएं और वेरिएंट कार्यप्रवाह और रिलीज़ हस्ताक्षर से मेल खाते हैं;
उत्पादन के लिए डिबग लॉगिंग अक्षम है;
धारण, सहमति, गोपनीयता सूचना, विलोपन और समर्थन पथ आपकी भूमिका और कानून से मेल खाते हैं;
SDK, नेटिव निर्भरता, OS और डिवाइस संगतता लॉन्च के बाद निगरानी की जाती है;
रोलबैक और जबरन-अपग्रेड निर्णयों के मालिक हैं।

सामान्य फ़्लटर SDK एकीकरण त्रुटियाँ

डार्ट में API कुंजी शिपिंग

मोबाइल एप्लिकेशन एक स्थायी सर्वर क्रेडेंशियल की रक्षा नहीं कर सकते। अपने बैकएंड पर सत्र बनाएं और एक स्कोप किया गया टोकन पास करें।

पूरे हुए कॉलबैक पर भरोसा करना

क्लाइंट परिणाम उपयोगकर्ता-इंटरफ़ेस स्थिति है। आधिकारिक स्थिति की पुष्टि करें और बैकएंड पर नीति लागू करें।

दूसरे प्लेटफ़ॉर्म से विधियों का आविष्कार करना

फ़्लटर हर नेटिव SDK विधि को एक ही नाम से उजागर नहीं करता है। पैकेज के विरुद्ध संकलित करें और एकीकरण कोड लिखने से पहले उसके सार्वजनिक डार्ट स्रोत की जाँच करें।

पुराने नेटिव कॉन्फ़िगरेशन की प्रतिलिपि बनाना

SDK वेरिएंट, परिनियोजन लक्ष्य और पैकेज-मैनेजर सेटअप बदलते रहते हैं। स्थापित रिलीज़ के लिए दस्तावेज़ों का पालन करें और इसे अपनी मोबाइल रिलीज़ चेकलिस्ट में रिकॉर्ड करें।

हर त्रुटि को अस्वीकृति के रूप में मानना

अनुमति, नेटवर्क, समाप्ति, API विफलता, रद्दीकरण और ग्राहक निर्णय को विभिन्न पुनर्प्राप्ति और विश्लेषण की आवश्यकता होती है।

केवल एक एमुलेटर पर परीक्षण करना

कैमरा, NFC, अनुमतियाँ, हस्ताक्षर और नेटिव निर्भरताओं को भौतिक-डिवाइस और रिलीज़-बिल्ड कवरेज की आवश्यकता होती है।

फ़्लटर पहचान कार्यप्रवाह में डिडिट का उपयोग करना

डिडिट फ़्लटर SDK को मुफ़्त के रूप में सूचीबद्ध किया गया है। यह पहचान सत्यापन, लाइवनेस डिटेक्शन, और अन्य कॉन्फ़िगर किए गए जांच वाले कार्यप्रवाहों को लॉन्च कर सकता है, जबकि टीमें कार्यप्रवाह ऑर्केस्ट्रेटर के माध्यम से सशर्त पथों का प्रबंधन करती हैं।

प्रकाशित मॉड्यूल दरें मूल्य निर्धारण पृष्ठ पर उपलब्ध हैं। SDK नेटिव कैप्चर अनुभव को संभालता है; आपका बैकएंड सत्र निर्माण, प्रमाणित परिणाम हैंडलिंग, ग्राहक स्थिति और उत्पाद निर्णयों के लिए जिम्मेदार रहता है।

अक्सर पूछे जाने वाले प्रश्न

कौन सी विधि सत्यापन शुरू करती है?

बैकएंड-निर्मित उत्पादन सत्र के लिए, DiditSdk.startVerification(sessionToken) को कॉल करें। SDK सरल कार्यप्रवाह-आईडी एकीकरण मोड के लिए DiditSdk.startVerificationWithWorkflow(...) को भी उजागर करता है।

क्या फ़्लटर ऐप में डिडिट API कुंजी होनी चाहिए?

नहीं। API कुंजी को बैकएंड पर रखें। ऐप को केवल उसके सत्यापन प्रयास के लिए आवश्यक स्कोप किया गया सत्र टोकन प्राप्त होना चाहिए।

क्या `VerificationCompleted` का अर्थ स्वीकृत है?

जरूरी नहीं। इसकी सत्र स्थिति स्वीकृत, लंबित या अस्वीकृत हो सकती है। तत्काल इंटरफ़ेस स्थिति के लिए परिणाम का उपयोग करें और अपने बैकएंड के माध्यम से आधिकारिक निर्णय की पुष्टि करें।

रद्दीकरण को कैसे संभाला जाना चाहिए?

इसे एक विशिष्ट उपयोगकर्ता परिणाम के रूप में मानें। बैकएंड सत्र स्थिति को सुरक्षित रखें, नीति के अनुसार एक स्पष्ट फिर से शुरू या पुनरारंभ पथ प्रदान करें, और रद्दीकरण को धोखाधड़ी या अस्वीकृति के रूप में लेबल न करें।

क्या फ़्लटर SDK में इनिशियलाइज़ विधि है?

सत्यापित सार्वजनिक डार्ट API कोई अलग आरंभीकरण विधि उजागर नहीं करता है। पैकेज के नेटिव सेटअप निर्देशों का पालन करें और दस्तावेज़ित प्रारंभ विधियों का उपयोग करें।

क्या फ़्लटर पहचान दस्तावेज़ों के लिए NFC का उपयोग कर सकता है?

नेटिव SDK NFC का समर्थन कर सकता है जब चयनित पैकेज वेरिएंट, डिवाइस, iOS या Android कॉन्फ़िगरेशन, हस्ताक्षर क्षमताएं और कार्यप्रवाह सभी इसे सक्षम करते हैं। वर्तमान रिलीज़ दस्तावेज़ों का पालन करें और भौतिक उपकरणों पर परीक्षण करें।

जब कोई मामला समीक्षा में हो तो ऐप को क्या करना चाहिए?

एक सच्ची लंबित स्थिति दिखाएँ, ग्राहक को सुरक्षित रूप से छोड़ने की अनुमति दें, और जब प्रमाणित परिणाम आए तो अपने बैकएंड से अंतिम उत्पाद स्थिति पढ़ें।

प्राथमिक संदर्भ

एक मजबूत फ़्लटर SDK एकीकरण प्रत्येक सीमा को स्पष्ट रखता है: बैकएंड प्रयास बनाता है, ऐप एक स्कोप किया गया नेटिव फ़्लो लॉन्च करता है, टाइप किए गए परिणाम पुनर्प्राप्ति को संचालित करते हैं, प्रमाणित सर्वर इवेंट ग्राहक स्थिति को संचालित करते हैं, और वास्तविक-डिवाइस परीक्षण साबित करते हैं कि अनुमतियाँ, जीवनचक्र, नेटिव निर्भरताएँ और विफलता पथ हैप्पी-पाथ डेमो के बाहर काम करते हैं।

आगे पढ़ें