Skip to content
Home/
Digital Banking
/
/
SEPA Credit Scheduled Tra...
Last updated

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.

This API replaces the previous Standing Orders and Timed Orders functionality, expanding capabilities to cover a broader range of scheduled payment scenarios with improved control and reliability. See the overview page to learn more about SEPA and the different types of SEPA payment schemes.

Prerequisites:

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

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

Schedule transfers have the same transaction type and booking type as a standard SCT and SCT Instant, which is SEPA_CREDIT_TRANSFER or SEPAInstantCreditTransfer respectively.

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 execution_schedule is set to "WEEKLY" , "EVERY_TWO_WEEKS" , "MONTHLY" , "QUARTERLY" , "EVERY_SIX_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 an existing scheduled transfer at any time using the PATCH Cancel a scheduled transfer endpoint. In rare cases, Solaris Customer Support manually cancels scheduled transfers, such as during account closure.

This action requires Strong Customer Authentication (SCA) through the change request process.

Modification of scheduled transfers

Customers can modify the details of an existing, active scheduled transfer using the PATCH Update a scheduled transfer endpoint.

Updatable fields

The request body allows updating one or more of the following optional fields:

  • amount: The new transaction amount (value in Euro cents and currency EUR).
  • description: The updated textual reference or purpose of the transfer.
  • active_to: The updated expiration date (YYYY-MM-DD). Solaris executes the final transfer on or before this date.

You can only modify amount, description, and active_to. If the customer needs to change the recipient (IBAN), the transfer scheme (SCT vs. SCT Inst), or the recurrence interval, they must cancel the existing scheduled transfer and create a new one.

Modification process

  1. Initiate the update: Call PATCH /v1/accounts/{account_id}/scheduled_transfers/{id} with the modified attributes.
  2. Authorize the change request: The endpoint returns a 202 Accepted response with a change_request object. The customer must authorize the challenge using their registered authentication method (SMS OTP or device signing challenge).
  3. Receive the outcome webhook: Once the customer completes or fails the challenge, Solaris emits the SCHEDULED_TRANSFER_UPDATED webhook:
    • UPDATE: The customer successfully authorized the change request. The webhook payload contains the updated fields and the recalculated next_execution_date.
    • FAILURE: The customer rejected the challenge, the challenge expired, or authentication failed. The webhook payload contains a reason explaining why Solaris could not apply the update.

Scheduled transfer statuses

A scheduled transfer can have the following statuses:

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

ACTIVE : The customer completed the change request process, and the scheduled transfer is actively running.

CONCLUDED : The scheduled transfer reached its final execution date as defined in active_to (for recurring transfers), or Solaris executed a ONE-TIME scheduled transfer on its active_from date.

CANCELED : You or Solaris canceled the scheduled transfer.

Solaris sends a SCHEDULED_TRANSFER_STATUS_CHANGED webhook when the scheduled transfer status changes to ACTIVE, CONCLUDED, or CANCELED.

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

  • SCHEDULED_TRANSFER_STATUS_CHANGED : Solaris sends this webhook when the status of the scheduled transfer changes to ACTIVE, CONCLUDED, or CANCELED.
  • SCHEDULED_TRANSFER_UPDATED : Solaris sends this webhook when a scheduled transfer update completes (type: UPDATE with the modified attributes) or fails (type: FAILURE with a rejection reason).
  • SEPA_CREDIT_TRANSACTION_DECLINED : Solaris sends this webhook when a regular SCT scheduled transfer execution fails, specifying the schedule ID in schedule_id and the failure reason in rejection_reason.
  • INSTANT_SEPA_CREDIT_TRANSFER_FAILED : Solaris sends this webhook when an SCT Instant scheduled transfer execution fails, specifying the schedule ID in schedule_id and the failure reason in rejection_reason.
  • INSTANT_SEPA_CREDIT_TRANSFER_EXECUTED : Solaris sends this webhook when it successfully executes an SCT Instant scheduled transfer, specifying the schedule ID in schedule_id.
  • BOOKING : Solaris sends this webhook whenever a successful execution creates a booking on the account.

API reference documentation:

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

Previous page
Next page