> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluz.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing KYC Flows

Fluz requires users to be KYC verified before they can perform certain transactions or unlock higher limits. In the **staging** environment you can run the entire verification flow against known test identities and confirm that your integration handles every outcome — without using a real person's information.

For the full mutation contract and response reference, see [User KYC Verification](/user-kyc-verification).

<Note>
  **Staging only**

  The identities on this page exist only on the staging endpoint (`https://transactional-graph.staging.fluzapp.com/api/v1/graphql`). They are synthetic and will not verify in production. Never submit a real person's name, address, date of birth, or SSN to staging.
</Note>

<Info>
  **Before you start, you'll need:** a Fluz account with **developer access** and an active application ([Prepare Your Accounts](/get-started/prepare-accounts)), and a **user access token** for the user you're verifying ([Generate a User Access Token](/recipes/generate-user-access-token)). The token identifies which staging user the verification applies to.
</Info>

## Step 1 — Create a test user (optional)

If you don't already have a staging user to verify, create one with the [`registerUser`](/user-registration) mutation, then generate a user access token for it.

<Note>
  **Restricted access**

  `registerUser` requires special permission from Fluz. If your application can't register users, use an existing staging user instead. Contact your account manager or [partnerships@fluz.app](mailto:partnerships@fluz.app) to enable it.
</Note>

## Step 2 — Use the approved test identity

The identity below is configured to return an **APPROVED** result on staging. Submit it exactly as shown.

| Field             | Value                  |
| ----------------- | ---------------------- |
| First name        | John                   |
| Last name         | Smith                  |
| Street address    | 222333 Peachtree Place |
| City              | Atlanta                |
| State             | GA                     |
| ZIP / postal code | 30318                  |
| Date of birth     | 02/28/1975             |
| SSN               | 112-22-3333            |

<Note>
  The API only consumes the **last 4 digits** of the SSN (`ssnLast4`). For this identity that's `3333`. Date of birth is formatted as `MM/DD/YYYY`.
</Note>

## Step 3 — Run the verification

Call `verifyUserInformation` with the approved identity. Replace `<USER_ACCESS_TOKEN>` with the token for the user being verified.

<CodeGroup>
  ```curl cURL theme={null}
  curl -X POST https://transactional-graph.staging.fluzapp.com/api/v1/graphql \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer <USER_ACCESS_TOKEN>" \
    -d '{
      "query": "mutation VerifyUserInformation { verifyUserInformation(input: { firstName: \"John\", lastName: \"Smith\", streetLine1: \"222333 Peachtree Place\", streetLine2: \"\", city: \"Atlanta\", state: \"GA\", postalCode: \"30318\", country: \"United States\", dateOfBirth: \"02/28/1975\", ssnLast4: \"3333\" }) { status message } }"
    }'
  ```

  ```javascript JavaScript theme={null}
  const response = await fetch(
    "https://transactional-graph.staging.fluzapp.com/api/v1/graphql",
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: `Bearer ${accessToken}`,
      },
      body: JSON.stringify({
        query: `
          mutation VerifyUserInformation($input: VerifyUserInformationInput!) {
            verifyUserInformation(input: $input) {
              status
              message
            }
          }
        `,
        variables: {
          input: {
            firstName: "John",
            lastName: "Smith",
            streetLine1: "222333 Peachtree Place",
            streetLine2: "",
            city: "Atlanta",
            state: "GA",
            postalCode: "30318",
            country: "United States",
            dateOfBirth: "02/28/1975",
            ssnLast4: "3333",
          },
        },
      }),
    }
  );

  const data = await response.json();
  console.log(data.data.verifyUserInformation);
  ```
</CodeGroup>

```json Approved response theme={null}
{
  "status": "APPROVED",
  "message": "User verification successful"
}
```

## Step 4 — Simulate the other outcomes

Use the same mutation to exercise your handling of every verification status.

| Status    | How to trigger it on staging                                                                       |
| --------- | -------------------------------------------------------------------------------------------------- |
| APPROVED  | Submit the approved test identity above.                                                           |
| DECLINED  | Submit an identity that does not match a known-good staging record. Test values: `[TBD: confirm]`. |
| DUPLICATE | Re-submit identity data that matches an already-verified staging user.                             |
| ERROR     | Submit a 4th verification attempt for the same user — verification is capped at 3 tries.           |

<Warning>
  The exact field values that force a `DECLINED` result on staging aren't published yet. Confirm them with the platform team before relying on them in an automated test suite.
</Warning>

## Verification responses

| Status    | Message                          | Description                                         |
| --------- | -------------------------------- | --------------------------------------------------- |
| APPROVED  | User verification successful     | User is KYC verified                                |
| DECLINED  | Verification declined            | User is not KYC verified                            |
| DUPLICATE | Duplicate user verification      | User is KYC verified but data matches another user  |
| ERROR     | Exceeded user verification limit | Verification attempts exceed the maximum of 3 tries |

## Notes

* **Three-attempt limit.** A user can be submitted for verification at most 3 times before returning `ERROR`. Plan your tests so you don't exhaust attempts on a user you still need.
* **Tokens are per user.** The access token determines which user is verified — make sure it belongs to the test user whose identity you're submitting.

## Next steps

<CardGroup cols={2}>
  <Card title="Test merchants" icon="store" href="/test-merchants">
    Staging merchants with predictable offers for exercising gift card purchases.
  </Card>

  <Card title="User KYC verification" icon="id-card" href="/user-kyc-verification">
    The full mutation contract — documentary verification links, statuses, and responses.
  </Card>
</CardGroup>