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 onlyThe 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 (Prepare Your Accounts), and a user access token for the user you’re verifying (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 accessregisterUser 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 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.

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

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

Approved response

{
  "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.

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

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

Test merchants

Staging merchants with predictable offers for exercising gift card purchases.

User KYC verification

The full mutation contract — documentary verification links, statuses, and responses.

Get started

Fluz Dashboard

Quickstarts

Testing KYC Flows

Step 1 — Create a test user (optional)

Step 2 — Use the approved test identity

Step 3 — Run the verification

Step 4 — Simulate the other outcomes

Verification responses

Notes

Next steps

Test merchants

User KYC verification

​Step 1 — Create a test user (optional)

​Step 2 — Use the approved test identity

​Step 3 — Run the verification

​Step 4 — Simulate the other outcomes

​Verification responses

​Notes

​Next steps

Test merchants

User KYC verification

Step 1 — Create a test user (optional)

Step 2 — Use the approved test identity

Step 3 — Run the verification

Step 4 — Simulate the other outcomes

Verification responses

Notes

Next steps