Terms are listed in the order you encounter them as you set up an account and run a verification. ## Applicant The person being verified. An applicant completes the verification flow on their device: they capture documents, take a selfie or liveness scan where required, and provide any information the workflow template asks for. The console list of people you have verified is **Applicants**. ## Organization The tenant boundary on the platform. Every member, API key, workflow template, applicant verification, webhook endpoint, and wallet entry belongs to one organization. You can be a member of multiple organizations under one sign-in. The internal identifier is `org_id`. ## Mode (test, live) Each organization runs in two parallel modes: - **Test mode** uses test-mode API keys (`ah_sk__test_…`) and test-mode webhook endpoints. It is free and fully synthetic: it runs no real checks, debits no wallet, and runs no fraud detection. Results are generated, not collected: you choose the outcome per verification with the [Expected outcome](/guides/verification/create-a-verification#expected-outcome-test-mode) control (`pass`, `review`, or `fail`). No real applicants and no real money. - **Live mode** runs real checks and bills real funds from your wallet. Resources created in one mode are invisible to the other. A test-mode verification does not appear in live-mode reports and vice versa. ## Region (us, eu) The physical jurisdiction your data lives in. The platform runs two independent regions: US region and EU region. You pick a region at organization creation and the choice is sticky. Data does not cross regions. See [Where is my data hosted?](/guides/faq/data-residency). ## Workflow template A reusable configuration that defines which checks run on a verification and in what order. Workflow templates also carry branding and applicant-flow copy. You start a verification from a workflow template. The console sidebar label is **Workflows**. ## Verification (applicant verification) One run of a workflow template against one applicant. (The REST API object is named `Session`.) A verification has a status (`created`, `pending`, `in_progress`, `awaiting_gate`, `processing`, `payment_required`, `awaiting_review`, `completed`, `expired`, `cancelled`) and a verdict (`approved`, `declined`, `review`) once it reaches a terminal state. The `awaiting_gate` state holds the applicant in the flow while a server-side check (for example a watchlist gate) settles before the flow continues. ## Check A single verification step inside a verification. The canonical check types are `collect_user_info`, `id_verification`, `watchlist`, `background_us_criminal`, and `background_global`. A verification runs many checks; the overall verdict is derived from each check's outcome. ## Finding A reviewable observation produced by a verification: a watchlist match, a document concern, or a fired fraud rule. Findings carry the evidence a reviewer reads before making a decision. A fraud finding that is not tied to one specific check appears under a **Session-level** group in the reviewer's findings list. ## Fraud signals An opt-in workflow layer that watches for suspicious applicant patterns — IP reputation, automation, device velocity, repeat applicants, impossible travel, identity rings, email risk, behavior anomalies, and geo mismatch — and turns what it sees into findings. Fraud rules can flag, send to review, or adjust the fraud score, but never decline an applicant on their own. Configured in the workflow editor's **Fraud signals** section. See [Add fraud signals to a workflow](/guides/workflows/workflow-templates-fraud-rules). ## Identity verification (id_verification) The applicant-rendered check that captures a government-issued identity document with the device camera and, optionally, a biometric face check. You choose which document types the workflow template accepts and whether to add a face match. The document is read and screened for authenticity, and the verdict resolves asynchronously once capture is complete. See [Choose the right check types](/guides/workflows/workflow-templates-check-types#identity-document-verification). ## Biometric mode The `biometricMode` setting on the `id_verification` check, with three mutually exclusive values: `none` (document only — the default), `selfie` (a single selfie matched to the document photo), and `liveness` (an active face scan, then a match to the document photo). The biometric check is strictly opt-in. In the workflow template editor it is the **Face match** control. ## Liveness A biometric mode that runs a short, guided face scan to confirm a real, present person is in front of the camera before matching that face to the document photo. The challenge is movement-based with no flashing lights, so it carries no photosensitivity warning. It offers higher assurance against photo or screen spoofing than a plain selfie. ## Verdict The verification's overall outcome at the terminal `completed` state: `approved`, `declined`, or `review`. `review` means the platform cannot auto-decide; a human reviewer makes the call. See [Why was a verification declined?](/guides/faq/verification-declined). ## Invite link The single-use link in each applicant's invite, of the form `/v/?o=`. The token is consumed when the applicant clicks **Start verification** on the landing page, not when an email scanner pre-fetches the URL. This means corporate mail gateways and antivirus link-checkers do not burn the link. Invite links have a 24-hour TTL by default. If a link expires, you can issue a fresh one from the applicant detail screen. ## Wallet The organization's single balance, in US dollars. One wallet per organization; subscription grants, top-up funds, trial credit, and goodwill all share the wallet. Inside it, funds sit in two buckets (grant and top-up) with different expiry. Debits drain trial funds first, then the grant bucket, then the oldest top-up funds. See [Wallet and balance](/guides/billing/wallet). ## Grant Bucket / Top-Up Bucket The two logical buckets inside the single wallet. The **Grant Bucket** holds subscription grants and is use-it-or-lose-it (a monthly grant expires at cycle end; an annual grant expires 365 days out). The **Top-Up Bucket** holds prepaid funds (top-ups, auto-recharge, wire, goodwill) and rolls over, expiring 365 days after each deposit. The total balance is the sum of both. ## Check price The dollar amount a verification check consumes. Each check type has a price set by the platform's pricing table (for example, identity verification $0.75, address verification $0.50). Cash-backed funds become breakage revenue if they expire unspent. ## Subscription tier (Basic, Pro, Max) A tier funds a monthly (or annual) grant into your wallet's Grant Bucket and unlocks premium features. It is a **feature gate, not an access gate** — you can run verifications whenever your wallet has a positive balance, including with prepaid funds and no subscription at all. The three tiers differ in price and grant amount. See [Subscription](/guides/billing/subscription). ## Checkout discount The value lever on a preset [top-up](/guides/billing/top-up): you pay less than the face value and your wallet is credited the full face (for example, $250 of wallet for a $200 charge). Custom top-up amounts and auto-recharge fund 1:1 with no discount; subscription grants land at face. There is no "bonus" or volume-ladder model. ## Top-up A one-time purchase that adds dollars to your wallet's Top-Up Bucket. The amount is your choice (presets with a checkout discount, plus custom amounts at 1:1). See [Top up](/guides/billing/top-up). ## Auto-recharge An off-session top-up that fires when the wallet balance dips below a customer-set threshold (default $10). It funds the wallet 1:1 at the base rate — the preset checkout discounts are a manual-top-up lever only. See [Auto-recharge](/guides/billing/auto-recharge). ## Freeze-on-cancel The one place a subscription's state blocks spending: if you subscribe and then cancel (or lapse past the dunning grace), your remaining balance is **frozen** — preserved, never forfeited, and not spendable until you re-subscribe. A never-subscribed, top-up-funded wallet is never frozen. See [Subscription](/guides/billing/subscription). ## Parked verification A verification that ran out of spendable funds mid-flight and is paused waiting for funds. The platform debits dollars before each check runs, so on insufficient balance the check is never invoked (no cost, no arrears). The verification sits in the `payment_required` state until funds land (or a frozen wallet is unfrozen), then resumes automatically without re-running completed steps and without double-charging. ## `payment_required` The HTTP `402` returned by the API when the wallet can't cover the operation — insufficient balance, or a `locked`/`closed` wallet (for example, frozen by a card dispute). Also the non-terminal state for a [parked verification](#parked-verification). The fix is to add funds (or contact support for a locked wallet); see [Why is my account in payment_required?](/guides/faq/payment-required). ## `subscription_required` The HTTP `403` returned by the API when your wallet holds a balance that is **frozen** after a subscription cancellation (or a `past_due` lapse past the dunning grace). The funds are preserved; re-subscribe to unfreeze them. (The same code is reserved for premium-feature gating.) See [Subscription](/guides/billing/subscription).