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.

👍

Xpollens provides a complete solution to create mandates and manage Sepa Direct Debit (SDD). If you already have a Sepa Creditor ID (SCI), you will be able to use it to direct debit your customer. If not, we can provide you with one within 48 hours.

General sequence diagram

sequenceDiagram
Title: Create an SDD Out (Core & B2B)
autoNumber
Actor User
Participant Partner
Participant XPO

Note over Partner, XPO: Create a beneficiary
Partner ->> XPO : POST api/sca/v2.0/users/appUserId/beneficiary
XPO ->> Partner : http 20X 

Note over Partner, XPO: Create a mandate
Partner ->> XPO : POST /api/v2.0/accounts/accountId/mandates {beneficiaryId]
XPO ->> Partner : http 20X
XPO -->> Partner: webhook MandateCreatedOrUpdated

Partner -->> User: Sign the mandate
User -->> Partner: Signature


Note over Partner, XPO: Activate the mandate
Partner ->> XPO : POST /api/v2.0/accounts/accountId/mandates/{mandateId}/activate
XPO ->> Partner : http 20X
XPO -->> Partner: webhook MandateCreatedOrUpdated


Note over Partner, XPO: Create an SDD OUT
Partner ->> XPO : POST /api/v2.0/sepa-direct-debits
XPO ->> Partner : http 20X
XPO -->> Partner: webhook SepaDirectDebitCreatedOrUpdated (status: Created)
XPO -->> Partner: webhook SepaDirectDebitCreatedOrUpdated (status: Approved)

Note over Partner, XPO: Completion of the SDD on the settlement date
XPO -->> Partner: webhook SepaDirectDebitCreatedOrUpdated (status: Completed)

---

Mandate

The mandate creation is a prerequesite to create an SDD (see "State diagram for an SDD OUT").

State diagram for a debtor mandate (Core & B2B)

stateDiagram
    [*] --> Created : when created
    Created --> Activated: when activated
		Created --> Revoked : when revoked
    Activated --> Revoked : when revoked
    Revoked --> [*]

❗️

Xpollens does not create a document for the mandate.

If you want to display a document to your customers, you must create it.

---

Mandate creation

The prerequesite to create a mandate is to create the beneficiary.

sequenceDiagram
Title: Create a mandate (Core & B2B)
autoNumber
Actor User
Participant Partner
Participant XPO

Note over Partner, XPO: Create a beneficiary
Partner ->> XPO : POST api/sca/v2.0/users/appUserId/beneficiary
XPO ->> Partner : http 20X

Note over Partner, XPO: Create a mandate
Partner ->> XPO : POST /api/v2.0/accounts/{accountId}/mandates {beneficiaryId, type}
XPO ->> Partner : http 20X {mandateId}
XPO -->> Partner: webhook MandatedCreatedOrUpdated

To use this mandate and create and SDD, the mandate must be activated.

---

Mandate activation

sequenceDiagram
Title: Activate the mandate
autoNumber
Actor User
Participant Partner
Participant XPO

Note over Partner, XPO: Create a mandate

Partner -->> User: Sign the mandate
User -->> Partner: Signature

Note over Partner, XPO: Activate the mandate
Partner ->> XPO : POST /api/v2.0/accounts/{accountId}/mandates/{mandateId}/activate
XPO ->> Partner : http 20X

---

Mandate revocation

Why and when

The mandate can not be modified. As a consequence, if a modification is needed, you must :

• revoke the mandate
• create a new one

Impacts

❗️

The revocation of the mandate does not cancel already scheduled SDDs.

---

What happens if the end user revokes the mandate from their external bank?

❗️

Xpollens is not aware that all SDDs have been opposed and that the mandate has been revoked.

However, we receive rejections for all direct debit attempts.

---

Sepa Direct Debit OUT (SDD OUT)

An SDD out is an SDD that debits an external account to credit the Xpollens account.

State diagram for an SDD OUT

stateDiagram-v2
    [*] --> Created  : internal status
    Created --> Approved : http 201
    Created --> Rejected:  rejected by The Payment Decision System
    Approved --> Rejected : /- rejected by BPCE <br/> /- rejected by the Interbank_market <br/> /- rejected by the external bank
        Approved --> Completed : accepted
		Rejected --> [*]
    Completed --> [*]

---

Sequence diagram for an SDD OUT

sequenceDiagram
Title: Create an SDD
autoNumber
Actor User
Participant Partner
Participant XPO
Participant BPCE
Participant Interbank_market

Note over Partner, XPO: Create an SDD OUT
Partner ->> XPO : POST /api/v2.0/sepa-direct-debits
XPO ->> BPCE: create SDD
XPO -->> Partner: webhook SepaDirectDebitCreatedOrUpdated {status Approved}


Note over XPO, Interbank_market: Every working day 21h (FR)
BPCE -->> XPO : SDDs sent {executionDate}
XPO -->> Interbank_market: SDD sent

Note over Partner, Interbank_market: On the executionDate
XPO -->> Partner:  webhook SepaDirectDebitCreatedOrUpdated {status Completed}

expectedExecutionDate

The expectedExecutionDate is the payment date expected by the partner (or its enduser) and entered in the request POST.
When the SDD creation on the SEPA exchange plateform, the expected execution date is recalculated. The value (new or not) is integrated in our system, and returns by the GET sdd. As a consequence, this date can evolve.

The expectedExecutionDate changes if the expectedExecutionDate is a day during a week-end or a day off. In this case, the expectedExecutionDate is the next working day.

🚧

Note: the expectedExecutionDate can not be in the past.

An SDD can only be created a maximum of 14 days before the expectedExecutionDate.
Therefore, you need to manage the debit schedule on your side to create the SDDs in a timely manner.

Rules

❗️

To schedule multiple SDDs in parallel for the same mandate, the first SDD must be finalized.

This occurs as soon as its status changes to "Completed".

SDD Core vs. SDD B2B

1- The characteristic is defined during the mandate creation, through the type = Core or B2B
2- This information is replicated during the SDD creation, same attribute type

Rules are different according to the sdd type:

---

API & technical items

Error for a mandate creation

POST /api/v2.0/users/appuserId/mandates

---

Error for a mandate activation

POST api/v2.0/accounts/accountId/mandates/mandateId/activate

---

Error for a SDD OUT creation

POST /api/v2.0/sepa-direct-debits

---

Error for a get sdd

GET /v2.0/sepa-direct-debits/sepaDirectDebitId

---

R-transactions

Some direct debit transactions require exception handling, because one of the parties involved does not or cannot process the collection in the
normal way. This exception handling involves the sending of messages called R-transactions because their names all start with an R: Refusals,
Rejects, Returns, Refunds, Reversals. The definitions of the various SDD R-transactions are outlined this document :

🔗https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf

General scheme

sequenceDiagram
Participant Before
Participant D-14
Participant D-1 bank business day
Participant D Payment Date
Participant D5 bank business day
Participant D8 weeks
Participant D13 months

Before -->> D-1 bank business day: Revocation by creditor
D-14 -->> D Payment Date: Request for cancellation from creditor's bank
D-14 -->> D Payment Date: Reject from the debitor's bank
D-14 -->> D Payment Date: Refusal from the debitor's bank

D Payment Date -->> D5 bank business day : Reversal by Creditor
D Payment Date -->> D5 bank business day : Return
D Payment Date -->> D8 weeks : Request for refund
D8 weeks -->> D13 months : Request for refund for <br/>an unauthorized transaction

• Reject example: account closed
• Refusal by debtor example: the user debited by the SDD OUT refused
• Reversal by creditor example: external bank debit error.
• Return example: insufficient balance

---

General sequence diagram

👍

In the case of a reject or a refusal the day or after the paymentDate, a new operation is created: this operation is named R-transaction.

Each of these two operations has an independent status diagram, but the R-transaction is linked to the original operation through the field refundReference.

Case refund after the payment date

sequenceDiagram
Title: R-transaction for a completed SDD OUT
autoNumber
Participant Partner
Participant XPO
Participant External_bank


Partner -->> XPO : SDD OUT
XPO -->> External_bank: SDD OUT
XPO -->> Partner: Webhook SepaDirectDebitCreatedOrUpdate {sepaDirectDebitId: X status 'Completed'}

Note over Partner, External_bank : Refund
External_bank -->> XPO: R-transaction refund
XPO -->> Partner: SepaDirectDebitCreatedOrUpdate {isRTransaction:true, status:'Completed', relatedSepaDirectDebitId:X}

The initial operation:

• has a status Completed
• has the refund reference in the attribute relatedSepaDirectDebitId

The refund operation

• isRTransaction
• has a status Completed
• has the reference of the initial operation in the attribute relatedSepaDirectDebitId

Case reject or refusal before the payment date

sequenceDiagram
Title: R-transaction for a rejected SDD OUT
autoNumber
Participant Partner
Participant XPO
Participant ESP

Note over Partner, ESP : X days before payment date
Partner -->> XPO : SDD OUT
XPO -->> ESP: SDD OUT
ESP -->> XPO: ok
XPO -->> Partner: Webhook SepaDirectDebitCreatedOrUpdate {sepaDirectDebitId:X, status 'Approved'}

Note over Partner, ESP : Rejected
ESP -->> XPO: Reject
XPO -->> Partner: SepaDirectDebitCreatedOrUpdate {sepaDirectDebitId:X, status 'Rejected'}

ESP = Sepa Exchanger

---

sepaRejectCode & sepaRejectReason

These attributes are visible in the webhook SepaDirectDebitCreatedOrUpdate.

They are filled when the SDD is refused and a R-transaction

Please referee to this link, page 5, to find all code, definition and associated use cases.

🔗https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf

---