API - Apr 15, 2025

​

Recipients

​

Added

​

Recipients endpoints, replacing legacy bank accounts

Platforms can now integrate SCA on bank account registration thanks to the new Recipients feature, which is live in Sandbox.

As well as supporting SCA, Recipients enable faster and more reliable local and international payouts, thanks to dedicated endpoints to dynamically retrieve the schema of the account details, and validate the user’s data before registration.

The following endpoints have been added:

• GET View payout methods
• GET View the schema for a Recipient
• POST Validate data for a Recipient
• POST Create a Recipient
• GET View a Recipient
• GET List Recipients for a user
• PUT Deactivate a Recipient

The following webhook event types have been added:

• RECIPIENT_ACTIVE
• RECIPIENT_CANCELED
• RECIPIENT_DEACTIVATED

Your platform’s existing active bank accounts (BankAccountId) will continue to be usable for payouts, as well as direct debits and pay-in refunds. This migration is in progress and will be completed before Recipients goes live in Production (planned for mid-May 2025).

A new guide has been added:

---

​

Transfers

​

Added

​

ScaContext and PendingUserAction on transfers

Thanks to the new ScaContext body parameter on POST Create a Transfer, platforms can now introduce SCA on user-initiated transfers between Owners (using the USER_PRESENT value) and identify automated transfers made as part of their authorized workflow (using the USER_NOT_PRESENT).

The need to redirect for SCA, which may technically happen whatever the ScaContext value, is indicated by PendingUserAction in the response, which contains the RedirectUrl if SCA is needed (otherwise null).

​

Changed

​

User-initiated transfer status remains CREATED until SCA completed

If a transfer triggers SCA, its Status remains CREATED until SCA is completed, at which the transaction is attempted and it may then pass to SUCCEEDED.

This means your integration must rely on the existing transfer webhooks and object status.

​

Added

​

ResultCode 007101 and 007102 for SCA-related transfer failures

Because a transfer can fail due to an expired or unsuccessful SCA session, two new ResultCode errors have been added:

• 007101 – Transfer authentication failed. Please retry with a new request.
• 007102 – Transfer authentication expired. Please initiate a new request.

The existing guides have evolved with more guidance on the transfer scenario:

---

​

Wallet access

​

Added

​

ScaContext on wallet access endpoints

Thanks to the new ScaContext query parameter, platforms can now introduce SCA on Owner-initiated wallet access requests, using the USER_PRESENT value.

​

Changed

​

Wallet access endpoints return 401 if SCA required

To maintain the same behavior across the 4 GET endpoints impacted by SCA on wallet access, when SCA is required the endpoint returns a 401 - Unauthorized response. Your platform can retrieve the redirectUrl that you need to use for the unique hosted SCA session in the WWW-Authenticate response header.

The existing guides have evolved with more guidance on the transfer scenario: