SEPA Direct Debit is the new European cashing system. SEPA Direct Debit (SDD) enables you to reach all bank accounts that allow direct charge in the SEPA area.

With Axerve Ecommerce Solutions, you can request an approvation order and then issue recurrent payments.

How does it work for the user?

The user is redirected to the SEPA Direct Debit payment page.
The user inserts their bank account coordinates (i.e. the IBAN) in the text box.

The user must provide a telephone number, on which they’ll receive an authorization code via SMS.

The user inserts the code in the text box.

How to enable in Axerve Ecommerce Solutions

Contact our customer support to enable SEPA direct debit in your Axerve Ecommerce Solutions account.

To use SEPA Direct Debit, you must explicitly set the paymentType to SEPADD.

Requesting an approval order

To request an approval order, you can perform a call to our payment page using the payment type SEPADD. Here are the steps:

1. call Encrypt

The first step is to call Encrypt. You can see an example call in the API section api link .

The Encrypt call requires a mandatory amount, but in the preapproval phase it’s discarded. The only amount that will be charged is the amount passed to callPagamS2S. See Performing a recurrent payment later in this page.

2. Redirect the user to the returned URL

Axerve Ecommerce Solutions will answer to the previous request the CryptDecryptString. You should redirect your buyer to

http://ecomm.sella.it/pagam/pagam.aspx?a=<ShopLogin>&b=<CryptDecryptString>

or, in case of test environment, http://sandbox.gestpay.net/pagam/pagam.aspx?a=<ShopLogin>&b=<CryptDecryptString>

Axerve Ecommerce Solutions will show you a preapproval page, where the buyer can enter their bank account number.

3. Response from the preapproval page

In the merchant backoffice, configure the URLs for positive and negative responses, together with the URL Server to Server. This can be set in Configuration -> Environment -> Response Address.

If Axerve Ecommerce Solutions cannot reach your server to server URL, it may try for other 48 hours.

The response will be a GET to the specified URL, with these query parameters:

http://<url merchant>?a=<ShopLogin>&b=<encrypted string>

the <encrypted string> has to be passed to WsCryptDecrypt web service, calling the Decrypt method.

When decrypting the preapproval Axerve Ecommerce Solutions will answer with XX as the TransactionResult code, that means that this is not the final result. Axerve Ecommerce Solutions will send XX when the outcome is asynchronous. A new communication will be provided to the merchant when the transaction will assume the final OK/KO status.

Here is an example:

1<DecryptResponse xmlns="https://ecomm.sella.it/">
2  <DecryptResult>
3    <GestPayCryptDecrypt xmlns="">
4    <TransactionType>DECRYPT</TransactionType>
5    <TransactionResult>XX</TransactionResult><!-- XX: final response code will come in the future -->
6    <ShopTransactionID>MYSHOP-1123</ShopTransactionID>
7    <BankTransactionID/>
8    <AuthorizationCode/><!-- This field is empty now... -->
9    <Currency>242</Currency>
10    <Amount>10.00</Amount>
11    <Country/>
12    <CustomInfo/>
13    <Buyer>
14      <BuyerName/>
15      <BuyerEmail/>
16    </Buyer>
17    <TDLevel/>
18    <ErrorCode>0</ErrorCode>
19    <ErrorDescription>Transaction correctly processed</ErrorDescription>
20    <AlertCode>0</AlertCode>
21    <AlertDescription>Transaction correctly processed</AlertDescription>
22    ... 
23  </DecryptResult>
24</DecryptResponse>

The final response of a SEPA payment takes some time; Axerve Ecommerce Solutions will then send the final outcome of the payment to the Server to Server URL, always in the form:

http://<url merchant>?a=<ShopLogin>&b=<encrypted string>

By decrypting the enctypted string, we’ll get a new DecryptResponse with an updated TransactionResult and a filled AuthorizationCode field. Example:

1<DecryptResponse xmlns="https://ecomm.sella.it/">
2  <DecryptResult>
3    <GestPayCryptDecrypt xmlns="">
4      <TransactionType>DECRYPT</TransactionType>
5      <TransactionResult>OK</TransactionResult><!-- Actual response -->
6      <ShopTransactionID>3 year SubScription</ShopTransactionID>
7      <BankTransactionID/>
8      <AuthorizationCode>SPOEJ4NWDAKEBU5H<AuthorizationCode><!-- we have finally recevied a token to use with callPagamS2S -->
9      <Currency>242</Currency>
10      <Amount>10.00</Amount>
11      <Country/>
12      <CustomInfo/>
13      <Buyer>
14        <BuyerName/>
15        <BuyerEmail/>
16      </Buyer>
17      <TDLevel/>
18      <ErrorCode>0</ErrorCode>
19      <ErrorDescription>Transaction correctly processed</ErrorDescription>
20      <AlertCode>0</AlertCode>
21      <AlertDescription>Transaction correctly processed</AlertDescription>
22      ...
23    </GestPayCryptDecrypt>
24  </DecryptResult>
25</DecryptResponse>

If the confirmation message contains OK as TransactionResult, Axerve Ecommerce Solutions will also send the AuthorizationCode that is a token that can be used later with CallPagamS2S api link .

You can read more about Encrypt and Decrypt and the payment process at this link.

Performing a recurrent payment

Once you have the token, you can pay via callPagamS2S api link .

Together with usual callPagamS2S mandatory parameters, there are two more: tokenValue and BillingAddress.CountryCode.

For example, if the received token is SPOEJ4NWDAKEBU5H, a call to callPagamS2S would be:

1<callPagamS2S>
2    <shopLogin>GESPAYxxxxx</shopLogin>
3    <uicCode>242</uicCode>
4    <amount>10</amount>
5    <shopTransactionId>MYSHOP-paymentExecution1</shopTransactionId>
6    <tokenValue>SPOEJ4NWDAKEBU5H</tokenValue><!-- mandatory -->
7    <OrderDetails>
8      <BillingAddress>
9        <ProfileID></ProfileID>
10        <FirstName></FirstName>
11        <MiddleName></MiddleName>
12        <Lastname></Lastname>
13        <StreetNumber></StreetNumber>
14        <StreetName></StreetName>
15        <Streetname2></Streetname2>
16        <HouseNumber></HouseNumber>
17        <HouseExtention></HouseExtention>
18        <City></City>
19        <ZipCode></ZipCode>
20        <State></State>
21        <CountryCode>IT</CountryCode><!-- mandatory -->
22        <Email></Email>
23        <PrimaryPhone></PrimaryPhone>
24        <SecondaryPhone></SecondaryPhone>
25        <Company></Company>
26        <StateCode></StateCode>
27      </BillingAddress>
28    </OrderDetails>
29</callPagamS2S>

Here is an example response:

1<callPagamS2SResult>
2  <GestPayS2S xmlns="">
3    <TransactionType>PAGAM</TransactionType>
4    <TransactionResult>XX</TransactionResult><!-- again! -->
5    <ShopTransactionID>SlimPay_Test</ShopTransactionID>
6    <BankTransactionID>2922</BankTransactionID>
7    ...
8  </GestPayS2S>
9</callPagamS2SResult>

Notice that the TransactionResult is XX, again. That’s because SEPA requires two days to process payments, and the final result will be sent via GET request to your Server to Server URL.

When Axerve Ecommerce Solutions has performed the payment, a call to the server to server will be issued in the classic form:

http://<server-to-server merchant url>?a=<ShopLogin>&b=<encrypted string>

This call can be decrypted by calling Decrypt, as usual, and a payment confirmation will be in this form:

1<soap:Envelope 
2  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
3  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
4  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
5   <soap:Body>
6      <DecryptResponse xmlns="https://ecomm.sella.it/">
7         <DecryptResult>
8            <GestPayCryptDecrypt xmlns="">
9               <TransactionType>DECRYPT</TransactionType>
10               <TransactionResult>OK</TransactionResult>
11               <ShopTransactionID>SlimPay_Test</ShopTransactionID>
12               <BankTransactionID>954</BankTransactionID>
13               <AuthorizationCode>S2P123</AuthorizationCode>
14               <Currency>242</Currency>
15               <Amount>10</Amount>
16               <Country/>
17               <CustomInfo/>
18               <Buyer>
19                  <BuyerName/>
20                  <BuyerEmail/>
21               </Buyer>
22               <TDLevel/>
23               <ErrorCode>0</ErrorCode>
24               <ErrorDescription> Transaction correctly processed</ErrorDescription>
25               <AlertCode/>
26               <AlertDescription/>
27               <VbVRisp/>
28               <VbVBuyer/>
29               <VbVFlag/>
30               <TransactionKey/>
31               <AVSResultCode/>
32               <AVSResultDescription/>
33               <RiskResponseCode/>
34               <RiskResponseDescription/>
35            </GestPayCryptDecrypt>
36         </DecryptResult>
37      </DecryptResponse>
38   </soap:Body>
39</soap:Envelope>

Slimpay

The SDDs are of the CORE type and therefore can be reversed in 8 weeks.

In addition to retaining the mandate in its systems, SlimPay creates a proof of creation of the mandate that is kept at CDC Arkineo, which is a French deposit and deposit fund (certification institute certified by the French government). This document can be reused if there is a dispute with the signature. If the merchant wants a preservation in accordance with the law, this can be done at the French institution or at the organization they prefer. We can arrange for the merchant to receive a copy of the mandate via e-mail. In case of a dispute over the signing of the mandate, the merchant retrieves the test file from CDC Arkineo in which there are all the data concerning the mandate, the certificate, the IP and other. These are authenticated and certified by the French organization and at the same time legal assistance is provided.

Sella Personal Credit "Rate in Rete"

TrustPay