API - May 11, 2026 | Mangopay docs

Changed

Email property per Hook for failed notification alerts

Platforms can now set a dedicated email address for each webhook event type.

The email address is used to send alerts after:

25, 50, and 75 consecutive failed notification attempts, to warn you that Mangopay is not receiving a 200 HTTP response from your endpoint
100 consecutive failed attempts, to notify you that, as a result, the Hook’s VALIDITY has become INVALID and notification attempts have stopped

The Email property can be set on:

Platforms integrating for the first time must set the Email proactively to receive these notifications.

For existing platforms, Mangopay automatically populates this property with the previously used global email address (provided one was set) unless and until you set it proactively on a Hook.

This behavior means that your existing alerts are maintained and that there is no impact on new Hooks unless you decide to set the Email. Mangopay will continue to set the email automatically, but recommends that you integrate the Email property on all new Hooks that you create.

The Email is also returned on GET View a Hook and GET List Hooks.

For all platforms, if the Email is not defined on a Hook and is null in the API response, the Hook still becomes INVALID after 100 consecutive failed notifications but email alerts are not sent.

Note – Integration depends on date of Production Hook integration

If your platform didn’t have any VALID Hooks in Production on April 2, 2026, then you must set the Email at creation or update to receive alerts. You can do this via the API directly (for example, using Postman): you can’t yet manage the email via the Dashboard.

For platforms that integrated before April 2, 2026, this change does not impact your existing webhook setup unless and until you set the Email on a new or existing Hook.

Added

SCA: Theme parameter to set dark or light mode on SCA redirection

When redirecting a user for SCA, you can now add the theme to the URL as a query parameter with the value dark or light (for example, &theme=dark) to force the mode of session.

Note that if the user changes the mode in the session then their preference is stored as a local cookie for 30 days and takes precedence over the theme that you set.

Added

DateRangeBy property to generate reports based on transaction ExecutionDate

You can now generate the USER_WALLET_TRANSACTIONS and COLLECTED_FEES reports based on the transaction ExecutionDate instead of CreationDate.

The ExecutionDate is the date and time that the transaction Status became SUCCEEDED, which is likely to be more useful for most platforms. Note also that these reports only contain successful transactions.

On calls to the POST Create a Report endpoint for these report types, set the DateRangeBy property to ExecutionDate to use it for the range specified in the AfterDate and BeforeDate. If not specified, these Unix timestamps filter by the transaction CreationDate.

Added

Ability to list all recipients regardless of scope

The GET List Recipients for a User endpoint now accepts the ALL and PAYIN values for the RecipientScope query parameter. This allows retrieval of both PAYOUT and PAYIN recipients together.

The default value for RecipientScope remains PAYOUT, so existing integrations continue to receive payout recipients only unless another value is specified.

By default, results are sorted by CreationDate in descending order (CreationDate:DESC), but the CreationDate:ASC value has also been added to the Sort query parameter.

Read more about recipient scopes in the guide →

Added

VOP: Dedicated property for suggested name during Recipients check

If the Verification of Payee (VOP) check performed on the POST Create a Recipient endpoint returns a CLOSE_MATCH result, the name returned by the check is now returned in a dedicated property: RecipientVerificationOfPayee.RecipientVerificationPayeeSuggestedName.

This allows you to re-register the Recipient with the suggested name if you wish.

The data was already returned as part of the RecipientVerificationMessage, but a dedicated property makes it easier to parse and use.

The RecipientVerificationPayeeSuggestedName is not returned on a Payout request, even if the result is CLOSE_MATCH.

Read more about VOP checks on Recipients and Payouts →