Integrating an active liveness detection API is not just a camera prompt followed by a success response. The implementation must answer a defined risk question, bind the result to the right transaction and give users a safe next step when the check is inconclusive. Start with the decision and journey, then shape the API contract around them.
What should an active liveness check establish?
An active liveness check asks a person to respond to an instruction during capture. It helps assess whether a live person is present rather than a static image or replay. That is a useful signal, but it is not proof of a legal identity, account ownership or benign intent. Keep those questions separate in product copy, policy and code.
Write the intended decision in plain language before choosing a prompt. It might be, “Should this session proceed to account creation?” or, “Does this recovery attempt need an additional check?” Specify what the liveness result contributes, what other evidence is needed and which outcomes the application can return. A signal can inform a decision without becoming the entire decision.
VerifEye confirms human presence and uniqueness without documents, processes verification on-device and does not store images. Presence, same-person matching and uniqueness answer different questions. If a flow needs to match a person to an existing account, define that as a distinct requirement and test it separately.
Where should the check sit in the journey?
Place the prompt where its result can change a meaningful outcome. Asking every user too early adds friction before there is a clear reason. A step-up prompt after a risk event can be appropriate, but decide which event triggers it and how the request will be explained. Map the use case to Realeyes’ journey labels: Onboard, Reverify, Protect or Recover.
| Journey | Decision question | Design focus |
|---|---|---|
| Onboard | Should a new account or participant proceed? | Run before access to sensitive capabilities; define duplicate and incomplete attempts. |
| Reverify | Does this session still involve the expected person? | Use a defined trigger, such as a material risk change, rather than repeated prompts without cause. |
| Protect | Does this sensitive action merit step-up verification? | Match the check to the action’s risk and preserve an approved alternative. |
| Recover | Can recovery proceed with enough confidence? | Presence alone does not establish account ownership; combine it with appropriate account signals. |
For example, a platform may use a liveness check during onboarding before enabling a high-impact feature, while reserving another check for recovery after a device change. Those are different decisions and should have separate triggers, explanations and fallback rules. The API may be shared; the policy around it should not be copied wholesale.
Draw the journey before implementation. Mark where a person enters, what context is already known, where the prompt appears, what happens after each possible outcome and which systems own each transition. Include exits such as cancel, back, timeout and support escalation. This exposes awkward handoffs early: a liveness result may arrive after a session expires, or a recovery flow may lose the account context needed to continue.
Then examine proportionality. Ask what changes if the check is moved earlier or later. An onboarding check before account creation may prevent a weak account from being established, but can interrupt someone before they understand why camera access is requested. A check immediately before a high-impact action has a clearer explanation, but may not address risk created earlier. The decision owner should document the trade-off, not leave it to whichever team builds the screen.
How do you define the API contract?
Document the exchange among client, API and application before building the prompt. Confirm which component initiates a session, how instructions reach the user, how the result returns and how your service binds it to the correct person and transaction. Review the VerifEye platform and API integration information when aligning the flow with product capabilities.
- Request: identify the journey and transaction context without sending unnecessary personal information.
- Capture: explain why camera access is needed and what the person should do. Use the platform’s normal permission controls.
- Result: agree on statuses the application must handle, such as completed, inconclusive, failed or expired where supported by the integration.
- Decision: map each status to a documented action. A technical error is not a negative identity finding.
- Audit: retain only the operational record needed to explain a decision, consistent with retention and privacy policy.
Session binding deserves particular attention. A result should be associated with a single attempt and transaction, not merely a browser session that might be reused. Decide how the server validates the relationship among account, session identifier, request and returned status. Define what happens to stale results and duplicate submissions. These details are easy to overlook in a happy-path demo and expensive to retrofit after launch.
For a concrete contract review, walk through a recovery transaction. The application creates an attempt tied to the account recovery case; the client starts capture for that attempt; the server accepts only the expected response for the active case; and the recovery policy decides whether to proceed, pause or request another approved factor. If the user opens a second tab, submits twice or returns to an expired page, the system should not silently attach an old result to the new attempt.
Keep responsibilities clear across teams. Product owns the user journey and decision intent; engineering owns correct integration and state handling; security reviews abuse paths and controls; privacy and legal teams assess notices, purpose and retention. One owner should maintain the status-to-action map so a policy change does not leave the interface or logs behind.
Make errors actionable without leaking sensitive details. A user-facing message can say the check could not be completed and offer the next approved step. Internal telemetry can distinguish a camera permission denial, network timeout and service error, subject to data minimization. Do not expose implementation details that help an attacker tune attempts, and do not collapse distinct failures into one unhelpful message for operators.
How should prompts, retries and fallbacks work?
An active interaction should be brief, specific and accessible. Tell the person what to do and why the step is present. Avoid wording that makes the camera request feel unexpected. Test the instruction on supported devices, small screens and low-bandwidth connections. A prompt that makes sense to its designers may still be ambiguous in a recovery flow.
Set retry rules deliberately. A retry can help when capture fails temporarily, but unlimited attempts frustrate legitimate users and can create an abuse path. Define the attempt limit, whether a fresh session is required and when the flow changes to another approved route. Keep attempts tied to the same transaction policy while ensuring a new legitimate transaction is not mistakenly blocked by an old expired attempt.
Use distinct messages for distinct conditions. If permission is denied, explain how a user can change the setting or choose the approved alternative. If capture is interrupted, offer a retry where policy allows it. If a service is unavailable, avoid implying the person failed verification. The wording should be consistent with the state machine: promising a retry that the backend rejects is a small interface defect with a large capacity for irritation.
Design the fallback before implementation. Some people cannot use a camera, cannot follow a visual instruction or decline permission. Another verification path or human review may fit the journey. The important distinction is between “the check could not be completed” and “the person failed a security decision.” Do not label an accessibility barrier or device problem as fraud.
Consider cancellation and resumption too. Explain whether the user can resume later, whether progress is retained and what support route is available. In account recovery, restarting the entire process can impose avoidable burden; for a high-risk action, pausing the action pending review may be appropriate. The policy should reflect the decision at stake.
Before release, ask support staff to follow the fallback using the same screens a user sees. Give them a concise explanation of what the result does and does not mean, which information they can see and how to route an unresolved case. This practical rehearsal often reveals a gap between a policy document and an actual support interaction.
What should security and privacy teams review?
Map the data flow before the first production request. Record what is captured, where processing occurs, what the service returns, what the application logs and how long each element persists. VerifEye processes verification on-device and does not store images. The deploying organization still needs to document its own event and context data, access controls and retention rules.
Review transport security, authentication, access control, rate limits, session binding and replay handling. Consider a compromised client as well as a malicious user. A server should not accept an untrusted client’s claim of success without validating the expected transaction and response. Keep sensitive operational details out of routine logs and ensure incident responders can access the records they need.
Presentation attacks and injection attacks are different threat paths. A presentation attack places an artifact, such as a photo or replay, in front of a camera. An injection attack attempts to insert media into the capture pipeline. A liveness check aimed at the first does not automatically address the second; threat modeling and tests should cover both where relevant.
For presentation-attack testing, use APCER and BPCER terminology and ask what attack instruments, capture setup and operating conditions produced a reported result. ISO/IEC 30107-3 sets out requirements for testing and reporting on presentation attack detection; its scope is described on the ISO/IEC 30107-3 standard page. A measure without its test conditions is hard to interpret.
Privacy review should cover purpose limitation, notice, consent where required, retention and regional obligations. Involve counsel early rather than treating legal review as a launch checklist item. The GDPR-compliant liveness overview provides product context, but each organization remains responsible for its deployment choices and obligations.
Make the review concrete by drawing a simple inventory: data element, purpose, system, access group, retention rule and deletion trigger. For instance, an application may need a transaction identifier and outcome for audit, but not a copy of captured media in general-purpose logs. Ask each team to justify every stored field against a defined operational need. If nobody can explain why a field persists, remove it or shorten its retention.
How do you test before launch?
Build the plan around the actual user journey, not just a successful API response. Include representative devices, browsers, lighting and network conditions. Test people who complete the prompt, abandon it or receive an inconclusive result. Where permitted, examine variation across relevant user groups and investigate differences rather than relying on an aggregate result.
- Verify session binding. Confirm that a result cannot attach to the wrong account, transaction or attempt.
- Exercise every outcome. Test completion, failure, timeout, cancellation, duplicate submission and service unavailability.
- Test controls. Check authentication, rate limits, replay resistance, logging and alerting.
- Walk the fallback. Ensure users reach the approved alternative without losing their place or being misclassified.
- Run a limited pilot. Compare the intended decision with downstream outcomes and examine unexpected cases before expanding.
Use a test matrix that separates technical conditions from policy outcomes. Vary device and network conditions while holding the journey constant, then vary the journey while holding the test environment steady. If a result changes, this helps isolate whether the cause is capture quality, client behavior, integration logic or decision policy. Record the expected response before running each case; otherwise a test can pass simply because nobody agreed what it should do.
A practical test case should state its setup, action, expected system response and evidence to retain. For example: “Recovery attempt expires during capture; submit the late response; the server rejects it as stale; the account state remains unchanged; the event is logged without media.” Another case can cover permission denial: the user sees a clear alternative, the account is not marked as a failed identity check and support can identify the route taken. Specific cases turn broad assurances into testable behavior.
Include negative and boundary testing, not only ordinary users on current devices. Test a slow connection, a browser refresh during capture, a repeated callback and a user who switches devices mid-journey. Confirm idempotency where the integration expects it, and confirm that retries do not accidentally create parallel unresolved sessions. Set a clear owner for each defect and retest the whole path after a fix.
Bring the journey diagram, data map, threat model and test results into one deployment review. The security overview and face verification whitepaper can support technical questions. Teams assessing deployment context can also explore human verification solutions and industry use cases.
What should you monitor after launch?
Monitor security and experience together. Separate completed checks from inconclusive results, technical failures and user drop-off. Track invocation volume, retry resolution, fallback completion and time to finish the wider journey. Segment by device and operating conditions where useful, with access and retention controls appropriate to the data.
Assign owners and thresholds before release. A rise in failures might reflect an attack pattern, software change, compatibility issue or network problem. Route those hypotheses to the right teams instead of treating every change as a fraud signal. Review edge cases, record decisions and document why configuration or policy changed.
Choose measures that explain outcomes, not just API volume. If many sessions start but few finish, inspect the prompt, permissions and capture environment. If completion remains steady while fallback use rises, examine whether a new device or browser release changed the experience. If retries cluster around one transition, look for a state-handling defect before changing the risk policy. Pair each metric with an owner and a next diagnostic step.
Use a staged rollout where the use case allows it. Begin with a limited population or low-impact decision, observe how users move through primary and fallback paths, then expand when the integration behaves as intended. Define rollback criteria in advance, including what happens if a dependency is unavailable or an unexpected error rate appears. A pilot without an exit condition is only a launch with better stationery.
Revalidate after a material change to the prompt, client code, API configuration or decision policy. Liveness is one signal in a broader trust flow. Its value depends on where it is used, how its limits are represented and whether the rest of the journey handles uncertainty well.
Frequently Asked Questions
Is active liveness detection the same as identity verification?
No. Active liveness helps assess whether a live person is present during capture. Identity verification may require additional evidence or matching, depending on the use case.
Does an active liveness result prove a user owns an account?
No. Presence does not establish account ownership. Bind the result to an appropriate recovery or authentication process and consider the other signals needed for that decision.
Should every user complete an active prompt?
Not necessarily. Place the check where it can inform a defined risk decision. The right trigger depends on the journey, threat model and user experience requirements.
What should happen when a user cannot complete the check?
Use a planned fallback, such as another approved verification path or review. Do not equate camera access problems or accessibility barriers with malicious behavior.
Verify real humans. Without the friction.
VerifEye confirms users are real and unique in seconds. No documents, no stored data, no drop-off.
A well-integrated liveness check has a defined purpose, a tested fallback and a clear place in the larger trust decision.