The SEPA direct debit is a payment method in euros. The payment order can only be expressed in euros. However, the clients’ accounts can be held in another currency. In this case, the client’s bank carries out the conversion, which takes place outside of the SEPA direct debit transaction itself.

The permission that your client has given you for issuing direct debit orders and submitting them for account debiting is formalised by the signature of SEPA direct debit mandates. The direct debit is based on a clear contract concluded between you and your clients, evidenced by explicit consent: the mandate.

The SEPA direct debit mandate materialises a client's consent to his merchant. SPS assigns a Unique Mandate Reference (UMR) to each mandate (see parts "Setting the payment request" of the connector Paypage or Office (M2M)). You can also assign the UMR by yourself. In that case, you must ensure their uniqueness. Changes may occur to the mandate during its life cycle (changes to the client’s account number, etc.). Therefore, you will need an up-to-date mandate.

The electronic validation of SEPA direct debit mandates is used during an online mandate creation by the client or an electronic mandate creation in Mercanet Back Office or in Office (M2M) by you.

The electronic validation uses an “Organisation” type certificate in your name, that guarantees document integrity, enables time stamping and provides proof sealing of actions that led to the mandate validation.

In order to obtain this certificate, your legal representative must sign a subscription contract.

The electronic validation is compatible with the European standard ETSI 102-042 (European Telecommunications Standards Institution).

A SEPA direct debit can lead to the contestation of a non-authorised transaction, but in the event of legal action, it is the existence of the consent to the main contract (binding the merchant and the client - e.g. subscription contract) that will be primarily considered. The mandate validation may take place through two payment processes:

• validation through a code entry received by email.
• validation through a code entry received by text message.

Choosing the right solution lies between the risk to be covered, the payment guarantee and the process ergonomics.

You have to specify your choice when sending the mandate creation request.

Unlike card payments, a submission deadline is to be observed before interbank exchanges.

Thus, for a payment/maturity date, the direct debit must be presented in compensation at D-1 of BBD (Banking Business Day) at the latest.

Depending on your banking institution the files are:

• transmitted by SPS
• transmitted by yourself

Please contact your banking institution to find out how it works.

You are bound to supply the debtor with a notification at least 14 calendar days, prior to the direct debit maturity date.

During the payment kinematics, it is possible that we don't receive the expected return (timeout), the status of the transaction can be one of the followings.

• TO_CONFIRM_AUTHOR
• TO_CONFIRM_CAPTURE
• TO_CONFIRM_CREDIT

A batch processing is carried out daily to update these transactions to final statuses:

• REFUSED
• TO_CAPTURE/TO_VALIDATE
• CAPTURED
• TO_CREDIT

The diagram of the Making an SDD payment paragraph illustrates these statuses as well as the transitions.

The final status will appear in your transaction report to allow you to continue processing the order.

As part of the SDD acceptance you need to:

• Check of the client identity.
• Pre-fill the mandate creation page and thus promote the SDD type of transaction processing.

The Unique Mandate Reference (UMR) can be sent in the payment request. If the UMR is not sent, then the reference is automatically generated.

Warning: in case you choose to send the UMR, you are responsible for the UMR unicity. In case of duplicated UMR, the mandate signature will be refused and the customer will not have the possibility to pay.

Below is a list of settings enabling the transfer of the cardholder’s personal information.

(*) You must necessarily fill in the 5 fields: city, country, street, streetNumber and zipCode, so that the address is taken into account and pre-filled on the mandate entry page.

The following table summarises the different response cases to be processed:

For the complete response codes (responseCode) and acquirer response codes (acquirerResponseCode), please refer to the Data dictionary.

The SEPA mandate initialisation is performed by calling the initializeMandate method.

The customer must be redirected to the URL provided in initializeMandate response. The redirection is done by calling the HTTP POST method to the redirectionUrl received with parameters messageVersion and redirectionData.

At the end of the payment processes, the client is redirected to the URL provided in the initialisation request, merchantReturnUrl. The following fields are sent in POST and must be retrieved to finalise the payment:

Once the customer has signed his mandate on the SDD pages, he is redirected to the URL that was provided during the initializeMandate call in the field merchantReturnUrl.

The redirection to this URL is done by Mercanet by calling the HTTP POST method on that URL using the messageVersion and redirectionData settings. Those POST settings must be provided as inputs of the finalizeMandate method to complete the mandate creation process.

In order to have your customer sign an online mandate:

• either you use the Paypage connector. Please follow instructions in chapter Making an SDD payment with Paypage
• or you use the Office (M2M) connector. Please follow instructions in chapter Making a payment with Office (M2M)
  • initialise the mandate using the initializeMandate method
  • redirect the customer to the mandate signature pages
  • finalise the mandate creation using the finalizeMandate method

Whatever connector you choose, the paymentMeanData.sdd.mandateUsage has to be populated with RECURRENT. You must keep the value of the mandateId field, to resubmit this value during recurring direct debit requests.

In order to trigger your customer’s direct debit:

• either you use the Office (M2M) connector. Please follow instructions in chapter Making an SDD payment with Office (M2M):
  • charge your customer from the mandate number, using the directDebitOrder method
  • charge your customer from the transaction reference (created when signing the mandate), using the duplicate method
• or you use the Office Batch connector:
  • charge your customer from the mandate number, using the directDebitOrder method
  • or charge your customer from the transaction reference (created when signing the mandate), using the duplicate method

A example of a searchMandate request is available on this page.

Returned mandate data (mandateList):

A example of a searchMandate response is available on this page.

A example of a getPdfMandate request is available on this page.

A example of a getPdfMandate response is available on this page.

The example below is coded in JAVA and can be used to build an HTTP response to offer customers to download a PDF file from the received mandatePdf field:

byte[] decodedBytes = Base64.decodeBase64(%MANDATE_PDF_RECEIVED%).getBytes("UTF-8"));
response.setContentType("application/pdf");
response.setHeader("Content-disposition", "attachment; filename=MandatePDFFile.pdf");

try (final ByteArrayInputStream in = new ByteArrayInputStream(decodedBytes);
final OutputStream out = response.getOutputStream()) {
final byte[] buffer = new byte[4096];
int length;
while ((length = in.read(buffer)) > 0) {
out.write(buffer, 0, length);
}
}

A example of a getMandateData request is available on this page.

Data related to the mandate and the client:

Returned debit data (mandateList):

A example of a getMandateData response is available on this page.