SEPA Direct Debit (SDD)

This page contains all the relevant information about SEPA Direct Debit (SDD) transfers, including key concepts and the necessary endpoints you need to integrate in your solution.

What is SEPA Direct Debit?

SEPA Direct Debit (SDD) is a pull-based payment scheme that allows a creditor to debit a debtor's bank account. Similarly to other SEPA transfers, an SDD requires the IBAN (and occasionally the BIC) of both the sender and the recipient's bank accounts. However, it differs from other SEPA transfers in that the roles are reversed: the recipient of the funds is the one who must request the money transfer from the sender.

SEPA Direct Debit is only available in Euros and can be used for both one-off transactions and recurring payments. It is often used for recurrent payments so that customers can avoid missing payments and being charged additional fees.

The debtor must sign a valid SDD mandate to authorize the creditor to withdraw the money from the debtor's account. Additionally, there are other rules governing SDDs, such as pre-notifications, refunds, returns, etc.

How does a SEPA Direct Debit work?

1. The creditor and the debtor must enter into a collection agreement.
2. The creditor must create an SDD mandate following the mandate rules, which the debtor must sign to authorize the creditor to withdraw the SDD amount from their account.
   • For B2B SDDs, the mandate must be shared with the debtor's bank.
3. The creditor must send a notification to the debtor at least one business day before the debit date.
4. On the debit date, the creditor initiates the SDD collection from the debtor's account in the agreed upon amount.
5. Before executing an SDD, Solaris checks a variety of the transaction's attributes, such as transaction reference, mandate attributes, SDD limit, direct debit profile, and the status and type of the account.
6. Solaris executes the transaction, withdrawing the money from the debtor and crediting it to the creditor's account. This creates a booking on the sender's account with the booking type SEPA_DIRECT_DEBIT (for the B2B scheme) or DIRECT_DEBIT (for the Core scheme).

SDD mandate

An SDD mandate is a mandatory contract the customer (the debtor) must sign to authorize the creditor to initiate SDD collections from their account. An SDD mandate can be "one-off", valid for only a single collection, or "recurrent", which can be used until the debtor revokes the authorization.

The SDD mandate must contain the legal text, including the following mandatory information:

• A unique mandate reference number
• The name of the debtor
• The debtor's address
• The debtor IBAN
• The BIC of the debtor's bank account (optional)
• The creditor company name
• The creditor's identifier
• The creditor's address
• The type of payment
• Signature place and time
• Signature(s) of both parties

The mandate can be in a physical paper form or an electronic version, and the debtor must sign it with a qualified signature. After a mandate is created and signed, the creditor must send it to the debtor and must continue to store the mandate throughout the validity of the agreement. If the mandate expires or gets revoked by the customer, the creditor must continue to keep the mandate according to the national legal requirements for a minimum of the time a Direct Debit collection under this SDD mandate can be disputed.

SDD payment schemes

There are two payment schemes under SDD:

1. SEPA Direct Debit Core scheme: available to both businesses and retail customers.
2. SEPA Direct Debit Business to Business (B2B) scheme: available only to businesses.

The two schemes work almost in the same way, but there are several key differences:

1. Refunds

In the SDD Core scheme, customers can request refunds for authorized collections for up to 8 weeks after the date the amount was debited from their account (for unauthorized collections, up to 13 weeks). However, due to the typically high volume of transfers in the SDD B2B scheme, customers are not eligible to request refunds.

2. Transaction authorization

In the SDD B2B scheme, the bank typically performs additional verification steps for each transaction to check and validate the mandate before collecting any money.

3. Transaction pre-notification and processing

Core SDDs are usually processed within 2 business days, whereas B2B SDDs can take up to 3 business days to process.

Prerequisites

You must implement the following features before you can use SEPA Direct Debits in your solution:

• Device binding
• Strong Customer Authentication

API documentation

To implement Incoming SEPA Direct Debit transfers, integrate the following endpoints in your solution. The following links will take you to the API reference for SEPA Direct Debit transfers where you'll find information about the different API calls and its related properties and examples.

Click the links below to view the API references for SEPA Direct Debits:

• SEPA Direct Debit (endpoints for all customer types)
• SEPA Direct Debit Returns

Return notifications

Solaris will inform you about invalid SDD collections from your customers' accounts using return notifications. All of the following acceptance criteria in order for an SDD to be considered valid:

• The customer's account exists and is not closed,
• SDD is enabled for the customer's account,
• The customer's account is not blocked, and
• The customer's account has enough funds to cover the SDD.

If the account does not meet the above criteria, then Solaris will generate a return notification. It will include a return code (according to EPC guidelines) that explains why the SDD was rejected. Here are the most common return codes:

• AC04 : The debtor's account is closed.
• AC06 : The debtor's account is blocked.
• MD01 : The mandate is invalid for the collection.
• MS03 : Other reason (e.g., insufficient funds).

If an SDD fails for an account that is not blocked or closed, then the customer's account balance may be affected. For example, for an SDD of 15,00 EUR, the customer may see the attempt (-15,00) and then the failure (+15,00) in their account statement.

SEPA_DIRECT_DEBIT_RETURN webhook

Subscribe to the SEPA_DIRECT_DEBIT_RETURN webhook to receive notifications whenever Solaris rejects an SDD from one of your customer's accounts that does not meet the acceptance criteria.

API endpoints

Click here to view the full API reference for the SEPA Direct Debit return endpoints.

SDD refunds

Customer can request SDD refunds only in the context of CORE SDD. Please note that SDD refunds will be rejected in the following cases:

• The account is blocked for any reason
• The direct debit was already returned
• It's not a Core SDD (e.g., B2B cannot be returned)
• The amount is positive
• valuta_date is older than 56 days
  • Older SDDs can only be refunded by contacting the customer support up to 13 months from the valuta date.

Call the following endpoint to issue SDD refunds to your customers.

Request URL

POST /v1/persons/{person_id}/accounts/{account_id}/sepa_direct_debit_returns

Click here to view the full API reference.

SDD notifications

The SEPA schemes allow creditor banks to issue pre-notifications of incoming SDDs between 14 days and up to 1 day before the execution date of the transaction. You can send your customers SDD notifications before the execution date of a scheduled SDD to give them the chance to top up their account to ensure there is enough balance and avoid SDD returns.

GET Fetch pending SDDs for an account

Call this endpoint to retrieve all scheduled pending SDDs for an account and use the information to produce notifications to your customers on your banking app.

Note: Please note that this endpoint will only return SDD transactions that are pending, i.e., have not been executed yet. Once an SDD is executed, it will be returned as a standard booking.

Request URL

GET /v1/accounts/{account_id}/incoming_sepa_direct_debits/scheduled

Click here to view the full API reference.

SEPA_DIRECT_DEBIT_TRANSACTION_SCHEDULED

You can subscribe to this webhook event and receive notifications whenever an SDD transaction is scheduled for an account.

Click here to view the full API reference.