Event types

The User has been blocked by Mangopay and can no longer make pay-ins or send or receive transfers.

The User has been unblocked by Mangopay and can now make pay-ins or send or receive transfers.

The User has been blocked by Mangopay and can no longer make payouts or send or receive transfers.

The User has been unblocked by Mangopay and can now make payouts or send or receive transfers.

The Owner User (Natural or Legal Soletrader) has triggered SCA enrollment or re-enrollment via a User endpoint. Their access to SCA-triggering actions is restricted until they complete the SCA redirection to enroll successfully.

This event is only triggered when the User’s UserStatus changes to PENDING_USER_ACTION, which only happens in the situations described here.

To obtain a new SCA redirection link to retry enrollment, call the POST Enroll a User endpoint.

The Owner User (Natural or Legal Soletrader) completed an SCA session successfully, and can now access Mangopay features.

This event is only triggered when the User’s UserStatus changes from PENDING_USER_ACTION to ACTIVE.

The User (Owner or Payer) was permanently closed and their UserStatus changed to CLOSED.

The User was closed either by the platform, using the dedicated endpoint for Natural or Legal users, or by Mangopay as per the terms and conditions.

A user can only be closed if all the wallets they hold are empty.

The user enrolled in Mangopay’s SCA feature successfully.

This event is triggered by any new enrollment (or re-enrollment) prompted by an API call, regardless of the endpoint that returned the SCA redirection link (users, recipients, transfers, wallets – see full list of endpoints).

This event is not triggered by authentication challenges once the user is enrolled.

The SCA enrollment session expired after 10 minutes before the user completed all steps to enroll all factors. To retry the enrollment, call another API endpoint that triggers SCA.

This event is not triggered by authentication challenges once the user is enrolled.

The user attempt enrollment but reached the maximum number of retries for one of the factors. To retry the enrollment, call another API endpoint that triggers SCA.

This event is not triggered by authentication challenges once the user is enrolled.

The email address required for SCA was successfully verified by the completion of an SCA session after it was added or changed via an API call.

Note that a user cannot modify their email address from within an SCA session.

The phone number used for SCA’s OTP factor was verified by the completion of an SCA session after it was changed either from within an SCA session or via an API call.

The user checked the checkbox (and completed the SCA session) to give consent for your platform to update the User’s SCA contact information on their behalf, which you can do by setting ScaContext to USER_NOT_PRESENT in a call to:

• PUT Update a Natural User (SCA) to modify the PhoneNumber, PhoneNumberCountry, or Email
• PUT Update a Legal User (SCA) to modify the PhoneNumber, PhoneNumberCountry, or Email of the LegalRepresentative

The user checked the checkbox (and completed the SCA session) to give consent for your platform to initiate a transfer to another OWNER user on their behalf, which you can do by setting ScaContext to USER_NOT_PRESENT in a call to:

• POST Create a Transfer

The user checked the checkbox (and completed the SCA session) to give consent for your platform to register an external bank or payment account on their behalf, which you can do by setting ScaContext to USER_NOT_PRESENT in a call to:

• POST Create a Recipient

The user checked the checkbox (and completed the SCA session) to give consent for your platform to retrieve wallet and transaction data on their behalf, which you can do by setting ScaContext to USER_NOT_PRESENT in a call to:

• GET View a Wallet
• GET List Wallets for a User
• GET List Transactions for a User
• GET List Transactions for a Wallet

The user unchecked the checkbox (and completed the SCA session) to revoke consent to your platform updating the User’s SCA contact information on their behalf.

The user unchecked the checkbox (and completed the SCA session) to revoke consent for your platform to initiate a transfer to another OWNER user on their behalf.

The user unchecked the checkbox (and completed the SCA session) to revoke consent for your platform to register an external bank or payment account on their behalf.

The user checked the checkbox (and completed the SCA session) to give consent for your platform to retrieve wallet and transaction data on their behalf

The existing user’s UserCategory was changed to OWNER.

This event is not triggered if OWNER is set at user creation. This event usually coincides with SCA, triggering USER_ACCOUNT_VALIDATION_ASKED.

The existing user’s UserCategory was changed to PAYER. Re-categorization from OWNER to PAYER is only possible by Mangopay.

The existing user’s UserCategory was changed to PLATFORM. Categorization as PLATFORM is only possible by Mangopay.

GET View a User (SCA)

User KYC/KYB verification

The User is not KYC/KYB verified by Mangopay and is therefore subject to KYC/KYB verification limits.

The User’s KYCLevel has changed from REGULAR to LIGHT.

The User was KYC/KYB verified by Mangopay.

The User’s KYCLevel changed from LIGHT to REGULAR.

GET View a User Regulatory Status

User KYC/KYB renewal

The User’s KycRenewalDeadline is in 90 days.

If the KYC/KYB verification process is not successfully completed before the end of this date (UTC), then the User’s KYCLevel will be downgraded to LIGHT the following day.

As a result, the User will be subject to the same limits as an unverified user. For platforms in the EEA, this means they will be unable to request payouts.

The User has successfully completed the KYC/KYB verification process and a new KycRenewalDeadline has been set.

The User’s KYCLevel has not changed and remains REGULAR.

The IDV Session’s Status is PENDING. The HostedUrl link is valid for completion and must be submitted within 7 days. The session may or may not have been started.

After 7 days, the Status of the IDV Session object changes to EXPIRED and can no longer be submitted. However, the link returned on HostedUrl remains active.

Note that there is not yet a webhook notifying you when the session expires after 7 days from the CreationDate, so you need to track this on your side.

The IDV Session’s Status changed to VALIDATED and the User became KYC/KYB verified.

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.

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.

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.

The format of the company number is not valid for the headquarters address country of the Business-type Legal User. A invalid format blocks verification.

The format of the company number is valid for the headquarters address country of the Business-type Legal User. The format is as expected for the country of registration but the veracity of the data has not yet been verified.

The KYC Document has been created but not yet submitted for review.

The KYC Document has been submitted for validation and is being processed.

The KYC Document has been validated by Mangopay.

The KYC Document has been refused by Mangopay.

The KYC Document is no longer valid. This is due to an amendment of the user’s identity or other key details as per the KYC/KYB verification downgrade.

The UBO Declaration has been created but not yet submitted for review.

The UBO Declaration has been submitted for validation and is being processed.

The UBO Declaration has been validated by the Mangopay Compliance team.

The UBO Declaration is incomplete and additional information or documents may be required.

The UBO Declaration has been refused by Mangopay.

The restrictions related to a country have been updated.

The Recipient was created successfully, including the SCA session if RecipientScope is OWNER, and it can now be used for payments.

The Recipient creation was unsuccessful because the SCA session was not successful. The CANCELED status is only relevant if RecipientScope is OWNER.

The Recipient was permanently deactivated and can no longer be used.

The PayIn transaction has been created but is not yet processed.

The PayIn transaction has been successfully processed.

The PayIn transaction has failed.

The Card Validation object has been created and the card is pending validation.

The Card Validation has failed, setting the corresponding card as invalid.

The Card Validation has succeeded, setting the corresponding card as valid.

The Recurring Registration object has been successfully created.

A pay-in against this recurring object requires authentication.

The Recurring Registration object is in a valid state. Pay-ins against this recurring registration are possible.

The Recurring Registration object has been ended. It is no longer possible to make pay-ins against this recurring registration.

The Preauthorization object has been successfully created.

The authorization of this Preauthorization has failed.

The authorization of this Preauthorization has been canceled.

The authorization of this Preauthorization has expired.

The Preauthorization has been successfully debited.

The Preauthorization object can now be debited.

The authorization of this Preauthorization has been successful.

• Card – 30-day deposit preauthorization
• PayPal – PayPal deposit preauthorization

The Deposit Preauthorization object has been successfully created.

The authorization of the Deposit Preauthorization has been successful. It can now be debited.

The Deposit Preauthorization has been successfully debited: a successful pay-in against the preauthorization has been made. No further action can be taken.

The payment action against the Deposit Preauthorization has failed. A retry may be possible.

The authorization of the Deposit Preauthorization has failed.

The request to cancel the Deposit Preauthorization has been taken into account.

The Deposit Preauthorization has been successfully canceled.

The authorization of the Deposit Preauthorization has expired.

The Pay by Bank PayIn has been successfully initiated by the user. The funds have not yet arrived on Mangopay’s bank account and the pay-in Status is still CREATED.

The account is active and can receive funds (see note about delayed UK CoP recognition for GB accounts).

The account is blocked and is not active. Any funds sent to the account are returned. This temporary status may be used during processes relating to user verification or fraud screening.

The account has been deactivated and is closed. Any funds sent to the account are returned. This is a final state.

The account creation request failed or was rejected. This final state is rare. Any funds sent to the account are returned (if account details exist).

The Mandate has been created.

The Mandate has been successfully validated, an email has been sent to the end user (if emails are configured).

The Mandate request has been successfully created and validated. A bank wire can be initiated.

The Mandate request has failed.

The Mandate has expired. It is no longer possible to make bank wire pay-ins against this mandate.

The Dispute has been created. It can either be closed directly or reviewed by the platform.

The contestable Dispute requires further action. The platform is notified by Mangopay in a short period of time.

The Dispute has been contested by the platform, either entirely or partially.

The Dispute has been sent to the bank for review and approval following the Dispute Documents validation.

To settle the Dispute, additional documents are required.

The Dispute has been closed. It can either be WON or LOST by the platform.

The Dispute Document has been successfully added to the Dispute, either by the platform or Mangopay’s team.

The Dispute Document has been refused by Mangopay’s team.

The Dispute Document has been validated by Mangopay’s team.

The Dispute Document has been sent to Mangopay’s team for validation.

A chargeback has been filed and has been created in Mangopay’s environment (Repudiation Wallet).

A chargeback has been filed but the transaction from the Repudiation Wallet back to the initial pay-in author has failed.

A chargeback has been filed and successfully sent back to the initial pay-in author.

The Settlement Transfer has been created but is not yet processed.

The Settlement Transfer could not be processed.

The Settlement Transfer has been successfully processed.

The Transfer has been created but is not yet processed.

The Transfer could not be processed.

The Transfer has been successfully processed.

The Instant Conversion was initiated and its Status changed to CREATED, but is not yet processed.

The Instant Conversion was processed successfully and its Status changed to SUCCEEDED.

The Instant Conversion could not be processed. See the ResultCode and ResultMessage for more information about the error that occurred.

The Quoted Conversion was initiated and its Status changed to CREATED, but is not yet processed.

The Quoted Conversion was processed successfully and its Status changed to SUCCEEDED.

The Quoted Conversion could not be processed. See the ResultCode and ResultMessage for more information about the error that occurred.

The Payout transaction has been created but is not yet processed.

The Payout transaction has failed.

The Payout transaction has been successfully processed.

The Instant Payout transaction has failed.

The Payout could not be processed instantly; it will be processed in 48 hours as a standard payout instead.

The Instant Payout transaction has been successfully processed.

The PayIn Refund transaction has been created but is not yet processed.

The PayIn Refund transaction could not be processed.

The PayIn Refund transaction has been successfully processed.

The Transfer Refund has been created but is not yet processed.

The Transfer Refund transaction could not be processed.

The Transfer Refund transaction has been successfully processed.

The payout return has been created.

The payout return has failed.

The payout return has been successfully processed.

The Intent was successfully created.

The Intent Capture was successfully processed.

The Intent Refund was successfully processed.

The Intent Refund was successfully reversed.

The Intent Dispute was successfully processed.

The Intent Dispute Status was successfully changed to DEFENDED.

The Intent Dispute was successfully processed as WON.

The Intent Dispute was successfully processed as LOST.

The Intent was successfully reconciled.

The Intent was successfully paid.

The Split was successfully created.

The Split was successfully reconciled.

The Split was successfully paid.

The Split could not be processed due to a technical issue, and can be retried.

The Split was successfully reversed.

The report has been generated and is ready for download at the DownloadURL value.

The report was not generated successfully.