Verification Outcome Status Enum
The Verification Outcome Status Enum is the canonical set of status values that HYPR Affirm uses across every observability surface — Activity Log, Audit Trail, Scorecards, Events, and API responses. The same status string means the same thing regardless of which surface you read it from.
The canonical status enum is introduced in HYPR 11.3. Earlier surfaces sometimes displayed N/A or Not Applicable for any state outside the simple verified/failed axis; the 11.3 enum replaces those with explicit semantics. See Observability for background on the migration.
Status values
| Status | Meaning | Required additional fields |
|---|---|---|
VERIFIED | All verification checks passed; the workflow's verified-outcome configuration fires | None |
UNVERIFIED | Verification completed with a fail outcome. The requester completed the flow but did not meet the verification criteria | status_reason (string describing the fail reason) |
ABANDONED | The requester exited the flow before completion (closed the browser, declined consent, navigated away) | status_reason (typically "UserExited" or "ConsentDeclined") |
SKIPPED | A step was intentionally skipped by policy (for example, an escalation policy configured to skip the step under specific conditions) | status_reason (typically "PolicySkipped") |
ERROR | A system or vendor error prevented the verification from completing. Distinct from UNVERIFIED — the requester didn't fail; the system didn't get to evaluate them | system_error_code OR vendor_error_code (one or both populated, depending on origin) |
TIMED_OUT | A vendor- or user-side timeout terminated the flow before completion | status_reason (typically "VendorTimeout", "ApproverTimeout", etc.) |
Retry counters
In addition to the canonical status, every outcome record includes two retry counters:
- Flow-level retry count — how many times the requester restarted the entire flow before this final outcome
- Per-step retry count — for each step, how many attempts that step took before producing its final per-step status
Retry counters are populated on every status record, including VERIFIED outcomes (a VERIFIED outcome with a retry count of 3 indicates the requester succeeded only on the third attempt — useful for UX analysis and fraud detection).
Legacy records
Verification flows that ran before HYPR 11.3 may not have all the fields described above. Surfaces display these legacy records with the phrase "Not Collected (legacy record)" in any unpopulated field, so analysts can distinguish pre-11.3 records from new-format records at a glance and aggregate statistics reflect per-record completeness explicitly.
Reading status across surfaces
The same status appears identically on every observability surface. An UNVERIFIED outcome in the Activity Log appears as UNVERIFIED in the API response, as an AFFIRM_VERIFICATION_UNVERIFIED event, and as a "fail" row in the Approver Scorecard — all keyed to the same Verification Flow ID. Use the Flow ID to correlate the record across surfaces.
Status vs. error code
HYPR Affirm distinguishes between status (the categorical outcome of the verification) and error code (a more granular identifier of the specific error, when applicable). A status of ERROR will always come with at least one populated error code field; the status tells you something went wrong, the error code tells you exactly what.
For the full HYPR error-code catalog, see HYPR Error Codes Troubleshooting Table.
Related
- Observability Concepts — how the status enum ties together with Verification Flow ID, evidence packages, and other observability mechanics
- Activity Log — primary per-requester record view where status is the headline field
- Audit Trail — admin-action events (which use a different categorical scheme)
- HYPR Error Codes — granular error code reference