Tutorial sui pagamenti via Internet. Per capire il ruolo degli issuer, degli acquirer e dei database transazionali.
gennaio 2007 Il crescente successo del commercio on line è da anni
sotto gli occhi di tutti, con la sua storia costellata di aziende che, spesso,
rappresentano veri e propri casi emblematici della “new economy” in senso lato.
Queste esperienze d’impresa e, più in generale, questi modelli di business si
basano tutti sulla possibilità tecnica di mettere in comunicazione diretta cliente
e fornitore, su un canale – il Web – pensato fin dall’origine per presentare
e trattare informazioni in modo oggettivo ed efficiente. Questo canale consente
di trovare rapidamente tutto quello che serve, di confrontare con estrema facilità
la competitività delle offerte, di avere accesso a una vasta scelta grazie alla
possibilità di entrare in contatto con venditori di ogni parte del mondo.
Ma il commercio elettronico non si riduce all’esposizione su Internet di un
insieme di cataloghi di prodotti più o meno chiari, nutriti e graficamente curati,
più o meno dotati di funzioni di ricerca, più o meno capaci di adattarsi ai
gusti del visitatore in base alle sue preferenze dedotte dalla storia dei suoi
precedenti acquisti o ricerche sullo stesso sito. Tutto questo gioca senza dubbio
un ruolo determinante nel successo dell’e-commerce, ma solo nell’ambito di una
fase preliminare all’atto di acquistare vero e proprio, che è l’unico scopo
per cui tutto questo sforzo tecnologico, di marketing ed editoriale (Web design)
viene messo in campo.
Rapporto venditore-acquirente
Specialmente nel modello business-to-consumer, ogni transazione commerciale
richiede tipicamente la corresponsione di una somma di denaro in cambio di beni
o servizi. In genere, nel caso dell’acquisto effettuato in un negozio, come
l’esperienza ci insegna, risulta facile e intuitivo rendere sostanzialmente
concomitanti, sicure, corrette e rapide queste due operazioni. Nel caso del
commercio elettronico l’obiettivo è lo stesso, ma una serie di circostanze rende
potenzialmente difficile o rischioso compiere la transazione.
Solo per limitarci a quelle macroscopiche che riguardano il rapporto venditore-acquirente
e il pagamento, possiamo ricordare ad esempio che:
- Non vi è interazione diretta fra due persone, ma tutto è mediato (e in molti
casi attuato) da una “asettica” interfaccia Web. Non soltanto acquirente e
venditore non si conoscono, ma non possono neppure “studiarsi” con sguardi
o domande per valutare, anche solo a livello superficiale, l’affidabilità
della controparte. Dunque, in linea di principio nessuno dei due ha un particolare
motivo per fidarsi dell’altro. - La comunicazione fra acquirente e venditore è, per così dire, incanalata
in un processo con fasi predeterminate e limitate possibilità di tornare indietro,
far notare un errore, fare richieste per esigenze particolari, gestire l’imprevisto.
È quindi importante che non si verifichino blocchi nella procedura, che non
vi siano aspetti poco chiari, che tutto avvenga in modo rapido, prevedibile
e facile. - Non è possibile utilizzare moneta fisica per il pagamento, ma si deve effettuare
un trasferimento di fondi attraverso mezzi di pagamento elettronico. - Il canale di comunicazione sul quale devono essere comunicate le informazioni
che consentiranno al venditore di incassare il prezzo concordato è Internet,
un canale che certo non brilla per sicurezza intrinseca contro intercettazioni,
alterazioni e falsificazioni.
Poiché la componente on line della transazione commerciale può dirsi completata
quando è stato effettuato il pagamento, si vede quanto sia importante che questo
singolo aspetto caratterizzante del commercio elettronico avvenga in modo affidabile,
rapido, intuitivo e sicuro. Idealmente, il venditore, del quale l’acquirente
per prudenza non si fida mai fino in fondo, non deve poter addebitare somme
maggiori di quelle autorizzate o ripetere più volte l’addebito, e non deve poter
comunicare a terzi gli estremi di una carta di credito.
Dal canto suo, il venditore ha bisogno che i dati forniti dal cliente per effettuare
il pagamento corrispondano a fondi realmente esistenti e di cui il cliente può
disporre e, una volta terminata con successo la procedura, si aspetta che non
possano verificarsi in un secondo tempo problemi che possano inficiarne retrospettivamente
la validità. La classica soluzione a questo insieme di problemi consiste nell’avvalersi
di un’autorità terza di cui sia il venditore, sia l’acquirente abbiano fiducia,
per gestire la transazione di pagamento.
L’acquirente arriva a definire tutti i termini della compravendita utilizzando
le opzioni del sito del venditore, poi passa alla fase di pagamento e, a questo
punto, viene ridiretto sul sito di un istituto bancario (o altro servizio di
intermediazione per pagamenti on line, come l’ PayPal). È solo in questo sito
che va immesso il numero della propria carta di credito: il venditore non ne
verrà mai a conoscenza.
Il collegamento con questo sito è sempre protetto con SSL e il browser visualizza
nella sua barra di stato l’icona che testimonia la protezione crittografica
del collegamento (un altro indicatore importante è l’indicazione del protocollo
https – che sta per secure http – nella barra dell’indirizzo). L’importo del
pagamento, la causale e il beneficiario sono automaticamente preimpostati dal
sito del venditore, per evitare errori. È il servizio di pagamento a occuparsi
della verifica di validità dei dati inseriti e di disponibilità effettiva di
fondi, nonché del trasferimento dell’esatta quantità concordata di fondi dall’acquirente
al venditore.
Ultimata l’operazione, il servizio di pagamento notifica al venditore dell’avvenuto
trasferimento, e quest’ultimo provvede a dare avvio alle procedure per evadere
l’ordine e spedire i beni o erogare i servizi acquistati.
I concetti di issuer e acquirer
Nelle transazioni di pagamento basate su carte di credito, anche nel caso in
cui esse avvengano in negozi e non su Internet, nel grafico di ruoli e relazioni
delle procedure previste spiccano i ruoli dell’issuer e dell’acquirer.
Sono detti issuer quei soggetti (tipicamente banche, ma anche
altri tipi di istituzioni finanziarie) che decidono di emettere uno strumento
di pagamento come una carta di credito: il nome dell’issuer è tipicamente stampato
sulla tessera, ed è l’issuer a intrattenere i rapporti con il cliente titolare
della carta.
È detta invece acquirer una banca licenziataria della convenzione con i circuiti
internazionali di verifica delle carte di credito; l’acquirer si occupa della
diffusione, installazione e manutenzione dei POS e intrattiene i rapporti con
gli esercenti che accettano carte di credito in pagamento. Un soggetto finanziario
può anche darsi la strategia di essere al tempo stesso issuer e acquirer per
un certo circuito di carte. In questo caso, può realizzare significative economie
di processo quando una transazione avviene con carte e POS entrambi di propria
gestione.
La procedura di pagamento
Il processo attraverso il quale avviene il pagamento per mezzo di carta di
credito si articola in un notevole numero di fasi, rappresentate nella figura
in basso.
Tutto inizia quando il cliente paga il venditore usando la sua carta di credito
(1). Il POS del venditore trasmette (2) i
dati della carta e l’ammontare della transazione alla rete del gestore circuito
carte, che li invia (3) al card issuer per ottenere l’autorizzazione
a procedere (per esempio, in base alla validità della carta e alla disponibilità
di fondi).
In caso di approvazione (4), il POS del venditore riceve (5)
comunicazione che è possibile procedere e stampa lo scontrino che il titolare
della carta dovrà firmare (6) per accettare di effettuare il
pagamento (la firma tradizionale può anche essere sostituita dalla digitazione
di un PIN, tuttavia il concetto non cambia).
Il POS trasmette (di solito a lotti, o alla fine della giornata) le informazioni
sulla transazione (7) all’acquirer che lo ha in gestione; questo
gli permette di corrispondere al venditore i fondi oggetto della transazione
(8).
Avviene poi una fase di calcolo dei flussi fra issuer e acquirer e determinazione
dell’ammontare delle compensazioni eventualmente necessarie a saldo, orchestrata
dal gestore circuito carte. L’acquirer informa periodicamente il circuito dei
dati relativi alle vendite che hanno interessato i suoi POS (9) e
il circuito gira l’informazione ai card issuer competenti (10).
Sempre il gestore del circuito determina la posizione debitoria o creditoria
netta dei vari attori.
Chi risulta essere in posizione debitoria netta (generalmente, si trovano in
questa posizione i card issuers perché le carte di credito vengono usate per
pagare più che per incassare) invierà i fondi dovuti al gestore circuito, che
li trasmetterà (11) agli aventi diritto (in genere, gli acquirers).
Al termine, il card issuer spedisce al titolare della carta un estratto conto
mensile che riporta l’insieme delle transazioni registrate nel periodo di osservazione
(12); il titolare, o la sua banca in caso di domiciliazione
automatica, effettuerà un pagamento a saldo del conto carta.
Come si vede da questo schema, ogni attore interagisce con poche controparti
note e fidate. Per esempio, il titolare della carta ha a che fare soltanto con
il venditore e con chi gli ha rilasciato la carta di credito (l’issuer). Dal
canto suo, il POS del venditore si connette solo al circuito carte per la verifica
e con l’acquirer che lo ha in gestione per la contabilità e la determinazione
periodica dei saldi dovuti. Acquirer e issuer non intrattengono relazioni dirette,
ma interagiscono sempre con la mediazione del gestore circuito carte.
Questo schema di controparti fidate e interfacce limitate fra gli attori contribuisce
a circoscrivere le interazioni e ad assicurare un elevato livello di sicurezza
al sistema. Le transazioni di pagamento rappresentano operazioni di complessità
medio-alta che interessano, come si vede, un gran numero di attori e che lasciano
tracce in più archivi contabili.
La transazione a livello di database
Esse non rappresentano però né l’unico, né il principale tipo di transazioni
elettroniche. Per esempio, l’affidabilità e la coerenza degli archivi contabili
appena citati è ovviamente determinante per il funzionamento del sistema. Per
concorrere ad assicurare tali proprietà, questi archivi sono realizzati con
dei database. Una delle proprietà più importanti dei database è la capacità
di supportare operazioni transazionali.
Il concetto di transazione è centrale anche per un database, e in questo ambito
si definisce transazione un’operazione che lascia il database in uno stato consistente;
ciò si ottiene facendo in modo che sia garantito che quando si esegue sul database
un gruppo di operazioni interdipendenti, queste riescano tutte o falliscano
tutte, ma non possa mai darsi il caso di un successo parziale. Si prenda, per
esempio, il caso di un bonifico da un conto a un altro di una stessa banca.
Dal punto di vista bancario e intuitivo si tratta di un’operazione singola,
ma a livello di database essa si traduce in almeno due operazioni distinte:
per esempio, un addebito di 100 euro sul conto da cui si prelevano i fondi e
un accredito di 100 euro sul conto di destinazione. Se entrambi i conti sono
gestiti dal database della banca, queste due operazioni non sono altro che due
scritture sul database.
Supponiamo che la procedura software che implementa i bonifici preveda di
effettuare prima l’addebito e poi l’accredito, e che per qualsiasi ragione (black
out, errore software o altro malfunzionamento) essa fallisca a metà: si verificherà
un ammanco di 100 euro, in quanto i fondi sono stati sottratti dal primo conto,
ma non sono stati ancora aggiunti al secondo. Se, viceversa, la procedura iniziasse
con l’accredito per poi effettuare l’addebito e fallisse sempre nel bel mezzo
dell’operazione, sarebbero stati inventati dal nulla 100 euro e, ancora una
volta, i conti della banca non quadrerebbero.
Per questa ragione, è necessario un meccanismo che assicuri che l’insieme delle
due operazioni riesca totalmente o fallisca totalmente, escludendo la possibilità
di una riuscita soltanto parziale. Proprio questo meccanismo è offerto dal supporto
del database a operazioni transazionali. Il software richiede al database server
di aprire una transazione, poi esegue nel suo contesto tutte le operazioni necessarie
nella sequenza desiderata, infine richiede un’operazione di commit.
Il database server si fa carico di verificare che tutte le operazioni parziali
riescano: in caso affermativo, il software riceve la conferma che la transazione
è riuscita (interamente); in caso contrario, il database server si occupa di
annullare, a ritroso, gli effetti del sottoinsieme di operazioni già effettuate
e riuscite, fino ad annullare ogni traccia parziale della transazione dallo
stato interno del database (questa operazione si chiama rollback),
e infine si provvede a segnalare al software che la transazione è fallita (interamente).
I principi base che il modello di elaborazione transazionale mira a implementare
sono spesso descritti dall’acronimo ACID, che sta per Atomicità,
Consistenza, Isolamento e Durabilità. L’atomicità assicura che la transazione
riesca o fallisca sempre integralmente, e mai parzialmente. La consistenza riguarda
il fatto che il database si trovi sempre in uno stato “legale”, ossia con dati
coerenti, all’inizio così come alla fine della transazione. L’isolamento è la
proprietà grazie alla quale le transazioni, durante la loro esecuzione, non
risentono di “effetti parziali” prodotti durante la simultanea esecuzione di
altre transazioni.
In altre parole, una transazione in corso non lascia mai il database in uno
stato intermedio che risulti visibile all’esterno. Gli effetti parziali si possono
vedere solo all’interno della transazione che li sta producendo, e solo fino
a quando per la transazione non viene richiesto il commit. La durabilità si
riferisce al fatto che una volta riuscito il commit per una transazione, vi
è la garanzia che i suoi effetti persistano e che il sistema sia in grado, eventualmente,
di replicarli in caso di crash di sistema, basandosi su un registro delle transazioni
riuscite (log) che consente di ricostruire lo stato aggiornato partendo dall’ultimo
backup.
