Paytrie Developer Documentation

KYC and Profile Data Requirements

Read what a user still needs to provide, and submit it

View as Markdown

A user must complete their profile before they can start identity verification or transact. Rather than tracking that yourself, ask Paytrie: GET /v2/users/{userId}/requirements returns every requirement with its status, and names the exact fields anything outstanding is waiting on. You submit those fields with PATCH /v2/users/{userId} and read the requirements again.

Use this page as a planning reference for what the requirements mean. The live response is what counts — which requirements apply varies by user, and the set changes as compliance rules change. Render whatever the API returns rather than hardcoding a list of steps.

Before you start

These endpoints act on a specific user, so they need both credentials:

  • Your API key, sent as x-api-key.
  • An access token for that user, sent as Authorization: Bearer.

Create the user first with POST /v2/users, then obtain an access token for them through Authentication — send a login code to their email, and exchange the code they give you for a token. Tokens are valid for one hour.

Calling these endpoints with only an API key returns 401 Authorization header missing or invalid.

Read a user's requirements

curl -X GET "https://api.paytrie.com/v2/users/550e8400-e29b-41d4-a716-446655440000/requirements" \
  -H "x-api-key: your-api-key" \
  -H "Authorization: Bearer <access-token>"
{
  "success": true,
  "data": {
    "requirements": {
      "emailVerification": { "status": "satisfied", "requiredFields": [] },
      "personalInfo": { "status": "satisfied", "requiredFields": [] },
      "address": { "status": "satisfied", "requiredFields": [] },
      "occupation": { "status": "satisfied", "requiredFields": [] },
      "additionalInfo": {
        "status": "pending",
        "requiredFields": [
          "olderUserInfo.sourceOfFunds",
          "olderUserInfo.intendedUseOfUSDC",
          "olderUserInfo.walletProvider",
          "olderUserInfo.walletAddress",
          "olderUserInfo.howDidYouHear",
          "olderUserInfo.whoReferredYou",
          "olderUserInfo.previousCryptoExperience"
        ]
      },
      "kyc": { "status": "pending", "requiredFields": [] }
    }
  }
}

API Reference: Get a user's requirements

View complete request parameters and response schema

Status

ValueMeaning
pendingThe user still has to act. Where the requirement is field-driven, requiredFields names what to submit.
processingPaytrie is reviewing what was submitted. No action is needed from you or the user.
satisfiedNothing further is needed.

Reason

Some requirements carry a reason when the status alone does not say enough.

ValueMeaning
documentUploadRequiredPaytrie needs identity documents uploaded directly.
manualReviewA person at Paytrie is reviewing the submission.
verificationFailedIdentity verification did not pass.

Required fields

requiredFields lists what is still outstanding as dot-paths into the PATCH /v2/users/{userId} body, so you can submit them back exactly as they are returned. It is empty when a requirement is already satisfied, or when it is not field-driven — kyc is completed through the verification flow rather than by submitting fields.

What each requirement means

RequirementSatisfied by
emailVerificationSet automatically for users created through the API
phoneVerificationSet automatically for users created through the API. Otherwise, verifying the user's phone
disclosureThe integrator passing false for both pep and tpd, meaning the user is not a Politically Exposed Person and is not a Third-Party Determination
personalInfofirstName, lastName, dob
addressaddressLine1, city, province, postalCode
occupationoccupation
additionalInfoThe olderUserInfo fields, for users aged 50 or over at signup
kycCompleting identity verification, or importing a reusable KYC result
kycRefreshRe-confirming details once the annual refresh window elapses

additionalInfo is the one integrations meet unexpectedly. It applies only to users who were 50 or over when they signed up, and it blocks the KYC link until it is filled in — GET /v2/users/{userId}/kyc-url returns 422 while it is outstanding.

Submit the outstanding fields

Send whatever the requirements response named. Every field is optional, so you can submit them all at once or a few at a time.

curl -X PATCH "https://api.paytrie.com/v2/users/550e8400-e29b-41d4-a716-446655440000" \
  -H "x-api-key: your-api-key" \
  -H "Authorization: Bearer <access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "olderUserInfo": {
      "sourceOfFunds": "Salary",
      "intendedUseOfUSDC": "Savings",
      "walletProvider": "MetaMask"
    }
  }'

Reading the requirements again narrows requiredFields to what is still missing:

"additionalInfo": {
  "status": "pending",
  "requiredFields": [
    "olderUserInfo.walletAddress",
    "olderUserInfo.howDidYouHear",
    "olderUserInfo.whoReferredYou",
    "olderUserInfo.previousCryptoExperience"
  ]
}

Repeat until nothing is pending except kyc, then generate the verification link.

Unknown or misplaced keys are rejected with a 422 rather than ignored. Submitting sourceOfFunds at the top level instead of nested under olderUserInfo returns Unrecognized keys, so a mistake fails loudly instead of appearing to succeed.

API Reference: Update a user

View complete request parameters and response schema

Verify a user's phone

Users created with POST /v2/users start with a verified phone. A user who signed up with Paytrie some other way may not, and phoneVerification stays pending until they confirm a number. Both calls act on the user behind the access token, so they need Authorization: Bearer as well as your API key.

Send the code

curl -X POST "https://api.paytrie.com/v2/users/me/phone/send-verification" \
  -H "x-api-key: your-api-key" \
  -H "Authorization: Bearer <access-token>" \
  -H "Content-Type: application/json" \
  -d '{"phone":"4161234567"}'

Paytrie saves the number to the user and texts them a code, returning 202.

Send the user's own 10-digit mobile number. VoIP and prepaid numbers are rejected, and a rejected number stops the user from completing identity verification until Paytrie support reviews the account. Check the number with the user before you submit it.

Submit the code the user received

curl -X POST "https://api.paytrie.com/v2/users/me/phone/verify" \
  -H "x-api-key: your-api-key" \
  -H "Authorization: Bearer <access-token>" \
  -H "Content-Type: application/json" \
  -d '{"code":"1234"}'

A 204 means the phone is verified.

StatusMeaning
400The number was rejected (see the warning above), or the code is wrong. After too many wrong attempts Paytrie texts the user a new code
403The phone number can no longer be changed because the phone or the account is already verified
409The code was correct, but the number is already verified on another account. It is removed from this user, so send a code to a different number
422Validation failed
429Too many requests. Wait the number of seconds in the Retry-After header before retrying

Updating a user's information

PATCH is also how you update a user's details after they are created — for example when verification fails because an address no longer matches their identity document. Submit the corrected fields and generate a new verification link.

On this page