Il SEPA Direct Debit corrisponde all’addebito diretto continuativo, anche domiciliazione bancaria, di un importo sul conto corrente, previa autorizzazione del debitore alla propria banca.

Con Fabrick Payment Orchestra è possibile richiedere l’ordine di approvazione e gli addebiti ricorrenti conseguenti.

Come funziona per il compratore

Di seguito le fasi del pagamento per l’acquirente:

Atterraggio alla pagina del pagamento SEPA Direct Debit
Inserimento dei dati del conto corrente (IBAN)

Inserimento del numero di telefono sul quale viene inviato un codice via SMS

Inserimento del codice ricevuto via SMS

Come attivare l’SDD sul gateway

Innanzitutto è necessario richiedere l’attivazione al proprio commerciale di riferimento o tramite l’assistenza.

Per utilizzare questo metodo di pagamento è necessario selezionare SEPADD comepaymentType.

1. Chiamata Encrypt

Il primo step è quello di chiamare Encrypt api link . Un esempio è disponibile nella sezione API.

La chiamata Encrypt richiede un importo obbligatorio ma nella fase di pre-approvazione viene scartato. L’unico importo che viene addebitato è quello inserito nella callPagamS2S. Per approfondire saltare subito alla sezione "effettuare un pagamento ricorrente" di questa pagina.

2. Indirizzare l’utente alla URL restituita

Fabrick Payment Orchestra risponde alla richiesta precedente con la CryptDecryptString. A questo punto si deve direzionare il buyer verso:

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

o, in ambiente di test, verso:

http://sandbox.gestpay.net/pagam/pagam.aspx?a=<ShopLogin>&b=<CryptDecryptString>

Il gateway, a questo punto, mostra una pagina di pre-approvazione dove l’acquirente deve inserire l’IBAN del suo conto corrente.

Risposta dalla pagina di pre-approvazione

Nella sezione Configurazione > Ambiente > Indirizzi Risposte del backoffice merchant, occorre configurare le URL per le risposte positiva e negativa alla richiesta autorizzativa e la URL server to Server.

Se il gateway non riesce a raggiungere i server del merchant, ritenta per 48 ore.

La risposta è una GET alla URL specifica con questi parametri:

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

La <encrypted string> deve essere passata al web service WsCryptDecrypt, chiamando il metodo Decrypt api link .

Decodificando la pre-approvazione, Fabrick Payment Orchestra risponde con XX come codice TransactionResult, il che significa che non è il risultato finale. Il gateway quindi invia XX quando il risultato è asincrono. Quando la transazione assume lo status finale di OK/KO, viene poi inviata al merchant una nuova comunicazione.

Ecco un esempio:

1<DecryptResponse xmlns="https://ecomm.sella.it/">
2  <DecryptResult>
3    <GestPayCryptDecrypt xmlns="">
4    <TransactionType>DECRYPT</TransactionType>
5    <TransactionResult>XX</TransactionResult>
6    <ShopTransactionID>MYSHOP-1123</ShopTransactionID>
7    <BankTransactionID/>
8    <AuthorizationCode/>
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>

Ricevuta la risposta del pagamento SDD, Fabrick invia il risultato finale alla URL Server to Server, sempre in questa forma:

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

Decodificando la stringa criptata, si ottiene un nuovo DecryptResponse con un TransactionResult aggiornato e il campo AuthorizationCode compilato. Ecco un esempio:

1<DecryptResponse xmlns="https://ecomm.sella.it/">
2  <DecryptResult>
3    <GestPayCryptDecrypt xmlns="">
4      <TransactionType>DECRYPT</TransactionType>
5      <TransactionResult>OK</TransactionResult>
6      <ShopTransactionID>3 year SubScription</ShopTransactionID>
7      <BankTransactionID/>
8      <AuthorizationCode>SPOEJ4NWDAKEBU5H<AuthorizationCode>
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>

Se il messaggio di conferma contiene OK come TransactionResult, il gateway invia anche l’AuthorizationCode che è un token che può essere usato più tardi con la CallPagamS2S api link . .

È possibile approfondire Encrypt e Decrypt e il processo di pagamento a questo link.

Effettuare un pagamento ricorrente

Una volta ottenuto il token, è possibile pagare attraverso la callPagamS2S api link .

Assieme ai parametri obbligatori della callPagamS2S, ce ne sono altri due: tokenValue e BillingAddress.CountryCode.

Per esempio, se il token ricevuto è SPOEJ4NWDAKEBU5H, una chiamata potrebbe essere:

1<callPagamS2S>
2  <shopLogin>GESPAYxxxxx</shopLogin>
3  <uicCode>242</uicCode>
4  <amount>10</amount>
5  <shopTransactionId>MYSHOP-paymentExecution1</shopTransactionId>
6  <tokenValue>SPOEJ4NWDAKEBU5H</tokenValue><!-- obbligatorio -->
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><!-- obbligatorio -->
22      <Email></Email>
23      <PrimaryPhone></PrimaryPhone>
24      <SecondaryPhone></SecondaryPhone>
25      <Company></Company>
26      <StateCode></StateCode>
27    </BillingAddress>
28  </OrderDetails>
29</callPagamS2S>

Ecco un esempio di risposta:

1<callPagamS2SResult>
2  <GestPayS2S xmlns="">
3    <TransactionType>PAGAM</TransactionType>
4    <TransactionResult>XX</TransactionResult><!-- di nuovo! -->
5    <ShopTransactionID>SlimPay\_Test</ShopTransactionID>
6    <BankTransactionID>2922</BankTransactionID>
7    ...
8  </GestPayS2S>
9</callPagamS2SResult>

Da notare che TransactionResult è di nuovo XX. Questo perché SEPA richiede due giorni per processare il pagamento, e il risultato finale viene spedito con la richiesta GET alla URL Server to Server.

Quando Fabrick Payment Orchestra ha effettuato un pagamento, una chiamata server to server viene effettuata nella forma classica:

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

Questa call può essere decodificata chiamando Decrypt e la conferma del pagamento avviene in questa forma:

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

Slimpay

Slimpay è il servizio tramite il quale Fabrick offre il metodo di pagamento SDD.

Gli SDD sono di tipologia CORE, dunque il periodo entro il quale è possibile chiederne il rimborso è di 8 settimane.

Oltre all’archiviazione del mandato sui suoi sistemi, Slimpay crea una prova della creazione del mandato che viene trattenuto da CDC Arkineo, un fondo di deposito francese (istituto di certificazione accreditato dal governo francese). Questo documento può essere riutilizzato in caso di disputa sulla firma. Se l’esercente richiede una protezione in accordo con la normativa, questa può essere effettuata tramite l’istituzione francese o altra organizzazione di sua preferenza. Fabrick può fornire una copia del mandato via e-mail. In caso di disputa sulla firma del mandato, il merchant recupera il file di testa da CDC Arkineo nel quale ci sono tutti i dati relativi al mandato, al certificato, l’IP e ad altri ancora. Questi sono autenticati e certificati dall’organizzazione francese, inoltre viene offerta anche assistenza legale.

Sella Personal Credit "Rate in Rete"

TrustPay