WL SIPS DOCS

Release 21.5

go directly to content
Search by keywords

SDD integration

To search in the page use Ctrl+F on your keyboard

WL Sips is a secure multi-channel e-commerce payment solution that complies with the PCI DSS standard. It allows you to accept and manage payment transactions by taking into account business rules related to your activity (payment upon shipping, deferred payment, recurring payment, payment in instalments, etc.).

The purpose of this document is to explain the SDD means of payment integration into WL Sips.

This document is intended to help you implement the SDD means of payment on your e-commerce site.

It includes:

  • functional information for you
  • implementation instructions for your technical team

To get an overview of the WL Sips solution, we advise you to consult the following documents:

  • Functional presentation
  • Functionality set-up guide

The SDD (SEPA Direct Debit) is a direct debit mean of payment used by debtors and creditors in the SEPA zone.

The drect debit is a payment initiated by the creditor (the merchant), previously authorised by the debtor (the customer) through a mandate. This mean of payment can be used for recurring or one-time payments.

Attention: the terms and conditions applicable to the SEPA direct debit described below are not exhaustive and do not replace the SEPA regulations available in the latest versions of the Rulebooks.Your bank must inform you of the rules regulating the SEPA Direct Debit operation.
Payment channels
Internet V Default payment channel
MAIL_ORDER, TELEPHONE_ORDER V
Fax X
IVS X
Means of payment
Immediate payment X
End-of-day payment V
Deferred payment V
Payment upon shipping V
Payment in instalments V
Subscription payment V
Batch payment V
OneClick payment V
Currency management
Multicurrency acceptance X EUR only
Currency settlement X EUR only

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 Sips Paypage or Sips Office). 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 SEPA direct debit is available in two schemes:

  • The SEPA CORE direct debit available to all types of clients. Two sub-types are available in WL Sips:
    • Core (BToC). This scheme applies to all payers, individuals or companies.
    • Business (BToF): for associations which have or do not have a registration number (ex: a SIRET number in France). This sub-type has been created to allow sending additional data, but it is still subject to the same rules as the standard Core type.
  • The SEPA BToB direct debit exclusively for payments between companies, professionals and associations, and which has specific management rules. It is prohibited for a creditor to debit an individual with a BtoB SDD. The debtor's bank has the obligation to ensure the validity of the BtoB mandate with its client before being able to initiate payments by SDD. The debtor must therefore send a copy of the SDD BtoB mandate to his bank upon signature so that it can record the characteristics of the mandate in its information system. If the debtor's bank is not informed of the signed mandate, the direct debit will be automatically rejected. The debtor also undertakes to inform his bank of any modification or deletion of mandate. The debtor cannot contest a BtoB SDD once he has been regularly paid (i.e. existence of a mandate), it is therefore not possible to ask his bank to refund a BtoB direct debit

The SEPA direct debit can be used for recurring or one-time payments:

  • recurring mandate: the mandate is valid for a series of direct debits. It is revocable at any time by the creditor or the debtor and becomes obsolete if not used for a period of 36 months.
  • one–time mandate: the mandate is valid only for a single direct debit and expires automatically.

The SEPA direct debit order amount must be between 0.01 and 999,999,999.99 euros.

The SEPA platform is also connected to the SafeDebit solution, proposed by the Score & Secure Payment (SSP) society, and which allows to deliver a payment guarantee for the unpaid SEPA payments.

To benefit from this guarantee, you must have a SafeDebit contract with SSP and obtain a beneficiary number to communicate to us during your subscription to this functionality.

The Score Score & Secure Payment (SSP) company proposes a solution allowing the guarantee of payments done by SEPA transfer. On the basis of fraud scoring, this independent company offers to guarantee SEPA direct debits on your merchant websites. WL Sips is connected to the SSP SafeDebit offer through SPS.

If you subscribe to the SafeDebit offer, you will benefit from this solution. You will need to follow the procedure described in the chapter "Signing your SDD acceptance contract". The SEPA debits will be guaranteed by SSP (and thus you can be compensated by SSP in case of unpaid).

There is currently an additional option associated with SafeDebit. It's the risk taking.

Activate the guarantee on the mandate and the SEPA debits allows to make a certain number of verification of the data (detection of false IBAN, type of account, digital identity, ...) and to refuse the creation of mandates and SEPA debits if the guarantee payment can not be applied. In order for SEPA direct debits or mandates not to be rejected, although not guaranteed by SSP, you have the option to opt for the option "risk taking". In this case you lose the payment guarantee. You will not be able to claim compensation for any outstanding payments.

This option must be indicated when registering or via your usual contacts for the option modification.

Note: since this is an option to set up at the shop level, risk taking applies to all mandate creations or SEPA direct debits. You can not choose to take a risk dynamically depending on the context of the payment.

Modification of a mandate is not allowed if guaranteed SEPA direct debits have been created on this mandate and are not finalized.

Indeed, the guarantee of a payment is based on the information of a mandate and could be revised in case of modification of the 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 Sips Office Extranet or in Sips Office 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.

Validation through code entry

Clients validate their direct debit mandate by entering a code received:

  • by text message to a known telephone number of the merchant
  • or by email to a known email address of the merchant
  • You must be able to transmit the customer details: title, surname, first name for an individual customer; company name, last name and first name of the legal representative for a business customer.
  • You must have the customer's phone number or e-mail address: the client can neither enter or modify his email address or phone number during the session used to validate the mandate.
  • When the customer clicks on the SEPA Direct Debit logo, the server verifies if the they already have a direct debit mandate (OneClick option).
  • If the customer has no mandate, they are advised to validate their direct debit mandate online.
  • You have to transmit details related to the customer (identification and contact details), and the customer cannot modify these details during the mandate creation.
  • The customer validates their information, provides their bank details (IBAN) and confirms that the pre-filled mandate contains the correct information.
    code-entry-creation-step1-en

  • The customer receives a code on their mobile phone or e-mail address to be re-entered on the page in order to confirm their mandate.
    code-entry-signature-step2-en

  • If you click on DOWNLOAD MANDATE, You can check the information inside your mandate:
    code-entry-mandatestep-en

  • The customer receives confirmation that his mandate has been successfully registered. He can download the mandate in PDF format or print it. The total of his purchase or of the next instalment will be deducted from his bank account.
    code-entry-summary-step3-en

  • You will have a message of Transaction Information:
    code-email-payment-confirmation-en

  • The next direct debit date is indicated on the summary ticket.
Note: you have to decide if you want to send the code by e-mail or by telephone. This information is transmitted in the request.
The customer cannot modify the details which is used to send the code (e-mail address or phone number) in the mandate creating process. If the latter is not correct, the customer must contact you in order to modify the details in your information system.

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.

In order to issue SEPA direct debits, you must first:

  • Sign a service contract with the bank (i.e. an agreement to issue SEPA direct debits).
  • Have a SEPA Creditor Identifier (SCI) issued by the Banque de France (for France).
  • Sign a service contract with Score & Secure Payment (SSP) in order to obtain and give us the beneficiary number if you wish to subscribe to the SafeDebit payment guarantee solution.

Some operations are not available on all the interfaces. Here is a table summarizing the actions available in each interface:

Actions/Interfaces Sips Paypage Sips Office Sips Office Extranet Sips Office Batch
Creation of a mandate and payment Yes Yes Yes Non
Making a payment from an already existing mandate Yes if the mandate has been enrolled in OneClick mode when it was created Yes: directDebitOrder function Yes Yes: directDebitOrder function
Cash management on debit orders No Yes Yes Yes
Searching a mandate No Yes: searchMandate function Yes No
Retrieving a signed pdf mandate No Yes: getPdfMandate function Yes No
Retrieving/viewing a mandate No Yes: getMandateData function Yes (search a mandate and open it in the interface) No

WL Sips offers you three solutions to integrate the SDD mean of payment:

  • Sips Paypage which directly acts as the payment interface with customers via their web browser.
  • Sips Office which gives you the opportunity to display your payment pages and works through a server-to-server dialog.
  • Sips Office Batch which allows you to process batch payments.

The remittance modes available for an SDD transaction are:

  • Cancellation mode: default mode allowing transaction remittance on a predefined date, called capture delay. When this capture delay is reached, the remittance is sent automatically. This delay is set via the captureDay field with its 0 default value (end-of-day payment).
  • Validation mode: you must validate the transaction to trigger the remittance. A capture delay must also be defined. When this capture delay is reached or exceeded, you will not be able to validate the transaction, which will therefore expire automatically.

The diagram below explains the different transaction statuses according to the chosen capture mode:


ProcessPayment-SDD-EN

Note: you can revoke a mandate via the Sips Office Extranet interface. All transactions created with this mandate but not already remitted are aborted. The final status for those transactions is ABORTED.

The payment process for Sips Paypage is described below:


ProcessPaypage-SDD-EN

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.

Field name Remarks/rules
customerContact.email

Mandatory if authentication method is EMAIL_OTP.

Mandatory with SafeDebit option

customerContact.firstname Mandatory
customerContact.gender Optional
customerContact.lastname Mandatory
customerContact.mobile

Mandatory if the authentication method is SMS_OTP. The expected format will include the area code (+33, etc).

Mandatory with SafeDebit option

customerContact.legalId Optional, only used with a BTOF transactionActors mandate.
customerContact.​positionOccupied Optional, only used with a BTOF transactionActors mandate.
customerAddress.city (*) Optional

If not valued, the customer will have to enter this information on the mandate entry page.

customerAddress.country (*) Optional

If not valued, the customer will have to enter this information on the mandate entry page.

customerAddress.street (*) Optional

If not valued, the customer will have to enter this information on the mandate entry page.

customerAddress.streetNumber (*) Optional

If not valued, the customer will have to enter this information on the mandate entry page.

customerAddress.zipCode (*) Optional

If not valued, the customer will have to enter this information on the mandate entry page.

customerAddress.company Mandatory if the transactionActors field is filed with BTOF.
customerAddress.​businessName Optional, only used if the transactionActors field is filled with BTOF.
customerLanguage Allows to choose the language used on WL Sips and SDD pages.
mandateId Optional. If not filled in, the mandate unique reference is generated by SPS. WARNING: It is the merchant's responsibility to guarantee its uniqueness if he provides it.
customerId Optional

must be provided to use the searchMandate function

paymentMeanData.sdd.​mandateAuthentMethod Optional

restricted values : MAIL_OTP, SMS_OTP

if not filled, default value is MAIL_OTP

paymentMeanData.sdd.​mandateUsage Optional

restricted values : ONE_OFF, RECURRENT

if not filled, default value is RECURRENT

statementReference Optional

Available for some acquirer

transactionActors Optional

restricted values : BTOC ou BTOF

if not filled, default value is BTOC

(*) 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:

Status Response fields Action to take
Payment accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
captureDay = with AUTHOR_CAPTURE mode, the value is corrected by SPS according to the submission rules chosen by the acquirer (captureDay = captureLimitDate - today's date).
With VALIDATION mode, the value remains the same as for the request.
captureLimitDate = the submission date is returned in the response in AUTHOR_CAPTURE mode only. In VALIDATION mode, the direct debit submission date is returned during the validation of the SDD transaction.
customerBusinessName = the company name set in input or sent by SPS.
customerLegalId = the company registration number set in input or sent by SPS.
customerPositionOccupied = the legal identifier set in input or sent by SPS.
maskedPan = BIC.IBAN hidden format rules:
Example:
AXABFRPP314.FR76 ######################44
BIC: shown; IBAN: only the first 4 and last 2 digits shown.
mandateId = UMR to be retained by you.
mandateUsage = ONE_OFF or RECURRENT
paymentMeanBrand = SEPA_DIRECT_DEBIT
paymentMeanType = DIRECT_DEBIT
secureReference = transaction warranty proof as part of the SafeDebit option.
This proof will be transmitted to SSP for any claim for compensation.
transactionActors = BTOB, BTOF ou BTOC
You can deliver the order.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary). The authorisation is refused for a reason unrelated to fraud.
If you have not opted for the "new payment attempt" option (please read the Functionality set-up Guide for more details), you can suggest that your customer pay with another means of payment by generating a new request.
Refusal due to the number of attempts reached responseCode = 75 The customer has made several attempts that have all failed.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

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

The payment process for Sips Office is described below:


ProcessOffice-SDD-EN

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

You must populate the following specific fields in the initialisation request for an SDD mandate creation:

Field name Remarks/rules
iban Mandatory
French IBAN are composed of 27 digits
mandateId Optional (set by SPS if not provided).
merchantReturnUrl Mandatory
transactionActors

Optional

Possible values = BTOC, BTOB, BTOF

If not filled, default value is BTOC

customerId Optional

must be provided to use the searchMandate function

customerLanguage Allows to choose the language used on WL Sips and SDD pages.
statementReference Optional

Available for some acquirer

customerContact.email

Mandatory if authentication method by MAIL_OTP

Mandatory with SafeDebit option

customerContact.firstname Mandatory
customerContact.gender Optional
customerContact.lastname Mandatory
customerContact.mobile

Mandatory if the authentication method is SMS_OTP. The expected format will include the area code (+33, etc).

Mandatory with SafeDebit option

customerContact.legalId Mandatory if transactionActors is BTOB

Optional if transactionActors is BTOF

Don't fill if transactionActors is BTOC

customerContact.positionOccupied

Optional if transactionActors is BTOB or BTOF

Don't fill if transactionActors is BTOC

customerAddress.city Mandatory
customerAddress.country Mandatory
customerAddress.street Mandatory
customerAddress.streetNumber Mandatory
customerAddress.zipCode Mandatory
customerAddress.company

Mandatory if the transactionActors field is filled in with BTOB or BTOF.

Don't fill if transactionActors is BTOC

customerAddress.businessName

Mandatory if the transactionActors field is filled in with BTOB or BTOF.

Don't fill if transactionActors is BTOC

Note: it is recommended to value the customerId field if you wish to look for all the mandates of a client (searchMandate).

Request example: initializeMandate via Sips Office JSON

{
    "customerAddress":
    {
      "city":"PARIS",
     "country":"FRA",
     "street":"Rue de la Bastille",
     "streetNumber":"19",
     "zipCode":"75000"
   },
"customerContact":
{
    "email":"julie.dupont@mail.com",
    "firstname":"Julie",
    "gender":"F",
    "lastname":"DUPONT"
},
"customerId":"JAU001"
"iban":"FR7617906001120227366700148",
"interfaceVersion":"MR_WS_2.19",
"keyVersion":"1",
"merchantId":"210011990011607",
"merchantReturnUrl":"https://merchantReturnUrl.com",
"paymentMeanAlias":"SEPA_DIRECT_DEBIT",
"paymentMeanData":
{
    "sdd":
{
    "mandateAuthentMethod":"MAIL_OTP"
}
},
"transactionActors":"BTOC",
"seal":"12682c81e701f171b9f33061846c60dcade2afb73eb064027fbb88cc6068382e"
}

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

Status Response fields Action to take
Mandate creation initialisation accepted acquirerResponseCode = 00
messageVersion = message version retrieved in response to the payment initialisation.
mandateId = mandate number (identical to the one in the request if provided, otherwise generated by SPS).
mandateResponseCode = server response code.
redirectionData = redirection data retrieved in response to the payment initialisation.
redirectionUrl = redirection URL to the SDD website.
Redirect the customer to redirectionUrl.
Mandate creation initialisation rejected
responseCode = <> 00
See the field errorFieldName, then fix the request.
If the problem persists, contact the technical support.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary). The authorisation is refused for a reason unrelated to fraud, you can suggest that your customer pay with another means of payment by generating a new request.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

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

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:

Field name Remarks/rules
responseCode Process response code
redirectionData Redirection data retrieved in response to the payment initialisation.
messageVersion Message version retrieved in response to the payment initialisation.
amount Transaction amount in cents
merchantId Shop identifier
transactionReference Transaction reference
transactionId Transaction identifier
transactionDate Transaction date

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 WL Sips 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.

You have to populate the following specific fields in the finalisation request for an SDD payment.

Field name Remarks/Rules
redirectionData Redirection data retrieved after the customer returns to your website (cf. Redirecting the client to the SDD pages).
messageVersion Message version retrieved after the customer returns to your website (cf. Redirecting the client to the SDD pages).

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

Status Response fields Action to take
Payment accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
bic = bank Identifier Code (BIC).
iban = international Bank Account Number (IBAN). French IBAN have 27 digits.
mandateId = mandate number
mandateResponseCode = response code returned by WL Sips (indicates the overall result of the mandate creation).
paymentMeanBrand = SEPA_DIRECT_DEBIT
paymentMeanAlias = means of payment alias defined and used by the customer in his portfolio.
transactionActors = terms of mandate:
BTOC|BTOB|BTOF
You can deliver the order.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary). The authorisation is refused for a reason unrelated to fraud, you can suggest that your customer pay with another means of payment by generating a new request.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.
Note: the field mandateResponseCode must be read to find out if the mandate creation process was done successfully.

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

To create an SDD direct debit, use the directDebitOrder method and indicate the SDD payment type and the unique mandate reference in the request.

Note: this fonction is also available on Sips Office Batch.
Field name Remarks/rules
paymentMeanBrand Doit être valorisé avec SEPA_DIRECT_DEBIT.

Request example: directDebitOrder with Sips Office JSON

{
   "amount":"1000",
   "captureDay":"0",
   "captureMode":"AUTHOR_CAPTURE",
   "currencyCode":"978",
   "customerId":"customerId1",
   "customerIpAddress":"127.0.0.1",
   "interfaceVersion":"IR_WS_2.18",
   "keyVersion":"1",
   "mandateId":"000000000000000031",
   "merchantId":"210043956120001",
   "merchantTransactionDateTime":"2017-10-16T16:13:11.602+02:00",
   "orderChannel":"INTERNET",
   "paymentMeanBrand":"SEPA_DIRECT_DEBIT",
   "transactionOrigin":"SIPS-SIM",
   "transactionReference":"SIM20171016161311",
   "seal":"108458787fe9dfe063605b21f946c727aab94468683482da1a5e2eb7ac08a016"
}

In the case of SDD payments, the following specific fields are filled in.

Field name Remarks/Rules
maskedPan

Hidden format: BIC.IBAN as follows: AXABFRPP314.FR76 ######################44 BIC: shown; IBAN: the first 4 and last 2 digits shown The BIC can vary from 8 to 11 characters, the IBAN varies in each country and has a maximum length of 34 characters

transactionActors Possible values:
  • BTOB
  • BTOC
  • BTOF

This value comes from the mandate type.

mandateId UMR to be retained by merchant
captureLimitDate YYYYMMDD format

The submission date is returned in the response in AUTHOR_CAPTURE mode only. In VALIDATION mode, it's the current date plus captureDay that is returned, the real direct debit submission date is returned during the validation of the SDD transaction.

captureDay Value corrected by SPS according to the rules of submission chosen by the acquirer.

captureDay = captureLimitDate - today's date

authorisationId In VALIDATION mode, the “0” value is returned and the real value is returned during the SDD transaction validation.
secureReference

Proof of warranty of the transaction with SafeDebit option.

This reference will be transmitted to SSP for the compensation in case of chargebacks.

Response example: directDebitOrder via Sips Office JSON

{
   "authorisationId":"32100000010020171016",
   "acquirerResponseCode":"00",
   "complementaryCode":"00",
   "responseCode":"00",
   "transactionDateTime":"2017-10-16T16:14:06+02:00",
   "holderAuthentStatus":"NO_AUTHENT",
   "scoreProfile":"10_GONOGO_PRE_AUTHORISATION",
   "maskedPan":"SOGEFRPPXXX/FR7630003005050005001582616",
   "captureLimitDate":"20171018",
   "transactionActors":"BTOC",
   "mandateId":"000000000000000031",
   "valueDate":"20171018",
   "s10TransactionReference":
  {
      "s10TransactionId":"10",
      "s10TransactionIdDate":"20171016"
  },
   "transactionReference":"SIM20171016161311",
   "seal":"d87ab3c1fac4d3eb53cdf3fb02d31b9da7483cb72898b4c639eeb1b52ed5a708",
   "preAuthorisationProfile":"10_GONOGO_PRE_AUTHORISATION",
   "preAuthorisationProfileValue":"unknown",
   "captureDay":2,
   "captureMode":"AUTHOR_CAPTURE",
   "transactionPlatform":"PROD",
   "secureReference":"SF_16957"
}

SEPA direct debits are perfectly suited for recurring payments. Compared to recurring card payments, they do not have any constraint on the expiry of the means of payment, nor do they have any amount limit linked to the card authorisation limit. There are two ways of implementing SDD recurring payments:

  • “basic” recurring payment
  • subscription payment

Implementing recurring payments is done in two steps:

  • the debtor signs their mandate
  • you submit a direct debit request on each instalment

In order to have your customer sign an online mandate:

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 Sips Office connector. Please follow instructions in chapter Making an SDD payment with Sips Office:
    • 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 Sips 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

SDD payment using a subscriber ID is described in the subscription payment guide.

The following operations are available on SDD transactions:

Cash management
Cancellation V The SDD can be cancelled via Sips Office or Sips Office Extranet; no field specific to this mean of payment is to be sent.
The cancellation must take place before the bank deposit order and it is your responsibility to check that the deposit has not been implemented.
Validation V
During the validation of a SDD transaction, the submission date of the direct debit created during the validation of the SDD transaction is returned in the captureLimitDate field.
In accordance with SEPA regulations, it is your responsibility to present this date to the customer.
Refund V The SDD reimbursement with Sips Office or Sips Office Extranet generates a SCT. It is not possible to make multiple reimbursements on the same SDD.
An unlimited refund (higher than the original amount) is not authorised.
The potential chargebacks on refund appear in the chargebacks report.
Duplication V The SDD can be duplicated via Sips Office or Sips Office Extranet. No field specific to this mean of payment is to be sent.
In accordance with SEPA regulations, it is your responsibility to present to the customer the direct debit date created by duplication.
Recycling X
SDD transaction abandonment V The mandate revocation operation is available only with Sips Office Extranet. This operation induces the abandonment of all transactions planned and not already remitted without any other action required from your side.
Credit X

The diagram below informs you which cash management operation is available when a transaction is in a given state:


ProcessCashManagement-SDD-EN

The reports provided by WL Sips allow you to have a comprehensive and consolidated view of your transactions, cash operations, accounts and chargebacks. You can use this information to improve your information system.

The availability of SDD transactions for each type of report is summarised in the table below:

Reports availability
Transactions report V
Operations report V
Reconciliations report V
Chargebacks report V
Note: for SDD transactions, the paymentMeanBrand field is populated with the value SEPA_DIRECT_DEBIT.

The minimum reports versions for the SafeDebit option are :

  • Transaction Report : TAB20_V18
  • Operation Report : TAB20_V9

You can view your SDD transactions and perform various cash management operations with Sips Office Extranet.

Here are the details of an SDD transaction:


ScreenSOE-SDD-EN

Attention: the field Secure Reference is only valued if you have subscribed to the option SafeDebit and only if the SEPA direct debit is guaranteed.

The field Liability shift is valued at YES if the SEPA direct debit is guaranteed and at NO if it isn't. It remains empty if not applicable.

You can search for all the mandates of a given customer if the customer ID was provided during the mandate creation (when calling "initializeMandate" on Sips Office or when requesting payment on Sips Paypage).

Field name Remarks/rules
customerId

Request example: searchMandate via Sips Office JSON

{
    "customerId":"JAU001",
    "interfaceVersion":"MR_WS_2.19",
    "keyVersion":"1",
    "merchantId":"210011990011607",
    "seal":"c2e8ca69f2c10e71bed97d62d72d24458eed2f1610756f58ee9b5981f315c327"
}
Field name Remarks/rules
mandateResponseCode
mandateList

Returned mandate data (mandateList):

Field name Remarks/rules
bic
iban French IBAN are composed of 27 digits.
mandateLastUpdateDate
mandateCreationDate
mandateId
mandateSignatureDate
mandateStatus
mandateUsage
transactionActors
mandateSecureReference Related to the SafeDebit option
riskyMandate

Y or N.

Related to the SafeDebit option

Response example: searchMandate via Sips Office

{
"mandateResponseCode":"00",
"acquirerResponseCode":"00",
"mandateList":
[
{
  "mandateId":"000000000000009383",
  "mandateStatus":"ACTIVE",
  "mandateSignatureDate":"20171016",
  "mandateCreationDate":"20171016",
  "mandateLastUpdateDate":"20171016",
  "bic":"AGRIFRPP879",
  "iban":"FR7617906001120227366700148",
  "transactionActors":"BTOC",
  "mandateUsage":"RECURRENT",
  "mandateSecureReference":"12345678901234567890123456789012",
  "riskyMandate":"N"
},
{
  "mandateId":"000000000000009382",
  "mandateStatus":"ACTIVE",
  "mandateSignatureDate":"20171016",
  "mandateCreationDate":"20171016",
  "mandateLastUpdateDate":"20171016",
  "bic":"AGRIFRPP879",
  "iban":"FR7617906001120227366700148",
  "transactionActors":"BTOC",
  "mandateUsage":"RECURRENT",
  "mandateSecureReference":"12345678901234567890123456789012",
  "riskyMandate":"N"
}
],
"seal":"7fea0c806411bac05d2687d8443ae031cb8b0c0ffde143c08536597e93862df1"
}

You can retrieve the PDF content using Sips Office to offer customers the direct download from your website for example.The getPdfMandate method is used to retrieve the PDF content in a base64 encoded format. It must then be decoded to build the PDF file.

Attention: it is not possible to retrieve a paper version mandate created via Sips Office Extranet which is not not signed electronically.
Field name Remarks/rules
mandateId

Request example: gePdftMandate via Sips Office JSON

{
  "interfaceVersion":"MR_WS_2.19",
  "keyVersion":"1",
  "mandateId":"000000000000009382",
  "merchantId":"210011990011607",
  "seal":"ac46f84ff1f9c974602f0b922f295a115af1c436186d2dbc58e692ef1813b766"
}
Field name Remarks/rules
mandateResponseCode
mandatePdf

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);
}
}

You can get the global data of a particular mandate. These are mandate specific data (status, IBAN, BIC, etc.), data related to the customer who created the mandate, as well as the list of transactions associated with this mandate, if applicable.

Field name Remarks/rules
mandateId

Request example: gePdftMandate via Sips Office JSON

{
   "interfaceVersion":"MR_WS_2.19",
   "keyVersion":"1",
   "mandateId":"000000000000009382",
   "merchantId":"210011990011607",
   "seal":"ac46f84ff1f9c974602f0b922f295a115af1c436186d2dbc58e692ef1813b766"
}

Data related to the mandate and the client:

Field name Remarks/rules
mandateResponseCode
acquirerResponseCode
mandateId
mandateCreationDate
mandateLastUpdateDate
mandateSignatureDate
mandateUsage ONE_OFF|RECURRENT
mandateStatus
bic
debtorName
iban French IBAN are composed of 27 digits.
transactionActors BTOB|BTOC|BTOF
directDebitList
customerContact.email
customerContact.gender
customerContact.mobile
customerContact.legalId
customerContact.positionOccupied
customerAddress.city
customerAddress.country
customerAddress.street
customerAddress.street Number
customerAddress.zipCode
customerAddress.company
customerAddress.businessName

Returned debit data (mandateList):

Field name Remarks/rules
amount
dueDate
directDebitCreationDate
directDebitStatus

Response example: getMandateData via Sips Office JSON

{
  "mandateResponseCode":"00",
  "acquirerResponseCode":"00",
  "mandateId":"000000000000009382",
  "mandateStatus":"ACTIVE",
  "mandateSignatureDate":"20171016",
  "mandateCreationDate":"20171016",
  "mandateLastUpdateDate":"20171016",
  "bic":"AGRIFRPP879",
  "iban":"FR7617906001120227366700148",
  "transactionActors":"BTOC",
  "mandateUsage":"RECURRENT",
  "debtorName":"DUPONT Julie",
  "customerContact":
 {
      "email":"julie.dupont@mail.com"
 },
 "customerAddress":
  {
     "city":"PARIS",
     "country":"FR",
     "street":"Rue de la Bastille",
     "streetNumber":"19",
     "zipCode":"75000"
},
 "directDebitList":
 [
 {
    "amount":250,
    "dueDate":"20171113",
    "directDebitCreationDate":"20171106",
    "directDebitStatus":"CREATED"
 },
{
    "amount":250,
    "dueDate":"20171206",
    "directDebitCreationDate":"20171106",
    "directDebitStatus":"CREATED"
},
{
   "amount":250,
   "dueDate":"20180108",
   "directDebitCreationDate":"20171106",
   "directDebitStatus":"CREATED"
}
],
"seal":"d1c7aff5c85fcc116f7c9fa39c470ba3ed807fd3e65f3edbd0344ec459337058"
}

This site uses cookies to improve your experience, perform analysis and researches on your use of WL Sips documentation website.
You have several options:
Closing this banner you refuse the use of cookies on your device.

Configuration