open menu
axerve docs
Pagamenti/Pagamenti ricorrenti/Pagamenti ricorrenti (MIT)

Pagamenti ricorrenti (MIT)

Per la corretta generazione di pagamenti ricorrenti, è necessario conoscere ed utilizzare correttamente due tipologie di transazioni:

  • Merchant Initiated Transaction (MIT)
    Sono transazioni avviate dal merchant in assenza del buyer, secondo accordi e condizioni definiti dall’esercente e preventivamente accettati dall’acquirente.

  • Customer Initiated Transactions (CIT)
    È la prima transazione della catena delle transazioni ricorrenti. Richiede la Strong Customer Authentication (SCA), in modo da verificare l'autenticità del pagatore e avere riferimento per la generazione delle successive transazioni, senza la presenza del pagatore.

La tipologia di transazioni ricorrenti è tipica di specifici settori nei cui modelli di business sono presenti servizi basati su sottoscrizione o bollette, solo per citare alcuni esempi. In questi scenari, l’acquirente consente al merchant di procedere con futuri pagamenti accettando termini e condizioni di un accordo tra le parti.

default

Le MIT sono da considerate out-of-scope rispetto alla PSD2 e pertanto non richiedono un’autenticazione forte.

Linee guida per l’integrazione

Esistono 3 tipologie di MIT che condividono tutte gli stessi principi funzionali.

Nel caso delle MIT è bene tenere a mente 3 elementi chiave:

  • Per finalizzare una MIT, occorre che ci sia stato un accordo tra esercente ed acquirente che autorizzi il primo ad effettuare transazioni a carico del secondo.

  • Le MIT devono avere una prima transazione di riferimento, identificata come la prima della serie.

  • La prima transazione (CIT) a cui faranno riferimento le successive MIT deve essere autenticata con la SCA (Strong Customer Authetication).

Axerve Ecommerce Solutions supporta due tipologie di MIT:

  • recurring transactions (transazioni ricorrenti)

  • unscheduled transactions (transazioni non-programmate).

Recurring transactions

Le recurring transactions sono la soluzione ideale per i casi in cui l’importo e la frequenza dei pagamenti sono conosciuti in anticipo.

Un esempio classico può essere relativo ai servizi con sottoscrizione: in questi casi vi è una transazione iniziale, che necessita di autenticazione, chiamata First Transaction (CIT) e una transazione a canone mensile, chiamata Next Transaction (MIT) la quale è addebitata al cliente a fronte di una sottoscrizione (agreement) del servizio. La sottoscrizione di prassi richiede la tokenizzazione della carta di credito dell’acquirente e l’autenticazione dell’importo per il canone mensile (transazione autenticata con SCA).

Per le transazioni First che prevedono la sottoscrizione gratuita durante la prima frequenza di pagamento (es. primo mese con transazione gratuita e mesi successivi inizia la catena di pagamenti), è necessario l'utilizzo dello strumento [ASI].

Secondo il framework delle CIT, le ricorrenze consistono di due passaggi:

  1. Setup delle recurring MIT: affinché possano essere processate le CIT, la ricorrenza deve essere impostata autenticando la prima transazione della serie con un importo massimo. Questo avviene compilando questi campi:

    • Type = 01F.

    • authenticationAmount: importo massimo atteso secondo termini e condizioni dell’accordo tra le parti.

    • expiry: data di scadenza dell’accordo.

    • frequency: numero minimo di giorni tra i pagamenti.

    Una volta concluso il pagamento, viene fornito un identificativo della serie dei pagamenti che seguiranno.

  2. Lavorazione delle transazioni MIT: a differenza della prima transazione che viene autenticata, quelle successive sono considerate vengono identificate come out-of-scope. I tag richiesti per le MIT sono i seguenti:

    • Type = 01N

    • previousTransDetails: questo oggetto contiene informazioni necessarie per collegare le MIT alla prima transazione autenticata. Può essere utilizzato uno qualsiasi dei campi seguenti:

      • BankTransactionID: questo è il dato che consigliamo di specificare. È l’identificativo del primo pagamento. Nel caso di integrazione con le API SOAP, il parametro BankTransactionID, per i pagamenti con le API REST, deve essere usato il PaymentID della transazione.

      • XID: ID univoco assegnato dal Directory Server.

      • Previous 3DS2 authentication data: in questo caso, tutti i campi seguenti devono essere compilati: authData, authMethod, authTimestamp, acsID.

      • expiry: data di scadenza dell’accordo.

      • frequency: numero minimo di giorni tra i pagamenti.

All'interno delle transazioni di tipologia 01F, i dati necessari per una corretta implementazione sono i seguenti:

  • AuthenticationAmount: è l'importo riguardante l'autenticazione 3DS. L'AuthenticationAmount sarà l'importo target utilizzato nelle transazioni ricorrenti successive alla prima, e per questo motivo, l'AuthenticationAmount deve essere uguale o maggiore all'importo delle transazioni ricorrenti. È quindi raccomandato avvisare il buyer, nel caso l'AuthenticationAmount sia maggiore dell'importo della transazione, che AuthenticationAmount ed AuthorizationAmount (nella API si chiama semplicemente Amount) differiranno all'interno della transazione.

  • expiry: Rappresenta la data di scadenza all'interno delle transazioni ricorrenti, dopo la quale non saranno più generate transazioni. Il formato necessario ai fini di una corretta implementazione è il seguente: YYYYMMDD.

  • frequency: Indica il numero minimo di giorni tra due transazioni ricorrenti per una stessa catena. Questo dato è necessario ai fini di una corretta implementazione della ricorrenza della transazione.

Unscheduled MIT

Le recurring transactions non coprono tutti gli scenari: in alcune occasioni l’importo massimo addebitato non può essere definito ex-ante oppure la periodicità dei pagamenti può essere variabile.

Le unscheduled MIT sono ideali per i modelli di business “a consumo”, nel caso di applicazione di no-show fees e per applicare penali (es. nel caso di danno a beni noleggiati).

Le unscheduled MIT seguono le regole comuni alle transazioni MIT e, per essere impostate, necessitano di un’autenticazione sulla prima transazione e di un accordo tra le parti (merchant e acquirente).

1. Impostazione delle unscheduled CIT: come specificato in precedenza, impostare una unscheduled MIT è molto più semplice di quanto non lo sia per i recurring payments, considerato che l’unica informazione necessaria è il tag corretto per il tipo di transazione:

  • Type = 03F

  • expiry: data di scadenza dell’accordo

2. Gestione delle unscheduled CIT conseguenti: i tag necessari per le MIT successive sono i seguenti:

  • Type = 03N

  • expiry: data di scadenza dell’accordo

  • previousTransDetails: questo oggetto contiene le informazioni necessarie per collegare i pagamenti ricorrenti MIT alla prima transazione autenticata con SCA. Uno qualsiasi dei seguenti può essere usato:

    • bankTransactionID: questo campo è quello che raccomandiamo di utilizzare. Identifica il primo pagamento ricorrente. Per i pagamenti effettuati con la tecnologia SOAP, il parametro è bankTransactionID, per i pagamenti effettuati via API REST, deve essere usato il bankTransactionID della transazione.

    • XID: ID unico prioritario assegnato dalla Directory del Server

    • Dati della precedente autenticazione 3DS2: in questo caso, tutti questi campi devono essere compilati opportunamente: authData, authMethod, authTimestamp, acsID.

Transazioni antecedenti alla PSD2 (Grandfathered transactions)

Le transazioni in corso da prima dei protocolli 3DS2 possono essere lavorate senza che esista una prima transazione autenticata né il relativo identificativo.

Ci si riferisce a queste MIT identificandole come grandfathered transactions e possono essere lavorate utilizzando i tag seguenti:

  • Type: occorre definire il tipo di MIT. I valori possibili sono i seguenti:

    • 01N per le Recurring Transactions.

    • 03N per le Unscheduled MIT.

  • bankTransactionID: -100

A differenza delle transazioni iniziate in un contesto PSD2, le grandfathered transactions non richiedono che venga archiviato alcun valore identificativo.

Ogni transazione MIT viene lavorata con la referenza bankTransactionID: -100 sino a che l’accordo tra le parti non viene rinnovato con una nuova autenticazione dell’acquirente. Quando ciò accade, inizia una nuova catena di ricorrenze sempre secondo i requisiti richiesti dalla tipologia di MIT.

Il 31 ottobre 2022, entra in vigore un processo di “spegnimento” da parte dei Circuiti per le transazioni grandfathered. È opportuno quindi allinearsi con la corretta condivisione dei dati riguardanti i pagamenti ricorrenti, al fine di avere una corretta creazione di questo tipo di transazioni.

A causa di questa implementazione, gli errori vengono individuati, targhettizzati e distribuiti in modo diverso. Alcuni errori prima generici hanno significati più precisi, in modo da aiutare il merchant a comprendere la dinamicità ed altezza dell'errore. È comunque attesa una riduzione in valore assoluto del numero degli errori, ma un aumento su un singolo (es. 8026 "Soft decline - Cardholder authentication required").

È plausibile un aumento dei casi di soft decline 8026 che informano della necessità di procedere ad un aggiornamento della catena di pagamento, a fronte del quale è necessario l'utilizzo di un meccanismo di retry impostabile e un monitoraggio delle transazioni che restituiscono questo tipo di errore. Una volta ricevuto l'errore, è necessaria la richiesta di generazione di una nuova catena che sostituisce la transazione grandfathered precedente.

Qui di seguito alcuni esempi:

SOAP
REST

Encrypt - 01F

copy
1 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ecom="https://ecomm.sella.it/">
2   <soapenv:Header/>
3   <soapenv:Body>
4      <ecom:Encrypt>
5         <ecom:shopLogin>GESPAY00001</ecom:shopLogin>
6         <ecom:uicCode>242</ecom:uicCode>
7         <ecom:amount>0</ecom:amount>
8         <ecom:shopTransactionId>OrderID_01F_001</ecom:shopTransactionId>
9         <ecom:requestToken>MASKEDPAN</ecom:requestToken>
10        <ecom:transDetails>
11        <ecom:type>01F</ecom:type>
12        <ecom:authenticationAmount>10</ecom:authenticationAmount>
13        <ecom:recurringTransaction>
14            <ecom:expiry>20301225</ecom:expiry>
15            <ecom:frequency>14</ecom:frequency>
16        </ecom:recurringTransaction>
17        </ecom:transDetails>       
18         <ecom:apikey></ecom:apikey>
19      </ecom:Encrypt>
20   </soapenv:Body>
21</soapenv:Envelope>

callPagamS2S - 01N

copy
1<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ecom="https://ecomms2s.sella.it/">
2   <soapenv:Header/>
3   <soapenv:Body>
4      <ecom:callPagamS2S>
5         <ecom:shopLogin>GESPAY00001</ecom:shopLogin>
6         <ecom:uicCode>242</ecom:uicCode>
7         <ecom:amount>10</ecom:amount>
8         <ecom:shopTransactionId>OrderID_01N_001</ecom:shopTransactionId>
9         <ecom:tokenValue><!-- Token received in the 01F :--></ecom:tokenValue>  
10        <ecom:transDetails>
11        <ecom:type>01N</ecom:type>
12        <ecom:previousTransDetails>
13            <ecom:bankTransactionID><!-- bankTransactionID of the 01F :--></ecom:bankTransactionID>
14        </ecom:previousTransDetails>
15        </ecom:transDetails>
16         <ecom:apikey></ecom:apikey>
17      </ecom:callPagamS2S>
18   </soapenv:Body>
19</soapenv:Envelope>

Encrypt - 03F 

copy
1<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ecom="https://ecomms2s.sella.it/">
2   <soapenv:Header/>
3   <soapenv:Body>
4      <ecom:callPagamS2S>
5         <ecom:shopLogin>GESPAY00001</ecom:shopLogin>
6         <ecom:uicCode>242</ecom:uicCode>
7         <ecom:amount>10</ecom:amount>
8         <ecom:shopTransactionId>OrderID_03N_001</ecom:shopTransactionId>
9         <ecom:tokenValue><!-- Token received in the 03F :--></ecom:tokenValue>  
10        <ecom:transDetails>
11        <ecom:type>03N</ecom:type>
12        <ecom:previousTransDetails>
13            <ecom:bankTransactionID><!-- bankTransactionID of the 03F :--></ecom:bankTransactionID>
14        </ecom:previousTransDetails>
15        </ecom:transDetails>
16         <ecom:apikey></ecom:apikey>
17      </ecom:callPagamS2S>
18   </soapenv:Body>
19</soapenv:Envelope>

Questa pagina è stata utile?

Precedente
prevTassi di cambio
Successiva
Pagamenti ricorrenti e NOM su carte MasterCardnext