Read how SCA impacts the transfer endpoint
OWNER
) transfers funds to another Mangopay Account holder, they must authenticate using SCA.
This means that when an OWNER
user initiates a transfer to a wallet held by another OWNER
user, the first user must authenticate the request.
USER_NOT_PRESENT
below can be used to declare an automated workflow transfer which won’t trigger SCA redirection. In future, and based on its analysis of adoption, Mangopay may be required to take action to ensure SCA adoption, such as overriding these requests.OWNER
user and another, your platform needs to implement SCA redirection to Mangopay’s hosted webpage.
ScaContext
, which your platform needs to send on all transfers initiated by users whose UserCategory
is OWNER
.
The ScaContext
parameter has the values:
USER_PRESENT
– The user is initiating the transfer and is actively present. The platform must redirect the user for SCA using the PendingUserAction.RedirectUrl
returned, unless an exemption can be applied by Mangopay such as on low-amount and low-risk transfers. Platforms are not able to request specific exemptions (read more).USER_NOT_PRESENT
– No user is present: the transfer is automated by the platform as part of their declared and authorized workflow. On these transfers, SCA redirection is not initially required, but in future Mangopay may be required to override the request.null
, which has the same meaning as USER_NOT_PRESENT
. This approach allows existing platforms to introduce SCA on their existing integration without undue consequences or breaking changes. Mangopay’s objective is to protect your users when they benefit from our services, via an authentication solution that is easy for your platform to adopt.
For new platforms, the parameter should be considered required for transfers initiated by OWNER
users, and USER_PRESENT
should be considered the default value.
You do not need to send this parameter if the UserCategory
is PAYER
.
See API request example with user present
ScaContext
may technically result in the need for SCA redirection: you can include USER_PRESENT
and be exempted by Mangopay, or include USER_NOT_PRESENT
and, in future, have SCA imposed by Mangopay.
If Mangopay determines that SCA is required for the transfer request, the API response contains PendingUserAction.RedirectUrl
, as shown in the example below.
See API response example if SCA required
returnUrl
before you redirect the user on the RedirectUrl
value, otherwise the hosted web page cannot return them upon completion.For more details, see How to redirect a user for SCA.returnUrl
, regardless of the outcome.
Status
essential.
Whereas previously, a Transfer’s Status
would typically pass to SUCCEEDED
quickly, with SCA it will remain in CREATED
until the user completes SCA.
This means that your platform needs to rely on the existing webhook event types for the outcome of the transfer:
TRANSFER_NORMAL_SUCCEEDED
TRANSFER_NORMAL_FAILED
Status
changes to FAILED
and there are two new SCA-related functional errors that may be returned in ResultCode
and ResultMessage
:
ResultCode | ResultMessage | Description |
---|---|---|
007101 | Transfer authentication failed. Please retry with a new request. | The user reached the maximum number of retries for one of the authentication factors, so the SCA session failed. |
007102 | Transfer authentication expired. Please initiate a new request. | The user did not complete all steps required within 10 minutes, so the SCA session expired. |
DebitedWalletId
and CreditedWalletId
belong to different OWNER
users.DebitedFunds.Amount
is greater than 30 EUR or equivalent. So if Currency
is EUR
, this means Amount
must be 3001
or more.ScaContext
is USER_PRESENT
LegalPersonType
is BUSINESS
, PARTNERSHIP
, or ORGANIZATION
ScaContext
is USER_NOT_PRESENT
or not sent (in which case it is null
)ScaContext
value USER_PRESENT
.
See the Postman guide for details on how to fork the collection and set up your environment with your ClientId
and API key.