Identity Verification Failed? How Businesses Should Respond

When identity verification fails, the failure needs a diagnosis before it needs another attempt. A service error may prevent the check from completing at all. A completed but unsuccessful check means the required verification conditions were not met. Neither result, by itself, establishes that the customer attempted fraud.

An unreadable image, unsupported document, unresolved match, and suspected manipulation should not all send a customer into the same retry loop.

For a business, the useful response is a clear explanation where safe, a limited corrective action, and an approved path for cases that remain unresolved.

Expand

Separate service errors from verification outcomes

A timeout, unavailable service, or invalid integration request is a technical problem. A completed verification that does not satisfy the configured checks is a different outcome. Your application should distinguish both from an incomplete session or a case awaiting review.

A successful API request does not necessarily mean the person is verified. Conversely, an unsuccessful request does not mean their identity was rejected. If a response is lost, confirm the authoritative session state before treating the attempt as failed or asking the customer to start again.

For a Stile integration, the error-handling documentation covers request errors and which ones are safe to retry. Verification outcomes arrive separately. A failed session can carry a public failure reason with a code for your application, an applicant-facing message, and a category that separates verification_declined from technical_error. Treat that reason as optional, and use the session status as the authoritative outcome. Keep technical retry decisions with the integration owner rather than asking support staff or customers to guess.

Start with the stage that failed

Support teams need enough context to distinguish a capture problem from a verification decision. Customers need a next step they can understand. Neither needs unrestricted access to sensitive evidence or internal fraud thresholds.

Use these categories as a starting point, then adapt them to the methods and error categories your provider actually returns:

• Image quality. Tell the customer: the specific capture adjustment. Operating action: permit a bounded retry, and escalate if the problem persists.
• Unsupported credential. Tell the customer: an accepted alternative. Operating action: route to another supported method.
• Information mismatch. Tell the customer: which user-correctable detail needs checking, where safe. Operating action: distinguish entry mistakes from evidence requiring review.
• Unresolved face or presence check. Tell the customer: an approved retry or assistance route. Operating action: apply the review policy without declaring fraud prematurely.
• Service unavailable. Tell the customer: the check could not complete. Operating action: use the outage procedure, and do not imply an identity failure.
• Suspected manipulation. Tell the customer: an appropriate review message. Operating action: restrict sensitive details and escalate under the fraud policy.

Make retries address an actual problem

If glare obscures a document, ask the user to change the lighting or angle. If the document is unsupported, another photo of the same document will not fix the problem. If the service is unavailable, repeated uploads may add frustration without adding evidence.

Each retry should have a reason and a stopping point. Define the limit according to your risk and provider requirements, and explain the alternative when the limit is reached. Avoid making a legitimate customer search the public internet for a workaround.

Give recovery an owner and a stopping point

For each category, name the team that owns the next action. Support may help with capture instructions, an integration owner may investigate service errors, and an authorized reviewer may resolve uncertain evidence. These are roles to assign in your operating policy, not assumed features of a verification product.

Define when retries stop: the allowed attempts are exhausted, the same unsupported credential is being resubmitted, the service remains unavailable, or the case meets your review criteria. At that point, move to the approved alternative or review path instead of restarting the same loop.

Also decide what happens to the underlying request while the case is unresolved. Tell the customer whether it is paused and how they can receive an update. An overdue review should escalate to its owner; elapsed time alone should not turn it into an approval. In a Stile integration, the manual-review guidance follows the same rule: hold the transaction when a session is flagged for review, release it only when the session is verified, and treat a review that times out as a rejection.

Provide review without creating a bypass

NIST's identity-proofing guidance, SP 800-63A-4, requires redress mechanisms for applicant complaints and problems, including proofing failures, delays, and difficulties, and says they should be easy for applicants to find and use. It also describes exception handling through trained trusted referees for applicants who cannot meet the standard process. That is a useful design reference for businesses planning support, even where the NIST framework is not a direct requirement.

An alternative route still needs appropriate evidence. A sympathetic support conversation should not automatically override the control that protected the account or transaction; support-desk persuasion is a common route into account takeover.

Decide who may approve an exception, what they must establish, and how the decision is recorded. Keep the customer inside a verified support channel. Requests to send a passport and selfie to an employee's personal inbox should not become the default recovery method.

Treat accessibility as part of the workflow

Test your flow with people using older devices, assistive technology, and different capture environments. Ask whether a person who cannot complete a required movement can reach support without repeating that same step.

A useful alternative is specific: a supported credential, an attended review, or another approved process that meets the necessary assurance. "Contact us" is less useful when the contact form requires the same verification that just failed.

Measure the whole path to a decision

A pass rate alone is difficult to interpret. It may change because the user population changed, a new credential was introduced, or a capture update made the flow harder to complete.

Track completion by method and device, retries by failure category, review turnaround, and how often an approved alternative resolves the case. Where you can establish reliable outcomes, compare missed fraud with legitimate users who were wrongly declined, your false rejection rate. Keep the definitions stable enough that your team can tell a product change from a reporting change.

For support quality, sample cases and ask a simple question: did the customer receive a next step that addressed the actual problem?

Keep the explanation useful and the record proportionate

Record the stage, result category, transaction reference, retry history, and decision ownership needed for your process. Determine separately which underlying evidence must be retained and who may access it.

If you use Stile, review the current data-retention documentation when designing support access and records. Avoid promising immediate deletion of every field or assuming a review-held session follows the same lifecycle as a resolved one: a session under review keeps the evidence its reviewer needs until the decision. For the related image-security discussion, see how Stile protects identity images.

Build the response alongside the check

When evaluating identity verification software, walk through failure cases before launch. Show the support team the messages customers receive, test the escalation route, and confirm what the business should do while verification remains unresolved.

Use this launch checklist with product, support, and risk owners:

• Separate technical errors, incomplete sessions, review states, and completed verification outcomes in reporting and customer messages.
• Give each customer-correctable problem a specific instruction and an appropriate retry limit.
• Assign an owner and escalation route for cases the customer cannot resolve.
• Test the stopping point and the approved alternative without bypassing required evidence.
• Decide whether the underlying transaction waits, is declined, or follows another authorized path while verification is unresolved.
• Limit evidence access and confirm how each record is retained or deleted.
• Review sample cases to check that the next step actually addressed the cause.

A good recovery path helps legitimate users complete the process while preserving the evidence needed for a sound decision. It deserves the same attention as the successful flow. New to the topic? Start with what identity verification is and when you need it.

The failure categories and measurement suggestions are editorial recommendations, not Stile error-code documentation or a claim of certification.