Predefined User States
This page enumerates every predefined state accepted by POST /qa/integration/user.
Each state provisions a complete user in a specific condition so integration tests can start from a known, repeatable baseline without needing to drive through the full onboarding UI.
See Integration Users for request/response shape, authentication requirements, and a worked example.
The authoritative list of valid state names is the state enum in spec/qa_api.yaml.
Re-check this page after schema changes.
|
Base States
These states create a user at an early stage of the FloatMe lifecycle — before or at the point where a float could be taken.
| State | Summary | Provisions | Test Scenarios |
|---|---|---|---|
|
Minimal registered user with a debit card but no bank connection or employment. |
Auth0 account, FloatMe user record, debit card (optional via code path). |
Onboarding flows, registration validation, pre-bank-link screens. |
|
User with a Plaid connection that has a zero balance, causing underwriting rulebooks to fail. |
Auth0 account, FloatMe user record, debit card, custom Plaid connection (balance = 0, recurring transactions 7–13 days), employment record. |
Underwriting rejection flows, "not eligible" UI states, retry prompts. |
|
Float-ready user whose Auth0 email is marked unverified. |
Same as |
Email verification gate, blocked feature screens requiring a verified email. |
|
Simple user with a $0 current balance but 7 days of $1,000 historical balances and a scheduled subscription. |
Auth0 account, FloatMe user record, scheduled subscription record (yesterday’s billing period), Huntington Plaid account (balance 0, past balances $1,000 × 7 days). |
Balance-check edge cases, past-balance-weighted eligibility logic, subscription scheduling with low current balance. |
Float States
These states produce a user who is eligible to take a float, or who is already in a specific float lifecycle stage.
| State | Summary | Provisions | Test Scenarios |
|---|---|---|---|
|
Standard float-eligible user with a $20 limit and CFI enabled. |
Auth0 account, FloatMe user record, debit card, float profile ($20, CFI + CFI-flow enabled), Plaid connection (valid income), employment record. |
Float request happy path, CFI new-experience UI, $20 float amount. |
|
Float-eligible user connected to a Discover account that does not support RTP. |
Auth0 account, FloatMe user record, debit card, float profile ($20, CFI enabled), Discover Plaid connection (recurring transactions 7–13 days), employment record. |
Non-RTP disbursement paths, ACH-only float delivery, institution capability screens. |
|
Float-eligible user with a $50 limit and CFI history to support it. |
Same as |
$50 float amount, limit-tier upgrade display. |
|
Float-eligible user with an $80 limit and CFI history to support it. |
Same as |
$80 float amount, higher-tier limit display. |
|
Float-eligible user with a $100 limit and CFI history to support it. |
Same as |
$100 float amount, higher-tier limit display. |
|
Float-eligible user with a $200 limit, CFI history, and the $200 float profile setting. |
Same as |
$200 float amount (max tier), limit-tier display. |
|
Float-eligible user located in California (state = CA). |
Same as |
California-specific compliance flows, state-gated feature flags. |
|
Float-eligible user located in Connecticut (state = CT). |
Same as |
Connecticut-specific compliance flows. |
|
Float-eligible user located in Maryland (state = MD). |
Same as |
Maryland-specific compliance flows. |
|
Float-eligible user located in Washington DC (state = DC). |
Same as |
DC-specific compliance flows. |
|
User who failed underwriting but has an active requirements bypass record. |
Same as |
Bypass-granted eligibility path, admin bypass workflows, bypass expiry edge cases. |
|
Float-eligible user with an outstanding PINLESS float ($20, fee $3) created 3 days ago. |
Same as |
Float repayment flows, outstanding balance display, payback collection triggers. |
|
Float-eligible user with an outstanding standard (non-PINLESS) float with no fee. |
Same as |
Standard float repayment, no-fee float collection, ACH payback path. |
|
Premium float-eligible user with $200 limit, identity set to Donald Blair (San Antonio TX). |
Same as premium |
Array/ARRAY product underwriting, real-identity-based eligibility checks, premium $200 flow. |
|
Premium float-eligible user with $200 limit, identity set to Thomas Devos (Tuscaloosa AL). |
Same as premium |
Array/ARRAY product underwriting, real-identity-based eligibility checks, premium $200 flow. |
Subscription States
These states configure a user with specific subscription history or status to support subscription lifecycle testing.
| State | Summary | Provisions | Test Scenarios |
|---|---|---|---|
|
Float-eligible user whose membership is paused for 1 month using a GrowthBook-configured pause state. |
Same as |
Membership pause UI, paused user restrictions, resume-membership flows, subscription skipping logic. |
|
Premium user whose membership is paused for 1 month (state forced to SC). |
Same as |
Premium pause UI, premium-specific pause restrictions. |
|
Active user whose most recent subscription payment is 15 days overdue. |
Auth0 account, FloatMe user record, debit card, float profile ($20), Plaid connection (valid income), user status set to |
Overdue subscription collection, retry flows, 15-day dunning UI states. |
|
Active user whose most recent subscription payment is 25 days overdue. |
Same structure as |
25-day dunning UI, escalated collection flows, potential suspension triggers. |
The sub_overdue family supports arbitrary day values matching the pattern sub_overdue_<N>d (e.g. sub_overdue_30d).
Only sub_overdue_15d and sub_overdue_25d appear in the spec enum; other values may work at the API level but are not guaranteed stable.
|
LOC / Loan States
These states provision a user who is eligible for a Line of Credit (LOC) loan product.
| State | Summary | Provisions | Test Scenarios |
|---|---|---|---|
|
Float-eligible user with loans enabled and a passing KYC record. |
Same as |
LOC product eligibility display, loan application happy path, KYC-gated loan flows. |
KYC / Premium States
These states configure users with KYC-passing identities or premium membership tiers.
| State | Summary | Provisions | Test Scenarios |
|---|---|---|---|
|
Float-eligible user with identity data matching Plaid’s KYC sandbox passing values (Leslie Knope, Pawnee IN). |
Same as |
Plaid identity verification happy path, KYC approval flows, identity-gated features. |
|
Float-eligible user upgraded to the Premium membership tier. |
Same as |
Premium feature access, premium UI tier display, upgrade confirmation screen. |
|
Premium user who has requested a downgrade to the base tier. |
Same as |
Pending downgrade UI, feature access during downgrade window, downgrade confirmation. |
Failure / Edge Case States
These states simulate broken connections, missing data, or administratively restricted accounts.
| State | Summary | Provisions | Test Scenarios |
|---|---|---|---|
|
User whose Plaid login has been forcibly invalidated to simulate a disconnected bank. |
Auth0 account, FloatMe user record, debit card, Plaid connection (valid income), employment record, then Plaid |
Plaid reconnect prompt, item-error handling, re-link bank account flow. |
|
User with a Plaid connection that reports no detectable income. |
Auth0 account, FloatMe user record, debit card, Plaid connection using the |
Income detection failure, "no income found" eligibility block, underwriting rejection UI. |
|
User with a valid Plaid connection and employment but no debit card on file. |
Auth0 account, FloatMe user record (no debit card), Plaid connection (valid income), employment record. |
Missing payment method UI, add-debit-card prompt, debit card required gate. |
|
User whose account has been banned via the admin ban endpoint. |
Auth0 account, FloatMe user record (no debit card), then |
Banned account restrictions, banned-user error screens, admin ban workflow. |
|
User with recurring expenses (income, rent, bills, streaming, restaurants, groceries) distributed across a 1–6 day window. |
Auth0 account, FloatMe user record, debit card, custom Huntington Plaid connection (balance $500, recurring transaction set spanning 1–6 days ago), employment record, requirements bypass. |
Recurring expense detection, insight service categorization, expense-based eligibility rules. |
|
User with recurring expenses distributed across a 7–13 day window. |
Same as |
Longer-window recurring expense detection, alternate pay-cycle expense patterns. |
|
User with two linked Plaid items from different institutions (Huntington + Gingham). |
Auth0 account, FloatMe user record, debit card (×2 — one per item flow), Huntington Plaid connection (balance $500, 1–13 day transactions, |
Multi-bank account flows, primary account selection, item-management UI, institution-change handling. |
|
User with two debit cards on file and a single Plaid connection. |
Auth0 account, FloatMe user record, debit card (×3 total — one from simple creation + two additional), Huntington Plaid connection (balance $500, 7–13 day transactions), employment record, requirements bypass. |
Multiple payment method UI, primary card selection, debit card management screens. |
|
Cancelled user with no float and no debit card, ready to go through reactivation. |
Auth0 account, FloatMe user record (no debit card), account closed via user service, account cleared (allows re-registration), 5-second settle delay. |
Reactivation flow (no prior float), returning-user onboarding, cleared account re-signup. |
|
Cancelled user who had an active PINLESS float before cancellation. |
Float-payback user (float_ready $20 + outstanding PINLESS float), account closed, account cleared, 5-second settle delay. |
Reactivation with outstanding float, instant-float reactivation path, returning user with debt. |
|
Cancelled user who had an active standard (NORMAL, no-fee) float before cancellation. |
Float-payback user with float type = |
Reactivation with standard float outstanding, ACH-based float repayment on reactivation. |
Related Pages
-
Integration Users — endpoint reference, request/response schema, and usage patterns for
POST /qa/integration/user -
API Endpoints — full list of QA API endpoints and their parameters