Gestpay diventa Axerve Ecommerce Solutions

Transazioni MIT

Con Merchant Initiated Transactions, generalmente MIT, ci si riferisce alle transazioni avviate dal merchant in assenza del buyer, secondo accordi e condizioni definite dall’esercente e preventivamente accettati dall’acquirente.

Questa tipologia di transazioni è tipica di specifici settori nei cui modelli di business sono presenti servizi basati su sottoscrizione, bollette e rateizzazioni, 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.

Visto che le MIT vengono avviate in assenza del compratore, non richiedono un’autenticazione (SCA) e sono da considerarsi out-of-scope rispetto alla PSD2.

Linee guida per l’integrazione

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

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

Axerve Ecommerce Solutions supporta due tipologie di MIT: recurring transactions (transazioni ricorrenti) e 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 un canone mensile (MIT) vie e addebitato 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’autorizzazione dell’importo per il canone mensile (transazione autenticata con SCA).

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

  1. Set up delle recurring MIT : affinché possano essere processate le MIT, 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 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.

Unscheduled MIT Under development

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

Tuttavia, ci sono meno limitazioni rispetto alle recurring transactions: la somma delle transazioni MIT successive può essere superiore dell’importo della prima transazione autenticata e frequenza e data di scadenza non sono richieste.

  1. Impostazione delle unscheduled MIT: 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
  2. Gestione delle unscehduled MIT conseguenti: i tag necessari per le MIT successive sono i seguenti:
    • 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. 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 antecendenti 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:

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.