Scheduled Transfers

Introduction

Scheduled Transfers enable seamless integration of future-dated payment functionality into your application. It supports both recurring and one-off payments with full control over scheduling and execution. The feature is compatible with SEPA Credit Transfers (SCT) and SEPA Instant Credit Transfers (SCT Inst), offering flexibility to accommodate a wide range of payment scenarios.

Prerequisites:

You must implement the following features in order to use scheduled transfers in your solution:

• Device binding
• Strong Customer Authentication
• Verification of a Payee
• SEPA Credit Transfers
• SEPA Instant Credit Transfers

How It Works

A Scheduled Transfer functions similarly to a standard SEPA Credit Transfer (SCT) or SEPA Instant Credit Transfer (SCT Instant), depending on the selected transfer type. You should allow end users to choose between SCT and SCT Instant when configuring a scheduled transfer. Due to regulatory requirements, offering only SCT is not permitted. You must support SCT Instant as well.

Before a transfer can be scheduled, the customer must complete the Verification of Payee (VoP) process to confirm the recipient's account details. Once verified, the frontend should guide the user through setting up the transfer, which initiates a change request. The customer then authorizes the request using either SMS OTP or a device signing challenge.

Process Overview:

1. The customer logs into their account and initiates a scheduled transfer. As part of this process, they provide the recipient's name and IBAN, which triggers the VoP check.

2. The customer selects the transfer type (SCT or SCT Inst) and inputs relevant details such as:

   • Amount
   • Execution schedule (e.g., recurring or one-off)
   • Execution date
   • Verification of Payee ID
3. The customer authorizes the scheduled transfer using two-factor authentication (2FA) via SMS One-Time Password (OTP), or Device signing challenge

4. Before each scheduled execution, Solaris performs a real-time account check, including:

   • Validation of available_balance
   • Account status (must be ACTIVE)
5. If validations pass, Solaris executes the transfer. The transaction is booked on the customer’s account with one of the following booking types based on previous chosen method: SEPA_CREDIT_TRANSFER or SEPAInstantCreditTransfer

Execution Rules for Scheduled Transfers

One time scheduled transfers:

• The execution_schedule is set to ONE-TIME.
• For one-off transfers, active_from is the single execution date.
• The active_to property is not required.
• The transfer status changes from ACTIVE to CONCLUDED immediately after execution.

Recurring scheduled transfers:

• The executionschedule is set to WEEKLY, EVERYTWOWEEKS, MONTHLY, QUARTERLY, EVERYSIX_MONTHS or ANNUALLY.
• A scheduled transfer is executed on the date defined in the active_from field.
• For recurring transfers, the transfer is executed on the last day of each recurrence interval, starting from active_from.
• When creating a recurring transfer, the customer can set an active_to date to specify when it should stop. Based on this active_to date,the scheduled transfer transitions from ACTIVE to CONCLUDED.

Execution failures:

In the event of a scheduled transfer execution failure:

• No booking will be recorded on the customer’s account.
• For regular SEPA Credit Transfers (SCT), the transfer status will be set to declined, and the SEPA_CREDIT_TRANSACTION_DECLINED webhook will be issued.
• For instant SEPA Credit Transfers (SCT Inst), the transfer status will be set to FAILED, accompanied by the INSTANT_SEPA_CREDIT_TRANSFER_FAILED webhook.
• Failed scheduled transfers will not be retried; the schedule will continue with the next execution as specified in the execution schedule.
• For transfers designated as ONE-TIME , a failure will immediately result in the scheduled transfer status being updated to CONCLUDED, with no further retry attempts.

A scheduled transfer may fail for various reasons. Depending on whether the transfer is a regular or instant SEPA Credit Transfer, the appropriate webhook will be sent. The specific reason for failure will be detailed in the failure_reason property.

Typical causes of transfer decline include:

• The target account is blocked, preventing transactions.
• The source account is blocked, preventing transactions.
• Insufficient funds to complete the transfer.
• The target account is closed.
• The source account is closed.

Cancellation of Scheduled Transfers:

Customers can cancel their previously set scheduled transfers at any time. Currently, modifying an existing scheduled transfer is not supported. To make changes, customers must cancel the existing transfer and create a new one. In rare cases, Solaris may also cancel scheduled transfers, such as during account closure or upon a customer support request. Such cancellations are handled manually by Solaris Customer support teams. Please use the PATCH Cancel a Scheduled Transfer API endpoint to enable your customer to cancel a scheduled transfer.

Scheduled Transfer Statuses

The scheduled transfer can have different statuses:

AUTHORIZATION_REQUIRED : When the creation of the scheduled transfer was triggered, but it has not yet been approved by using two-factor authentication (2FA) via an SMS OTP or a device signing challenge.

ACTIVE : When the scheduled transfer was created after the change request process and is now actively running.

CONCLUDED : When the scheduled transfer reaches it's last execution date as defined in the active_to property for recurring transfers. In case of a ONE-TIME scheduled transfer, the status changes once it's executed on the active_from date.

CANCELED : When the scheduled transfer is canceled.

Related webhooks:

Solaris recommends subscribing to the following webhook events, to better automate your processes. For detailed instructions on implementing Solaris webhooks, check the webhooks documentation.

SCHEDULE_TRANSFER_STATUS_CHANGED : When the status of the scheduled transfer is changed to ACTIVE, CONCLUDED and CANCELED.

SEPA_CREDIT_TRANSACTION_DECLINED : When the execution of the scheduled transfer with a transfer type SCT fails, you'll receive this webhook specifying the schedule transfer id in the schedule_id property and the reason of the failure in the rejection_reason property.

INSTANT_SEPA_CREDIT_TRANSFER_FAILED : When the execution of the scheduled transfer with a transfer type SCT_INSTANT fails, you'll receive this webhook specifying the schedule transfer id in the schedule_id property and the reason of the failure in the "rejection_reason" property.

INSTANT_SEPA_CREDIT_TRANSFER_EXECUTED : Only sent when the scheduled transfer with a transfer type SCT_INSTANT was executed successfully. The webhook will also specify which schedule transfer was successfully executed by providing the schedule_id property.

BOOKING : Whenever the execution of the scheduled transfer, irrespectively to the transfer type, was successful and created a booking.

API reference documentation:

To implement scheduled transfers, integrate the following endpoints in your solution:

• POST Create a Scheduled Transfer
• PATCH Cancel a Scheduled Transfer
• GET Get scheduled transfers for an account
• GET Get a single Scheduled Transfer