Skip to main content

Flags & Tickets

Our system employs flags to monitor user behaviors, and depending on predefined limits, it either provides additional or limits existing functionalities. Every flag can be linked to a corresponding ticket, facilitating communication between managers and users to address and resolve issues.

Flags​

Currently, raised flags can be on the User or Transaction level. The RaisedFlagType among the others, contains info on level and the flag itself. There are few flag types that usually appears on the end user side:

  • QUESTIONNAIRE_MISSING - user needs to submit questionnaire;
  • EMAIL_NOT_VERIFIED - user needs to verify email;
  • PHONE_NOT_VERIFIED -user needs to verify phone number;
  • KYC_MISSING - user needs to submit KYC;
  • REGISTER_PAYMENT_METHOD - user needs to register payment method.

More details can be found on the FlagType.

You should always show unresolved raised flags on the user level.

Example query:

query raisedFlags($pageRequest: PageRequestRaisedFlagsFilterType) {
  user {
    raisedFlags(pageRequest: $pageRequest) {
      totalCount
      data {
        id
        level
        flag {
          id
          code
          presentedCode
          isWarning
          level
        }
        resolved
        description
      }
    }
  }
}

Example variables:

{
  "pageRequest": {
    "filters": {
      "level": "USER",
      "resolved": false
    }
  }
}

How to resolve specific flag?​

After each step, you should refetch the userQueries.raisedFlags query to update state.

Email / Phone Verification Flag​

This flow ensures that the user's provided contact information is valid and that they have control over the communication channels associated with their account. It enhances security and reduces the risk of fraudulent activities.

A unique verification code will be sent to the user's email or phone. You must provide a way for the user to submit this code to the backend using the userMutations.verify mutation.

Example mutation:

mutation verify($code: String!, $type: String!) {
  userMutations {
    verify(code: $code, type: $type)
  }
}

Example variables:

{
  "code": "123456",
  "type": "PHONE"
}

If the user has not received the verification code, you can allow them to request a new one by calling the userMutations.resendVerificationCode mutation. This mutation returns a Boolean value indicating whether the operation was successful.

Example mutation:

mutation resendVerificationCode($type: String!) {
  userMutations {
    resendVerificationCode(type: $type)
  }
}

Example variables:

{
  "type": "EMAIL"
}

Questionnaire Flag​

To resolve the questionnaire flag, you must first use the public.fieldsConfig query to retrieve the list of fields that the user needs to complete. This process is similar to the registration flow, though the parameters differ in this case.

# use isoCode2 for countryCode, and `Questionnaire` for fieldsGroup
query publicFieldsConfig($countryCode: String, $fieldsGroup: String!) {
  public {
    id
    fieldsConfig(countryCode: $countryCode, fieldsGroup: $fieldsGroup) {
      country
      fields {
        description
        editable
        label
        max
        maxLength
        min
        minLength
        name
        orderNumber
        pattern
        required
        section
        type
        value
        values {
          label
          value
        }
        visible
        properties {
          type
          value
        }
      }
    }
  }
}

Example variables:

{
  "countryCode": "US",
  "fieldsGroup": "Questionnaire"
}

After that, you will need to display a form to the end user. Once the user fills in the required fields, you can invoke the addProperties mutation with the following parameters as an example:

Mutation

mutation addProperties(
  $properties: [CustomPropertyInputType]
  $flagCode: FlagCode
) {
  user {
    addProperties(properties: $properties, flagCode: $flagCode) {
      id
      key
      tag
      value
    }
  }
}

Example variables:

{
  "properties": [
    {
      "key": "income",
      "value": "Contractor",
      "tag": "QUESTIONNAIRE"
    },
    {
      "key": "reason",
      "value": "Sending funds to self",
      "tag": "QUESTIONNAIRE"
    },
    {
      "key": "destinationCountries",
      "value": "Burkina Faso,Burundi,Benin",
      "tag": "QUESTIONNAIRE"
    },
    {
      "key": "minValue",
      "value": "500",
      "tag": "QUESTIONNAIRE"
    },
    {
      "key": "maxValue",
      "value": "1000",
      "tag": "QUESTIONNAIRE"
    },
    {
      "key": "minTimes",
      "value": "5",
      "tag": "QUESTIONNAIRE"
    },
    {
      "key": "maxTimes",
      "value": "7",
      "tag": "QUESTIONNAIRE"
    }
  ],
  "flagCode": "QUESTIONNAIRE_MISSING"
}

This mutation will automatically resolve the questionnaire flag, provided that all required data has been submitted correctly.

KYC Flag​

For more information, see the details in the KYC Verification section.

Register Payment Method Flag​

This flag indicates that the user must set up a payment method. The exact implementation depends on the specific inbound service and must be handled accordingly for each case. For detailed guidance on handling this flag and configuring inbounds, see the Inbounds section.

Tickets​

If a manager decides that the user needs to provide additional details related to the raised flag (e.g. a user was unable to pass KYC), a manager can create a ticket based on that raised flag.

It will allow a manager to communicate with a user via messages. Messages may include text or files that require action from the manager.