Provider Timeouts, Rejections and Unsupported Routes Need Distinct Handling

An identity verification step can end in three different ways: a timeout or unavailable provider, an explicit rejection, or a request for a route the provider does not support. Treating all three as a generic failure can wrongly block honest users during outages or let outages pass as approvals. The article proposes that the application own a decision table that keeps these outcomes separate, with a distinct next action for each. It also stresses recording HTTP status apart from the decision, so a 503 is never logged as a decline or an approval. Automatic switching to a different provider is not part of the design, and any backup must be explicitly approved for that task and data.