Standing Orders

A standing order is a type of SEPA Credit Transfer (SCT) that allows customers to create and schedule transactions to be executed automatically at specific regular intervals. Your customers can set up standing orders for recurring payments, such as rent.

How does it work?

A standing order works exactly like a standard SEPA Credit Transfer (SCT). Offer your customer a frontend to log in and set up a standing order, which triggers the change request process. The customer must authorize the transaction either via an SMS OTP or a device signing challenge.

The process looks like this:

1. The customer logs in to their account to set up a standing order and provide the transaction details, such as the amount, recipient IBAN, start date, and the rate of re-occurrence.
2. The customer authorizes the standing order using two-factor authentication (2FA) via an SMS OTP or a device signing challenge.
3. Before executing each scheduled transaction, Solaris checks the account's available_balance to ensure that there are sufficient funds.
4. Solaris executes the standing order, which creates a booking on the customer's account with the booking type SEPA_CREDIT_TRANSFER.

Execution rules

A standing order is first executed on the date specified in the first_execution_date property and will be repeated on the same day for future payments based on the interval specified in the reoccurrence field.

For example, if the customer creates a standing order with the first_execution_date set to 2022-06-30 and the reoccurrence as MONTHLY, then the first payment will be executed on 2022-06-30, the following payment will be executed on 2022-07-30, and so on.

You can define a rule to handle differences between the number of days in each month using the field month_end_execution, which moves the execution date to the last day of the month in case a particular month doesn't have an equivalent day.

For example, if a payment's first_execution_date is 2021-06-30 and the standing order is set to execute at the end of the month, then the standing order will always execute on the last day of the month (e.g., February 28 or 29).

Decline reasons

A standing order can be declined for a number of reasons. Subscribe to the SEPA_SCHEDULED_TRANSACTION to receive notifications whenever a standing order is declined. The webhook payload will include the decline reason in the decline_reason property.

Examples of decline reasons

• Target account [account_number] is blocked, transactions can't be performed.
• Source account [account_number] is blocked, transactions can't be performed.
• There were insufficient funds to complete this action.
• Target account [account_number] is closed, transactions can't be performed.
• Source account [account_number] is closed, transactions can't be performed.

Prerequisites

You must implement the following features in order to use standing orders in your solution:

• Device binding
• Strong Customer Authentication
• SEPA Credit Transfers

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.

• SEPASCHEDULEDTRANSACTION
• SEPASTANDINGORDER

API reference documentation

To implement standing orders, integrate the following endpoints in your solution:

• POST Create a standing order
• GET Retrieve a standing order
• GET Retrieve all standing orders
• GET Index SEPA Credit Transfers for a standing order
• PATCH Update a standing order
• PATCH Cancel a standing order

How to create a standing order

POST Create a standing order

To create a standing order, call the following endpoint and provide the following properties in the request body:

• reference: A unique reference for the transaction.
• first_execution_date: The date when the first payment iteration should be executed. Future iterations will be executed on the same day at the specified interval.
• amount: The transaction amount in Euro, cents.
• reoccurrence: The frequency at which to execute the standing order.

Additional optional parameters:

• month_end_execution: Indicates whether a transaction execution should be moved to the last day of the relevant month.
• last_execution_date: Sets a date after which the standing order becomes inactive.

Request URL

POST /persons/{person_id}/accounts/{account_id}/standing_orders

Response example (before transaction authorization)

Calling the previous endpoint triggers the change request process and your customer must authorize the transaction using either an SMS OTP or a device signing challenge.

{
  "id": "d6c778822b2d7bd3b778935bcfd0d1d3csc",
  "status": "CONFIRMATION_REQUIRED",
  "updated_at": "2022-04-21T13:59:52+00:00",
  "url": "https://example.com/authorize"
}

Response example (after transaction authorization)

After the customer successfully authorizes the transaction, the payload will include the details of the standing order, such as the standing order's unique id, status, etc.

{
  "id": "f874b3102718a4d757a6b6e4d599607ccsto",
  "status": "ACTIVE",
  "booking_type": "SEPA_CREDIT_TRANSFER",
  "transaction_type": "SEPA_CREDIT_TRANSFER",
  "recipient_iban": "DE87110101001000057123",
  "recipient_name": "Hans Mustermann",
  "recipient_bic": "COBADEFFXXX",
  "reference": "dsf2r3raedfs3fsf342fctrx",
  "amount": {
    "value": 1000,
    "unit": "cents",
    "currency": "EUR"
  },
  "description": "string",
  "first_execution_date": "2021-09-01",
  "last_execution_date": "2025-09-01",
  "reoccurrence": "MONTHLY",
  "end_to_end_id": "END2ENDREJ",
  "month_end_execution": true,
  "next_occurrence": "2021-10-01"
}