المدونة · 28 يوليو 2026

دمج التحقق من الهوية في تطبيقات Flutter باستخدام Didit SDK (AR)

دليل للمطورين لإضافة التحقق من الهوية إلى تطبيق Flutter باستخدام Didit SDK: الإعداد الأصلي، الجلسات التي تم إنشاؤها من الواجهة الخلفية، معالجة نتائج Dart، الأخطاء المكتوبة، webhooks، الاختبار، الأمان، وعمليات الإصدار.

بواسطة Didit28 يوليو 2026تحديث 28 يوليو 2026

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

يجب أن يحافظ تكامل Flutter SDK للتحقق من الهوية على بيانات الاعتماد الدائمة والتفويض النهائي في الواجهة الخلفية الخاصة بك، بينما يطلق تطبيق الهاتف المحمول تدفق التقاط أصليًا باستخدام رمز جلسة قصير الأجل. يكشف Didit Flutter SDK عن واجهة برمجة تطبيقات Dart واحدة عبر حزم SDK الأصلية للتحقق من iOS و Android، ويعيد نتائج مكتوبة لإكمال العملية أو إلغائها أو فشلها إلى التطبيق. لا يزال القرار الكامل يعود إلى webhook الواجهة الخلفية أو تدفق الاسترداد.

يستخدم هذا الدليل فقط طرق Dart وأنواع النتائج التي تم التحقق منها مقابل مصدر واختبارات SDK المحلية الحالية. تتغير تفاصيل التبعية الأصلية عبر الإصدارات، لذا يتم وصف تكوين النظام الأساسي حسب المسؤولية وربطه بدليل SDK الأساسي بدلاً من نسخ Podfile أو كتلة Gradle الحساسة للإصدار.

النقاط الرئيسية

إنشاء جلسات الإنتاج في الواجهة الخلفية. حافظ على مفتاح API بعيدًا عن الجهاز وأرسل فقط رمز الجلسة الذي يحتاجه SDK.
استخدم نتيجة Dart المكتوبة لتجربة المستخدم، وليس للترخيص. تعني VerificationCompleted أن تدفق SDK قد انتهى؛ افحص الحالة للعرض وانتظر قرار الواجهة الخلفية الموثوق به.
تعامل مع الإلغاء، والأخطاء المكتوبة، وأخطاء النظام الأساسي غير المتوقعة بشكل منفصل. إنها تحتاج إلى استرداد وتحليلات مختلفة.
تعامل مع الإعداد الأصلي كبنية تحتية للإصدار. يجب اختبار مفاتيح خصوصية iOS، واستحقاقات الاتصال قريب المدى (NFC)، وأهداف النشر، وتبعيات Android، والتغليف، والأذونات على الأجهزة الحقيقية.
صمم دورة الحياة بأكملها. يشكل إنشاء الجلسة، وتسليم التطبيق، والتقاط، والتحقق من webhook، وتغييرات الحالة المتساوية، والمراجعة، وإعادة المحاولات، وإمكانية المراقبة تكاملاً واحدًا.

ماذا يفعل Didit Flutter SDK

تغلف حزمة didit_sdk حزم SDK الأصلية لنظامي iOS و Android خلف واجهة Dart مشتركة. تطلق واجهة المستخدم للتحقق كتدفق أصلي بملء الشاشة وتعود عندما يكمل المستخدم أو يلغي أو يواجه خطأ.

يمكن لـ SDK إطلاق مهام سير العمل باستخدام التحقق من الهوية، اكتشاف النشاط الحي، والفحوصات الأخرى المكونة. تحدد مهمة سير العمل الخطوات التي تظهر؛ لا يقوم استدعاء Flutter بترميزها بشكل ثابت.

سطح Dart العام ذو الصلة بدورة الحياة هو:

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

للإنتاج، يفضل startVerification مع رمز تم إنشاؤه من الواجهة الخلفية. طريقة معرف سير العمل أبسط ولكنها تمنح الواجهة الخلفية تحكمًا أقل في المعلمات المتقدمة.

البنية: الواجهة الخلفية، تطبيق Flutter، SDK، وwebhook

يحتوي تدفق الإنتاج على أربعة حدود ثقة:

المكون	يمتلك	يجب ألا يمتلك
الواجهة الخلفية الخاصة بك	مفتاح API، اختيار سير العمل، مرجع العميل، إنشاء الجلسة، الحالة النهائية للعميل	واجهة الكاميرا
تطبيق Flutter	طلب التسليم، واجهة مستخدم التحميل والاسترداد، إطلاق SDK، التحليلات المحلية	مفتاح API دائم أو تفويض نهائي
Didit Flutter SDK	التقاط أصلي وتدفق تحقق مكون	قرار استحقاق المنتج الخاص بك
عامل Webhook/الاسترداد	استيعاب النتائج المصادق عليها، إزالة التكرار، المطابقة	افتراضات العميل غير المتحقق منها

التسلسل هو:

يطلب تطبيق Flutter الذي تم تسجيل الدخول إليه من الواجهة الخلفية الخاصة بك بدء التحقق.
تنشئ الواجهة الخلفية الخاصة بك جلسة تحقق باستخدام سير العمل المقصود ومرجع عميل داخلي مستقر.
تُرجع الواجهة الخلفية session_token المحدود النطاق إلى التطبيق.
يمرر التطبيق هذا الرمز المميز إلى DiditSdk.startVerification.
يعرض SDK التدفق الأصلي ويعيد نتيجة مكتوبة لتجربة المستخدم الفورية.
تتلقى الواجهة الخلفية الخاصة بك حدث النتيجة وتتحقق منه، وتطابق الحالة الأساسية، وتحدث العميل بموجب سياستك.
يقرأ التطبيق حالة العميل في الواجهة الخلفية قبل منح الوصول أو المطالبة بالموافقة النهائية.

لا تثق هذه البنية في شاشة نجاح على الجهاز.

للعقد من جانب الخادم وحدود الحدث، راجع دليل تقييم تكامل API للتحقق من الهوية.

تثبيت الحزمة

استخدم أمر الحزمة بدلاً من نسخ إصدار قد يصبح قديمًا:

flutter pub add didit_sdk

ثم استورد المكتبة العامة:

import 'package:didit_sdk/sdk_flutter.dart';

قبل الترقية، اقرأ سجل التغييرات ووثائق Flutter SDK الرسمية. تحقق من متطلبات النظام الأساسي المعلنة مقابل تطبيقك وصور CI.

اتبع تعليمات إصدار Flutter للتبعيات الأصلية؛ قد يؤدي خلط الإصدارات التعسفية إلى عدم التوافق.

تكوين iOS و Android

مسؤوليات iOS

يمكن أن يستخدم التقاط الهوية أجهزة وبيانات محمية. اعتمادًا على سير العمل المكون ومتغير SDK، قد يتطلب إعداد iOS ما يلي:

هدف نشر مناسب؛
أوصاف استخدام الكاميرا والميكروفون؛
وصف استخدام مكتبة الصور إذا كان يسمح بالتحميل؛
وصف استخدام NFC واستحقاقات الاتصال قريب المدى عند تمكين قراءة الشريحة؛
تكوين CocoaPods متوافق؛
قدرات التوقيع وتوفير تتوافق مع استخدام NFC؛
خطوط مخصصة مسجلة إذا تم تكوين خط خاص بالتطبيق.

قد يؤدي فقدان سلاسل غرض الخصوصية إلى إنهاء تطبيق iOS. اختبر سير العمل الدقيق على جهاز مادي.

يمكن أن يؤدي دعم NFC إلى رفع الحد الأدنى لهدف النشر أو إضافة تبعيات أصلية. اختر متغير SDK الذي يتوافق مع سير عملك واتبع الوثائق الحالية لتكوين Podfile الخاص به.

مسؤوليات Android

على Android، تحقق من:

الحد الأدنى لمتطلبات SDK و Java؛
المستودعات والتبعيات المضافة بواسطة المكون الإضافي؛
إدخالات بيان الكاميرا والشبكة و NFC؛
سلوك إذن الكاميرا في وقت التشغيل؛
توافق Gradle و Kotlin؛
قواعد التغليف للتبعيات الأصلية أو التشفيرية؛
متغير SDK all، core، autodetection، أو nfc؛
تصغير بناء الإصدار وسلوك الموارد.

لا يزال منتجك يحتاج إلى سياق الأذونات، واسترداد الرفض، وإمكانية الوصول، وتعليمات الدعم. اختبر الرفض، والانقطاع، والتشغيل في الخلفية، والدوران، وإعادة إنشاء العملية.

إنشاء جلسات في الواجهة الخلفية

يجب أن تستدعي الواجهة الخلفية الخاصة بك واجهة برمجة تطبيقات الجلسة باستخدام مفتاح API من جانب الخادم. اربط كل جلسة بما يلي:

معرف العميل المستقر الخاص بك؛
سير العمل المحدد؛
البيئة؛
سلوك رد الاتصال أو الإرجاع حيثما ينطبق ذلك؛
اللغة المطلوبة أو تفاصيل الاتصال؛
تفاصيل العميل المتوقعة حيث تستخدمها السياسة؛
الارتباط الداخلي وبيانات التعريف للسياسة.

لا تقم أبدًا بتضمين مفتاح Didit API في Dart، أو أصول التطبيق، أو التكوين البعيد القابل للقراءة، أو طلب الهاتف المحمول.

أعد فقط رمز الجلسة والحد الأدنى من حالة التشغيل. حافظ عليه بعيدًا عن التحليلات، وتقارير الأعطال، والسجلات، واستخدام الحافظة، والتخزين طويل الأجل.

اجعل طلبات البدء متساوية

يمكن للعميل النقر مرتين، أو فقدان الاتصال بعد أن تنشئ الواجهة الخلفية جلسة، أو إعادة فتح الشاشة بينما تكون محاولة نشطة. استخدم معرف طلب مستقر ومنطق الواجهة الخلفية الذي يعيد المحاولة المناسبة الموجودة بدلاً من إنشاء نسخ مكررة غير متصلة.

يجب أن يمنع زر التحميل في تطبيقك النقرات المتكررة الواضحة، ولكن لا تزال المساواة من جانب الخادم ضرورية لأن العملاء يعيدون المحاولة وتتم إعادة تشغيل العمليات.

بدء التحقق من Dart

يستخدم مثال Dart الكامل هذا فقط استيراد 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 بينما يظل التحقق معلقًا أو مرفوضًا. يمكن أن تؤدي المراجعة البشرية أو الفحص غير المتزامن أيضًا إلى تغيير حالة الواجهة الخلفية بعد عودة استدعاء التطبيق. سمِّ حالة واجهة المستخدم المحلية “اكتمل التدفق” بدلاً من “تمت الموافقة على الهوية” حتى تؤكد الواجهة الخلفية الخاصة بك نتيجة السياسة.

لا يوجد استدعاء تهيئة Flutter

لا يكشف سطح Flutter العام المتحقق منه عن طريقة تهيئة منفصلة. لا تقم بنسخ نمط تهيئة Android الأصلي إلى Dart. إذا أبلغ Android عن notInitialized من خلال نتيجة Flutter، فتعامل معه على أنه مشكلة تكامل أو جسر أصلي وافحص إعداد الحزمة.

التعامل مع الأخطاء المكتوبة والاسترداد

أنواع أخطاء SDK التي تم التحقق منها هي:

نوع الخطأ	المعنى لسياسة التطبيق	استرداد آمن
`sessionExpired`	لم يعد الرمز المميز قادرًا على بدء الجلسة المقصودة	اطلب من الواجهة الخلفية جلسة جديدة صالحة
`networkError`	لم يتمكن التدفق الأصلي من إكمال عملية شبكة	الحفاظ على السياق وتقديم إعادة محاولة محدودة
`cameraAccessDenied`	الوصول المطلوب إلى الكاميرا غير متاح	اشرح سبب الحاجة إليه ووجه الإعدادات أو المسار البديل
`notInitialized`	تكامل Android الأصلي أو الجسر غير جاهز	سجل سياق الإصدار وافحص الإعداد
`apiError`	أرجع SDK أو الخدمة فشلًا على مستوى API	أعد المحاولة فقط عندما يكون آمنًا؛ طابق حالة الواجهة الخلفية
`retryBlocked`	يمنع التدفق محاولة تلقائية أخرى	أوقف الحلقة واتبع سياسة الواجهة الخلفية أو الدعم
`unknown`	لم يتم تعيين الخطأ الأصلي إلى نوع Dart معروف	الحفاظ على احتياطي آمن وبيانات الارتباط

يمكن أن تكشف المنصات الأصلية عن تفاصيل مختلفة. احتفظ بمسار unknown.

فصل الأخطاء عن نتائج العملاء

فشل الشبكة ليس رفضًا؛ حرمان الكاميرا ليس احتيالًا؛ الإلغاء ليس فشلًا في الهوية. حافظ على فصل الفئات في:

رسائل المستخدم؛
قواعد إعادة المحاولة؛
الوصول إلى المنتج؛
أدوات الدعم؛
التحليلات؛
تقارير الاحتيال والتحويل.

إعادة محاولة محدودة

دع الواجهة الخلفية تقرر ما إذا كان يمكن للجلسة الحالية أن تستمر أو إذا كانت هناك حاجة إلى جلسة جديدة. تجنب حلقة لا نهائية تستدعي SDK بشكل متكرر باستخدام رمز منتهي الصلاحية أو محظور. تتبع عدد المحاولات والسبب دون تسجيل الرمز أو دليل الهوية.

استخدم أحداث الواجهة الخلفية كمصدر وحيد للحقيقة

يعيد SDK نتيجة عميل مدمجة. تصل الأدلة الكاملة والحالة النهائية من خلال تكامل جانب الخادم. يجب على معالج webhook الخاص بك ما يلي:

تلقي الطلب الخام بالشكل المطلوب بواسطة مخطط التوقيع الموثق؛
مصادقة الحدث والتحقق من حداثته؛
إزالة تكرار معرف الحدث الخاص به؛
ربطه بالجلسة والعميل المتوقعين؛
منع الأحداث الأقدم من الكتابة فوق الحالة النهائية اللاحقة؛
استرداد حالة الجلسة الأساسية عند الحاجة إلى المطابقة؛
تطبيق سياستك والاحتفاظ بالسبب؛
العودة ضمن ميزانية استجابة المزود؛
معالجة العمل البطيء في المراحل اللاحقة بشكل غير متزامن.

افترض التسليم مرة واحدة على الأقل. الأحداث المكررة وغير المرتبة هي سلوك عادي للنظام الموزع. قم بتخزين حدث المزود والانتقال الداخلي بشكل منفصل حتى يتمكن التدقيق من إعادة بناء كليهما.

يجب أن يستطلع التطبيق الواجهة الخلفية الخاصة بك فقط لحالة المنتج الخاصة به أو يستخدم قناتك العادية في الوقت الفعلي. لا يجب أن يكشف مفتاح API للمزود لاسترداد السجل النهائي مباشرة.

بناء دورة حياة شاشة Flutter مرنة

نموذج الحالات المحلية الصريحة

يمكن أن تستخدم شاشة التحقق ما يلي:

خامل؛
طلب الجلسة؛
إطلاق SDK؛
تدفق SDK مفتوح؛
مطابقة قرار الواجهة الخلفية؛
في انتظار المراجعة؛
تمت الموافقة؛
تم الرفض؛
خطأ قابل للاسترداد؛
تم الإلغاء.

احتفظ فقط بما هو آمن. بعد تعطيل العملية، اسأل الواجهة الخلفية عما إذا كانت هناك جلسة نشطة أو منتهية بالفعل. لا تعتمد على قيمة منطقية في الذاكرة لتقرير ما إذا كنت ستنشئ محاولة أخرى.

احترم دورة حياة الودجت

بعد الاستدعاء المنتظر، تحقق من mounted قبل setState، أو مربعات الحوار، أو التنقل. احتفظ بحالة العمل خارج واجهة المستخدم العابرة.

التعامل مع التشغيل في الخلفية والإلغاء

اختبر تبديل التطبيقات، وقفل الشاشة، والتنقل، وإنهاء العملية. حدد سلوك الاستئناف، وإعادة التشغيل، والمطابقة.

تصميم استرداد الأذونات

اشرح الحاجة إلى الكاميرا أو NFC. بعد الرفض الدائم، أظهر إرشادات الإعدادات أو مسارًا بديلاً يمكن الوصول إليه.

التكوين دون تسرب السياسة

يكشف سطح Flutter DiditConfig الذي تم التحقق منه دون اتصال بالإنترنت عن languageCode، fontFamily، loggingEnabled، showCloseButton، showExitConfirmation، closeOnComplete، defaultDocumentCamera، defaultLivenessCamera، showDocumentCameraSwitchButton، و showLivenessCameraSwitchButton. تستخدم حقول الكاميرا CameraLens.front أو CameraLens.back؛ يتم كتابة جميع الخيارات في Dart وتعيينها إلى حزم SDK الأصلية.

احتفظ بثلاث قواعد:

تمكين التسجيل المطول فقط للتطوير أو بناء تشخيصي متحكم فيه؛
لا تستخدم تكوين واجهة المستخدم كبديل لسياسة الواجهة الخلفية؛
اختبر كل لغة مدعومة، وخط مخصص، وسلوك إغلاق، وسياسة كاميرا على كلا المنصتين، بما في ذلك سلوك الاحتياطي عندما تكون العدسة المطلوبة أو الأصل غير متاح.

ينتمي تكوين سير العمل وعلامة المنتج التجارية إلى وحدة التحكم أو سير العمل الذي تديره الواجهة الخلفية بدلاً من متاهة من علامات ميزات الهاتف المحمول. وهذا يحافظ على توافق عروض iOS و Android والويب والدعم.

اختبار التكامل

اختبارات Dart والودجت

قم بتغليف إطلاق SDK خلف خدمة تطبيق بحيث يمكن لاختبارات الشاشة أن تعيد:

اكتمل ووافق عليه؛
اكتمل ومعلق؛
اكتمل ورفض؛
ألغيت؛
كل فشل مكتوب؛
استثناء نظام أساسي غير متوقع تم إلقاؤه.

تأكد من تنظيف حالة التحميل، وفحوصات التثبيت، ورؤية إعادة المحاولة، وتحديث الواجهة الخلفية، وفئات التحليلات. لا تضع رموز جلسة حقيقية في التركيبات.

اختبارات التكامل الأصلية

قم بتشغيل إصدارات التصحيح والإصدار على أجهزة iOS و Android المادية. غطِ ما يلي:

الأذونات لأول مرة والتي تم اتخاذ قرار بشأنها مسبقًا؛
الكاميرات المدعومة وغير المدعومة؛
متغيرات NFC الممكّنة وغير الممكّنة حيثما يتم استخدامها؛
الإضاءة المنخفضة، والضبابية، والوهج، والاتجاه؛
الاتصال البطيء، والمفقود، والمستعاد؛
التشغيل في الخلفية وإعادة إنشاء العملية؛
الإلغاء والإطلاق المتكرر؛
انتهاء صلاحية الجلسة وحظر إعادة المحاولة؛
لغات مختلفة، وتوسيع الخط، وقارئات الشاشة، والحركة المخفضة؛
توقيع التطبيق، والتصغير، وحل تبعية الإنتاج.

المحاكي مفيد لاختبارات الحالة والأخطاء ولكنه لا يمكنه تمثيل كل حالة كاميرا، و NFC، والقياسات الحيوية، وسلامة الجهاز.

اختبارات الواجهة الخلفية الشاملة

استخدم حالات صندوق الحماية الحتمية لكل حالة عميل موثقة. أعد تشغيل أحداث الاختبار الموقعة، وأرسل نسخًا مكررة غير مرتبة، وأخر المراجعة، وطابق بعد webhook محاكي لم يتم تلقيه. تأكد من أن التطبيق لا يمنح الوصول أبدًا قبل تغيير حالة الواجهة الخلفية الخاصة بك.

لتصميم اختبار القياسات الحيوية وحدود الهجوم، راجع دليل اختبار النشاط الحي.

قائمة مراجعة الأمان والخصوصية

قبل الإصدار، تأكد من أن:

بيانات اعتماد المزود الدائمة موجودة فقط في الواجهة الخلفية؛
يتلقى التطبيق رمز جلسة محدد النطاق عبر قناة مصادق عليها؛
لا توجد الرموز المميزة والأدلة في السجلات، والتحليلات، وعناوين URL، وتقارير الأعطال؛
طلبات إنشاء الواجهة الخلفية متساوية ومرتبطة بمرجع عميل مستقر؛
إكمال العميل لا يمنح استحقاقًا مباشرًا أبدًا؛
تجاوز اختبارات توقيع webhook، والحداثة، والتكرار، والترتيب، والمطابقة؛
تستخدم أوصاف خصوصية iOS ورحلات أذونات Android نصًا واضحًا للغرض؛
تتوافق قدرات ومتغيرات NFC مع سير العمل وتوقيع الإصدار؛
تعطيل تسجيل التصحيح للإنتاج؛
تتوافق مسارات الاحتفاظ، والموافقة، وإشعار الخصوصية، والحذف، والدعم مع دورك والقانون؛
يتم مراقبة توافق SDK، والتبعيات الأصلية، ونظام التشغيل، والجهاز بعد الإطلاق؛
يوجد مالكون لقرارات التراجع والترقية القسرية.

أخطاء تكامل Flutter SDK الشائعة

شحن مفتاح API في Dart

لا يمكن لتطبيقات الهاتف المحمول حماية بيانات اعتماد خادم دائمة. قم بإنشاء جلسات على الواجهة الخلفية الخاصة بك ومرر رمزًا مميزًا محدد النطاق.

الثقة باستدعاء الإكمال

نتيجة العميل هي حالة واجهة المستخدم. تأكد من الحالة الموثوقة وطبق السياسة في الواجهة الخلفية.

اختراع طرق من منصة أخرى

لا يكشف Flutter عن كل طريقة SDK أصلية تحت نفس الاسم. قم بالتحويل البرمجي مقابل الحزمة وتحقق من مصدر Dart العام الخاص بها قبل كتابة كود التكامل.

نسخ تكوين أصلي قديم

تتغير متغيرات SDK، وأهداف النشر، وإعداد مدير الحزم. اتبع الوثائق الخاصة بالإصدار المثبت وسجلها في قائمة مراجعة إصدار الهاتف المحمول الخاص بك.

معاملة كل خطأ على أنه رفض

يتطلب الفشل في الأذونات، والشبكة، وانتهاء الصلاحية، وواجهة برمجة التطبيقات، والإلغاء، وقرار العميل استردادًا وتحليلات مختلفة.

الاختبار فقط على المحاكي

تتطلب الكاميرا، و NFC، والأذونات، والتوقيع، والتبعيات الأصلية تغطية الجهاز المادي وبناء الإصدار.

استخدام Didit في سير عمل هوية Flutter

يتم إدراج Didit Flutter SDK مجانًا. يمكنه إطلاق مهام سير العمل التي تحتوي على التحقق من الهوية، اكتشاف النشاط الحي، والفحوصات الأخرى المكونة، بينما تدير الفرق المسارات الشرطية من خلال منظم سير العمل.

تتوفر أسعار الوحدات المنشورة على صفحة التسعير. يتعامل SDK مع تجربة الالتقاط الأصلية؛ تظل الواجهة الخلفية الخاصة بك مسؤولة عن إنشاء الجلسة، ومعالجة النتائج المصادق عليها، وحالة العميل، وقرارات المنتج.

الأسئلة المتداولة

ما هي الطريقة التي تبدأ التحقق؟

لجلسة إنتاج تم إنشاؤها من الواجهة الخلفية، استدعِ DiditSdk.startVerification(sessionToken). يكشف SDK أيضًا عن DiditSdk.startVerificationWithWorkflow(...) لوضع تكامل معرف سير العمل الأبسط.

هل يجب أن يحتوي تطبيق Flutter على مفتاح Didit API؟

لا. حافظ على مفتاح API في الواجهة الخلفية. يجب أن يتلقى التطبيق فقط رمز الجلسة المحدد النطاق المطلوب لمحاولة التحقق.

هل تعني `VerificationCompleted` الموافقة؟

ليس بالضرورة. يمكن أن تكون حالة جلسته معتمدة، أو معلقة، أو مرفوضة. استخدم النتيجة لحالة الواجهة الفورية وتأكد من القرار الموثوق به من خلال الواجهة الخلفية الخاصة بك.

كيف يجب التعامل مع الإلغاء؟

تعامل معه كناتج مستخدم مميز. حافظ على حالة جلسة الواجهة الخلفية، وقدم مسار استئناف أو إعادة تشغيل واضحًا وفقًا للسياسة، ولا تصنف الإلغاء على أنه احتيال أو رفض.

هل يحتوي Flutter SDK على طريقة تهيئة؟

لا يكشف API العام الموثق لـ Dart عن طريقة تهيئة منفصلة. اتبع تعليمات الإعداد الأصلية للحزمة واستخدم طرق البدء الموثقة.

هل يمكن لـ Flutter استخدام NFC لوثائق الهوية؟

يمكن لـ SDK الأصلي دعم NFC عندما يمكن لمتغير الحزمة المحدد، والجهاز، وتكوين iOS أو Android، وقدرات التوقيع، وسير العمل جميعًا تمكينه. اتبع وثائق الإصدار الحالية واختبر على الأجهزة المادية.

ماذا يجب أن يفعل التطبيق بينما تكون الحالة قيد المراجعة؟

أظهر حالة معلقة صادقة، واسمح للعميل بالمغادرة بأمان، واقرأ الحالة النهائية للمنتج من الواجهة الخلفية الخاصة بك عندما تصل النتيجة المصادق عليها.

المراجع الأساسية

يحافظ تكامل Flutter SDK القوي على وضوح كل حد: تنشئ الواجهة الخلفية المحاولة، ويطلق التطبيق تدفقًا أصليًا محدد النطاق، وتقود النتائج المكتوبة الاسترداد، وتقود أحداث الخادم المصادق عليها حالة العميل، وتثبت اختبارات الجهاز الحقيقي أن الأذونات، ودورة الحياة، والتبعيات الأصلية، ومسارات الفشل تعمل خارج العرض التوضيحي للمسار السعيد.

تابع القراءة