Building Robust Liveness Fallback Logic with Didit Webhooks

Dynamic Risk AssessmentLeverage Didit's liveness detection reports and configurable warning thresholds to make informed, real-time decisions about verification outcomes.

Automated Fallback WorkflowsProgrammatically trigger alternative verification methods or manual reviews when initial liveness checks yield uncertain or high-risk results, improving conversion rates without compromising security.

Seamless User ExperienceDesign adaptive user journeys that guide legitimate users through necessary steps while effectively deterring fraudsters through intelligent fallback logic.

Didit's Modular AdvantageDidit's AI-native Liveness Detection, combined with webhooks and a no-code orchestration engine, allows businesses to build highly customizable and resilient identity verification workflows with Free Core KYC.

In the evolving landscape of digital identity, robust liveness detection is paramount for preventing spoofing attacks and ensuring that a real, live person is behind every transaction. However, no system is infallible, and sometimes, a liveness check might return an 'In Review' status, a low confidence score, or specific warnings that require further investigation. This is where programmable fallback logic becomes essential. By building intelligent fallback mechanisms, businesses can maintain high security standards while optimizing the user experience and minimizing friction for legitimate users.

Understanding Liveness Detection Outcomes and Warnings

Didit's Liveness Detection goes beyond a simple pass/fail. Our system provides a comprehensive report, including a liveness status (Approved, Declined, In Review), a confidence score, and detailed warnings. These warnings are crucial for understanding why a liveness check might not have been definitively 'Approved' and for informing your fallback strategy.

For instance, Didit's Liveness Detection Warnings outline various scenarios:

• NO_FACE_DETECTED: An automatic decline condition, indicating no face was found.
• LIVENESS_FACE_ATTACK: Another automatic decline, signaling a potential spoofing attempt.
• FACE_IN_BLOCKLIST: An automatic decline if the face matches an entry in your blocklist.
• LOW_LIVENESS_SCORE: Configurable thresholds allow you to set scores that trigger 'In Review' or 'Declined' statuses.
• POSSIBLE_DUPLICATED_FACE / DUPLICATED_FACE: Flags potential duplicate identities.
• MULTIPLE_FACES_DETECTED: (For Passive Liveness) Indicates more than one face was present.
• LOW_FACE_QUALITY / LOW_FACE_LUMINANCE / HIGH_FACE_LUMINANCE: Warnings related to image quality that might hinder accurate detection.

Each of these warnings provides valuable context. A low liveness score due to poor lighting (LOW_FACE_LUMINANCE) might warrant a re-attempt with instructions, while a POSSIBLE_DUPLICATED_FACE might trigger a deeper investigation or require additional identity proofs. Didit's Liveness Detection offers three primary methods: ACTIVE_3D, FLASHING, and PASSIVE, each with varying security levels and user interaction requirements. Understanding these methods and their outputs is key to designing effective fallback logic.

Designing Intelligent Fallback Strategies

Programmable fallback logic isn't about weakening security; it's about making your verification process more resilient and user-friendly. Here are common scenarios and how to approach them:

Scenario 1: Low Liveness Score / Poor Face Quality

If a user receives a low liveness score or the system flags low face quality (e.g., LOW_FACE_QUALITY, LOW_FACE_LUMINANCE), it often points to environmental factors or user error rather than outright fraud. Instead of an immediate decline, your fallback logic could:

• Prompt the user to re-attempt the liveness check with clearer instructions (e.g., "Please ensure good lighting and hold your device steady").
• Switch from a PASSIVE liveness check to a more robust FLASHING or ACTIVE_3D method, which provides higher assurance.
• If multiple re-attempts fail, escalate to a manual review, where an agent can assess the provided media (Didit's liveness report includes reference_image and video_url).

Scenario 2: Possible Duplicate Face

When Didit's 1:1 Face Match or Face Search detects a POSSIBLE_DUPLICATED_FACE, it's a red flag that requires attention. Your fallback logic could:

• Request additional forms of ID verification (e.g., a secondary document scan using Didit's ID Verification).
• Trigger a knowledge-based authentication (KBA) challenge.
• Initiate a manual review, possibly cross-referencing with other internal databases or leveraging Didit's AML Screening for enhanced due diligence.

Scenario 3: 'In Review' Status

An 'In Review' status signifies that the system couldn't definitively approve or decline the liveness check, often due to a combination of minor warnings or borderline scores. This is a prime candidate for automated fallback to a manual review queue. The webhook notification would include all the necessary details from the liveness report for an agent to make an informed decision, including the score, method, and any associated warnings.

Implementing Fallback with Didit Webhooks

Didit's modular architecture and webhooks are designed precisely for building such dynamic workflows. When a liveness check is completed, Didit can send a webhook notification to your system with the full liveness report, including the status, score, method, and any warnings. Your application then processes this JSON payload and executes predefined logic.

Here's a simplified example of how your webhook handler might work:

1. Receive Webhook: Your endpoint receives a JSON payload from Didit containing the liveness object.
2. Parse Status & Score: Extract liveness.status and liveness.score.
3. Check Warnings: Iterate through liveness.warnings for specific risk indicators.
4. Execute Logic:
   • If status == 'Approved': Proceed with onboarding.
   • If status == 'Declined' and LIVENESS_FACE_ATTACK or FACE_IN_BLOCKLIST: Block user, alert fraud team.
   • If status == 'Declined' due to LOW_LIVENESS_SCORE (below a strict threshold): Prompt user for re-attempt with improved instructions.
   • If status == 'In Review' or LOW_FACE_QUALITY: Queue for manual review, or offer an alternative verification method.
   • If POSSIBLE_DUPLICATED_FACE: Request additional ID proofs.

This allows you to programmatically react to every nuance of the liveness detection outcome, creating a highly customized and secure user journey.

How Didit Helps

Didit is the AI-native, developer-first identity platform that empowers businesses to build sophisticated verification workflows, including robust fallback logic for Liveness Detection. Our modular architecture means you can seamlessly integrate our advanced Passive & Active Liveness capabilities with other identity primitives like ID Verification and 1:1 Face Match.

We provide comprehensive Liveness Detection, offering 99.9% accuracy and multiple methods (3D Action & Flash, 3D Flash, Passive) to suit various security needs. Our detailed liveness reports and configurable warning thresholds give you the granular data required to build intelligent fallback logic. With Didit's webhooks and a no-code orchestration engine, you can define complex rules that automatically trigger re-attempts, manual reviews, or alternative verification steps, ensuring both security and a smooth user experience.

Didit stands out with Free Core KYC, no setup fees, and a pay-per-successful-check model, making advanced identity verification accessible to businesses of all sizes. Our AI-native approach ensures that our Liveness Detection is continuously learning and adapting to new spoofing techniques, keeping your platform secure against emerging threats.

Ready to Get Started?

Ready to see Didit in action? Get a free demo today.

Start verifying identities for free with Didit's free tier.