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.

📘

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.

Before you start

You'll need:

• A Fluz account with developer access and an active application — see Prepare Your Accounts.
• A user access token for the user you're verifying — see Generate a User Access Token. The token identifies which staging user the verification applies to.

Step 1 — Create a test user (optional)

If you don't already have a staging user to verify, create one with the registerUser mutation, then generate a user access token for it.

📘

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 [email protected] to enable it.

Step 2 — Use the approved test identity

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

📘

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.

Step 3 — Run the verification

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

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 } }"
  }'

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);

{
  "status": "APPROVED",
  "message": "User verification successful"
}

Step 4 — Simulate the other outcomes

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

🚧

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.

Verification responses

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.

Related pages

• User KYC Verification — full mutation contract and response reference.
• User Registration — create a test user to verify.
• Generate a User Access Token — required before calling the mutation.

Want to learn more? Contact us at [email protected]. Speak with our experts for more info or to request a demo.