User KYC/KYB verificationHosted KYC/KYBLegacy hosted flows

Organization - Legacy single-session flow

This page describes the previous hosted IDV flow for the Organization user type (the legacy integrated flow), in which a single individual completes the liveness check within the main IDV Session.

If your platform has been migrated to the new flow (the multi-session PSC flow), where all Persons of Significant Control (PSCs) are verified individually through separate PSC Sessions, see the Business guide instead.

Prerequisites

Before launching a hosted IDV Session for an Organization, please ensure that:

  • The Registration Proof they will need to upload conforms to the one expected by Mangopay
  • The Articles of Association they will need to upload conforms to the one expected by Mangopay
  • They have registration details about their organization
  • An individual listed in the national registry is available to perform the liveness check (the link can be closed and reopened)
  • The ID proof the individual will use is accepted by Mangopay

Flow description

Currently, when a hosted IDV session is generated for a Legal Organization:

  1. The session Status is PENDING and can be submitted within 7 days, at which point it becomes EXPIRED. This emits the IDENTITY_VERIFICATION_PENDING webhook.
  2. The user opens the session and sees a welcome screen explaining:
    • That they will need to provide details of their entity
    • That they will need to provide Registration Proof (RP) and Articles of Association (AoA) documents (links to the KYB local page are provided later in the flow)
    • That a registered director (not necessarily the one listed in the LegalRepresentative fields) will need to complete the liveness check with their ID and smartphone, with a link to Mangopay’s accepted ID documents
  3. The user enters details of their entity:
    • Country of registration
    • Optionally, registration number provided by the relevant national authority
    • Registered organization name
    • Registered organization address
  4. The session must then be opened by the registered director who will complete the liveness check (the session autosaves progress)
  5. The registered director completes the liveness ID check (via QR code or directly if session opened on a phone) by:
    • Taking a photo of their ID (or two photos if it’s a driver’s license or national ID card)
    • Taking a selfie of their face
  6. The session is redirected to the ReturnUrl
  7. Mangopay performs automated liveness validation checks:
    • IDENTITY_DOCUMENT_VERIFICATION
    • IDV_AGE_CHECK

Checks performed

Currently, for Legal Organization users, the following checks are performed:

TypeDescription
IDENTITY_DOCUMENT_VERIFICATIONVerifies the authenticity of the identity document, the liveness of the selfie, and that the selfie matches the identity document photo.
IDV_AGE_CHECKChecks whether the individual on the identity document meets the minimum age requirement for Mangopay users (age 18).

Only performed if IDENTITY_DOCUMENT_VERIFICATION is successful.

Outcomes

For a Organization user, the IDV Session can be refused automatically but otherwise is always reviewed manually. The following outcomes are possible (from a PENDING status):

Automated refusal

The Status becomes REFUSED if any of these checks fail:

  • IDENTITY_DOCUMENT_VERIFICATION
  • IDV_AGE_CHECK

This emits the IDENTITY_VERIFICATION_FAILED webhook. In this case:

  • You can retrieve more information in the IDV Session’s:
    • Checks.CheckStatus - For which checks were REFUSED
    • Checks.Reasons – For the refusal reasons (Type and preset Value)
  • You need to generate a new session to retry (even if some of the checks were validated)

Manual review

Provided the IDENTITY_DOCUMENT_VERIFICATION and IDV_AGE_CHECK are successful, the Status becomes REVIEW. This emits the IDENTITY_VERIFICATION_INCONCLUSIVE webhook.

In this case:

  • Mangopay reviews the session data and documents manually.
  • Automatically validated checks are returned, including verified data, but the User object data is only overwritten if the session is validated

Validation after review

If the manual review is successful, the Status changes from REVIEW to VALIDATED. In this case:

  • The verified data is overwritten in the User object:
    • LegalRepresentative.FirstName (even if the fields previously referenced a different individual)
    • LegalRepresentative.LastName
    • LegalRepresentative.Birthday
    • Name
    • CompanyNumber
  • The User’s KYCLevel becomes REGULAR

Refusal after review

If the manual review is unsuccessful, then the status changes to REFUSED.

In this case:

  • Verified data may be returned in the IDV Session but no action is taken with it
  • You can retrieve more information in the IDV Session’s:
    • Checks.CheckStatus - For which checks were REFUSED
    • Checks.Reasons – For the refusal reasonsType and, in the case of a manual review, a custom message in the Value
  • You need to generate a new session to retry (even if some of the checks were validated)

Testing

For general guidance on testing the hosted IDV experience in Sandbox, see Testing.

For an Organization user, the simulation of checks performed retain their conditional logic: IDV_AGE_CHECK is only performed if IDENTITY_DOCUMENT_VERIFICATION is validated.

Sequence diagram

The following diagram gives an overview of the integration flow:

Integration flow

1

Initiate the hosted session

Call the POST Create an IDV Session endpoint with the UserId to initiate a hosted KYC/KYB verification session.

You must include a ReturnUrl to which the session redirects once it is completed, before the outcome is known.

In the API response:

  • The HostedUrl value is the URL for the unique session, with your ReturnUrl encoded and appended.
  • The Status is PENDING, indicating that the session is available via the HostedUrl value, and the user has not successfully completed all the necessary steps.

The PENDING status emits the IDENTITY_VERIFICATION_PENDING webhook event type with the session Id (read more about setting up webhooks).

2

Redirect the user to the hosted session

Redirect the user to the HostedUrl value received in the response.

By default, the session can be submitted within 7 days, after which the Status changes to EXPIRED. If the liveness step has been opened (the QR code was generated), the session instead expires 1 hour after it started.

The object Status remains PENDING regardless of whether the session has been started or not. On your side you can track whether the HostedUrl was accessed by the user.

3

Let the user complete the session

On the HostedUrl, the experience guides the user through entering entity details, uploading KYB documents, and having the registered director complete the ID liveness check using their smartphone. If the session is opened on desktop then a QR code is displayed for the user to scan.

4

Receive the user after completion

Once the session is completed, the HostedUrl redirects to the ReturnUrl.

The outcome of the session is not returned immediately.

5

Listen to webhooks

When the outcome of the session is known, the Status is updated from PENDING and a webhook notification is emitted.

The PENDING value can change directly to one of:

StatusWebhook event typeDescription
VALIDATEDIDENTITY_VERIFICATION_VALIDATEDThe User became KYC/KYB verified: KYCLevel changed to REGULAR and verified data updated in the User object.
REFUSEDIDENTITY_VERIFICATION_FAILEDUser was not KYC/KYB verified and a new session must be created for them to retry.

Or, the session may first pass to a temporary state before the final outcome:

StatusWebhook event typeDescription
REVIEWIDENTITY_VERIFICATION_INCONCLUSIVEThe session is under manual review by Mangopay’s teams.
6

Handle outcomes

Once you receive a webhook, call GET View an IDV Session for more details about the session.

In a successful case, this endpoint returns the verified data points that are updated in the User object.

For REFUSED cases, the endpoint returns information about which Checks failed and for what reasons.

To see key details about all the sessions attempted for a user, call GET List IDV Session for a User.

State machine

The following diagram shows the statuses of the IDV Session object for an Organization user:

Webhooks

The hosted KYC/KYB verification feature takes time for the user to complete.

You are strongly recommended to implement webhooks for IDV Sessions and rely on them in your integration.

Once you receive a webhook notification, call GET View an IDV Session for more details.

The following event types are available for an Organization:

  • IDENTITY_VERIFICATION_PENDING – The IDV Session’s Status is PENDING. The HostedUrl link is valid for completion and must be submitted within 7 days (or 1 hour after the liveness step is opened). The session may or may not have been started.
  • IDENTITY_VERIFICATION_VALIDATED – The IDV Session’s Status changed to VALIDATED and the User became KYC/KYB verified.
  • IDENTITY_VERIFICATION_FAILED – The IDV Session’s Status changed to REFUSED and the User was not KYC/KYB verified. A new session is needed for them to retry.
  • IDENTITY_VERIFICATION_INCONCLUSIVE – The IDV Session’s Status changed to REVIEW and the session is under manual review by Mangopay’s teams before an outcome can be given.
  • IDENTITY_VERIFICATION_EXPIRED – The IDV Session’s Status changed to EXPIRED. A new session is needed to retry.
  • IDENTITY_VERIFICATION_OUTDATED – The IDV Session’s Status changed to OUT_OF_DATE indicating that the user’s KYC/KYB verification status was downgraded. To regain KYC/KYB verified status, the user must complete a new IDV Session successfully.

Verified data

The hosted KYC/KYB session gathers user data which is then verified as part of the process. This data is returned in the session’s Checks.Data. You can retrieve it using the GET View an IDV Session endpoint.

These data points are overwritten if the session Status is VALIDATED, but the Data may still be returned if the status is REFUSED or REVIEW.

As part of the IDENTITY_DOCUMENT_VERIFICATION check, the data in the next table is extracted from the ID document. If this check fails, the session Status is REFUSED and no data is overwritten.

Data.Type value extracted from IDUser object property overwritten if Status is VALIDATED
LEGAL_REPRESENTATIVE_FIRST_NAMELegalRepresentative.FirstName
LEGAL_REPRESENTATIVE_LAST_NAMELegalRepresentative.LastName
LEGAL_REPRESENTATIVE_BIRTHDATELegalRepresentative.Birthday