Pagamenti ricorrenti (MIT)

La tipologia di transazioni inizializzate dall'esercente (dall'inglese Merchant Initiated Transaction, normalmente indicato con MIT) è tipica dei settori caratterizzati da modelli di business nei quali i pagamenti avvengono in momenti separati dal momento dell'acquisto.
In questi scenari, l’acquirente consente al merchant di procedere con futuri pagamenti accettando termini e condizioni previsti dall'accordo tra le parti.

Alcuni esempi sono i pagamenti di bollette, gli abbonamenti e i servizi a consumo.

Per la corretta gestione di questi pagamenti è necessario conoscere e utilizzare correttamente due tipologie di transazioni:

• 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 ed avere riferimento per la generazione delle successive transazioni, che avverranno senza la presenza del pagatore.

• 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.

Le MIT sono da considerate out-of-scope rispetto alla PSD2, pertanto non richiedono l'autenticazione a due fattori.

Linee guida per l’integrazione

Fabrick Payment Orchestra supporta due tipologie di MIT:

• Transazioni ricorrenti (recurring transactions): Transazioni con importo e periodicità costanti.

• Transazioni non-programmate (unscheduled transactions): Transazioni con importo e periodicità variabili.

Le transazioni MIT condividono i seguenti requisiti:

• È necessario che ci sia un accordo tra esercente e acquirente che autorizzi il primo ad effettuare transazioni a carico del secondo.

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

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

Per processare le transazioni per le quali il compratore non è in sessione (MIT), le credenziali di pagamento utilizzate per completare la transazione vengono solitamente tokenizzate durante la transazione iniziale (CIT).

Transazioni ricorrenti (Recurring)

Le transazioni ricorrenti sono indicate per i casi in cui l’importo e la frequenza dei pagamenti sono conosciuti in anticipo.
Un esempio è l'abbonamento ad un servizio digitale: in questi casi vi è una transazione iniziale che necessita di autenticazione a due fattori (SCA), a cui faremo riferiremo come First (CIT), ed una serie di transazioni periodiche, chiamate Next (MIT). Queste ultime sono addebitate al cliente a fronte della sottoscrizione del servizio (ovvero l'accordo tra le parti). 

Per processare correttamente questa tipologia di transazione è necessario compilare correttamente i seguenti campi obbligatori:

1. Pagamento ricorrente iniziale (CIT):

   • type = 01F (è possibile verificare la tipologia di "type" negli esempi presenti in fondo alla pagina).

   • 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, Fabrick fornisce l'identificativo della serie dei pagamenti, da utilizzare nelle transazioni MIT successive.

2. Pagamento ricorrente successivo (MIT):

   • 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.

Transazioni non-programmate (Unscheduled)

Le transazioni non-programmate hanno la caratteristica di presentare periodicità ed importo dei pagamenti variabili. Questo tipo di transazione è ideale per i modelli di business che prevedono pagamenti “a consumo”, nel caso di applicazione di no-show fees e per applicare penali (es. nel caso di danno a beni noleggiati). 

Le modalità di integrazione seguono le linee guida generali per le MIT, presentando meno limiti rispetto ai pagamenti ricorrenti:

1. Pagamento non-programmato iniziale (CIT):

• type = 03F

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

Una volta concluso il pagamento, Fabrick fornisce l'identificativo della serie dei pagamenti, da utilizzare nelle transazioni MIT successive.

2. Pagamento non-programmato successivo (MIT):

• type = 03N

• 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 e 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 paymentID della transazione.

  • XID: ID unico prioritario assegnato dalla Directory del Server

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

La cancellazione del pagamento iniziale, sia esso di tipologia 01F o 03F, comporta il rischio di generare errori sui pagamenti successivi. Pertanto, per evitare i rischi di deterioramento delle performance, è necessario accertarsi che le transazioni CIT vengano processate correttamente e senza meccanismi di cancellazione automatica delle autorizzazioni ad esempio laddove siano previsti periodi di prova gratuiti.

Non è raro che la vendita di un servizio preveda un periodo di prova gratuito o un pagamento a consuntivo e, dunque, da processare in un momento successivo rispetto al pagamento nel quale il compratore è in sessione.
Per la gestione di questa tipologia di transazioni, l'esercente potrà valorizzare il campo "amount" nella transazione iniziale a "0". Il campo "authenticationAmount" dovrà invece essere valorizzato con l'importo previsto per gli addebiti successivi. Questo consentirà di generare una nuova catena di pagamenti MIT fornendo un'esperienza di acquisto ottimale al pagatore, che non si vedrà infatti addebitato alcun importo durante il periodo di prova.

Di seguito un esempio per le API SOAP:

1 {
22 "shopLogin": "GESPAY00001",
33 "amount": "0",
44 "currency": "EUR",
55 "shopTransactionID": "OrderID_01F_001",
66 "transDetails": {
77 "type": "01F",
88 "authenticationAmount": "10",
99 "recurringTransaction":{
1010 "expiry": "20301225",
1111 "frequency": "14"
1212 }
1313 }
1414}

Transazioni antecedenti alla PSD2 (Grandfathered transactions)

Fino al 31 Ottobre 2022, le transazioni in corso ed antecedenti all'adozione dei protocolli 3DS2 potranno essere processate senza che esista una prima transazione autenticata (CIT), né il relativo identificativo.

Ci si riferisce a queste MIT come grandfathered transactions e possono essere processate 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 che hanno avuto origine nel contesto normativo PSD2, le grandfathered transactions non richiedono che venga archiviato alcun valore identificativo che fa riferimento alla prima transazione della serie (CIT), e quindi la relativa corretta autenticazione del compratore.
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 corretta che segue i requisiti richiesti, in base alla tipologia di MIT.

Dal 31 ottobre 2022, i Circuiti dismetteranno le transazioni di tipo grandfathered: al fine di non incorrere in riduzioni dei tassi di conversione, è necessario assicurarsi di processare correttamente i pagamenti MIT secondo le linee guida descritte precedentemente.
Qualora una transazione venga processata senza aver rispettato le linee guida relative all'autenticazione ed alle possibili esclusioni (come lo sono ad esempio le MIT), questa potrà essere rifiutata con errore di tipo 8026 "Soft decline - Cardholder authentication required".

In questo caso, sarà necessario ingaggiare il buyer e completare una transazione "First", autenticando il pagamento, in modo da poter avviare una nuova catena di ricorrenze secondo i requisiti previsti.

Alcuni esempi di seguito: