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

simple

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.

underwriting_fail

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.

email_not_verified

Float-ready user whose Auth0 email is marked unverified.

Same as float_ready ($20 limit) but email_verified = false in Auth0.

Email verification gate, blocked feature screens requiring a verified email.

low_bal_high_past

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

float_ready

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_ready_no_rtp

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_ready_50

Float-eligible user with a $50 limit and CFI history to support it.

Same as float_ready plus 6 historical completed floats and 8 completed subscription records required by CFI.

$50 float amount, limit-tier upgrade display.

float_ready_80

Float-eligible user with an $80 limit and CFI history to support it.

Same as float_ready plus 6 historical completed floats (previous amount $50) and 8 completed subscription records.

$80 float amount, higher-tier limit display.

float_ready_100

Float-eligible user with a $100 limit and CFI history to support it.

Same as float_ready plus 6 historical completed floats (previous amount $80) and 8 completed subscription records.

$100 float amount, higher-tier limit display.

float_ready_200

Float-eligible user with a $200 limit, CFI history, and the $200 float profile setting.

Same as float_ready plus 6 historical completed floats (previous amount $200), 8 completed subscription records, and the id=8 float profile setting appended for $200.

$200 float amount (max tier), limit-tier display.

float_ready_cal

Float-eligible user located in California (state = CA).

Same as float_ready ($20) with user state overridden to CA.

California-specific compliance flows, state-gated feature flags.

float_ready_conn

Float-eligible user located in Connecticut (state = CT).

Same as float_ready ($20) with user state overridden to CT.

Connecticut-specific compliance flows.

float_ready_md

Float-eligible user located in Maryland (state = MD).

Same as float_ready ($20) with user state overridden to MD.

Maryland-specific compliance flows.

float_ready_dc

Float-eligible user located in Washington DC (state = DC).

Same as float_ready ($20) with user state overridden to DC.

DC-specific compliance flows.

float_ready_bypass

User who failed underwriting but has an active requirements bypass record.

Same as underwriting_fail plus a requirements bypass record (expires tomorrow).

Bypass-granted eligibility path, admin bypass workflows, bypass expiry edge cases.

float_payback

Float-eligible user with an outstanding PINLESS float ($20, fee $3) created 3 days ago.

Same as float_ready ($20) plus one historical float record in SCHEDULING status (PINLESS type, amount $20, fee $3, debit/credit date 3 days ago).

Float repayment flows, outstanding balance display, payback collection triggers.

float_payback_standard

Float-eligible user with an outstanding standard (non-PINLESS) float with no fee.

Same as float_payback but float type = NORMAL and fee = 0.

Standard float repayment, no-fee float collection, ACH payback path.

float_ready_array_donald

Premium float-eligible user with $200 limit, identity set to Donald Blair (San Antonio TX).

Same as premium float_ready ($200, KYC enabled) with first name Donald, last name Blair, address 3627 W Poplar St, city San Antonio, state TX, zip 78228.

Array/ARRAY product underwriting, real-identity-based eligibility checks, premium $200 flow.

float_ready_array_thomas

Premium float-eligible user with $200 limit, identity set to Thomas Devos (Tuscaloosa AL).

Same as premium float_ready ($200, KYC enabled) with first name Thomas, last name Devos, address 1206 Bear Creek Rd Apt 110, city Tuscaloosa, state AL, zip 35405.

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

paused_state

Float-eligible user whose membership is paused for 1 month using a GrowthBook-configured pause state.

Same as float_ready ($20) with user state set to a GrowthBook-sourced paused state (default SC), membership paused 1 month, subscription records updated to PAUSED_SKIPPED and a new PAUSED record for the following month.

Membership pause UI, paused user restrictions, resume-membership flows, subscription skipping logic.

premium_paused_state

Premium user whose membership is paused for 1 month (state forced to SC).

Same as premium with user state = SC, then membership paused 1 month and subscription records set to paused.

Premium pause UI, premium-specific pause restrictions.

sub_overdue_15d

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 ACTIVE directly (no insight subscription), 5 subscription records: 4 COMPLETED + 1 ERROR (RETRY process) dated 15 days past due.

Overdue subscription collection, retry flows, 15-day dunning UI states.

sub_overdue_25d

Active user whose most recent subscription payment is 25 days overdue.

Same structure as sub_overdue_15d but overdue date offset = 25 days.

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

loan_ready

Float-eligible user with loans enabled and a passing KYC record.

Same as float_ready ($20) but with is_loan_enabled = true, default loan profile settings, and a synthetic KYC session record (kyc_status = success, watchlist_status = cleared) inserted into the transactions service.

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

kyc_passing

Float-eligible user with identity data matching Plaid’s KYC sandbox passing values (Leslie Knope, Pawnee IN).

Same as float_ready ($20, loansEnabled = true) with first name Leslie, last name Knope, address 123 Main St., city Pawnee, state IN, zip 46001, phone 2345678909.

Plaid identity verification happy path, KYC approval flows, identity-gated features.

premium

Float-eligible user upgraded to the Premium membership tier.

Same as float_ready ($50, KYC enabled) plus membership upgraded to premium via the user service (proration calculated and applied).

Premium feature access, premium UI tier display, upgrade confirmation screen.

premium_pending_downgrade

Premium user who has requested a downgrade to the base tier.

Same as premium plus a downgrade request to base submitted via the user service.

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

plaid_reconnect

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 ResetLogin called to invalidate the access token.

Plaid reconnect prompt, item-error handling, re-link bank account flow.

no_income

User with a Plaid connection that reports no detectable income.

Auth0 account, FloatMe user record, debit card, Plaid connection using the custom_patri2 sandbox user (no income transactions).

Income detection failure, "no income found" eligibility block, underwriting rejection UI.

no_debit_card

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.

banned

User whose account has been banned via the admin ban endpoint.

Auth0 account, FloatMe user record (no debit card), then BanUser called on the user service.

Banned account restrictions, banned-user error screens, admin ban workflow.

recurring_7d

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.

recurring_14d

User with recurring expenses distributed across a 7–13 day window.

Same as recurring_7d but transaction window is 7–13 days ago.

Longer-window recurring expense detection, alternate pay-cycle expense patterns.

multiple_items

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, skipActivation = false), Gingham Plaid connection (same config, skipActivation = true), employment record, requirements bypass.

Multi-bank account flows, primary account selection, item-management UI, institution-change handling.

multiple_debit_cards

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.

reactivate_no_float_no_debit

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.

reactivate_instant_float

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.

reactivate_standard_float

Cancelled user who had an active standard (NORMAL, no-fee) float before cancellation.

Float-payback user with float type = NORMAL and fee = 0, account closed, account cleared, 5-second settle delay.

Reactivation with standard float outstanding, ACH-based float repayment on reactivation.

  • 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