Come avviene una transazione elettronica

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,
come Amazon o eBay. 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.

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’arcinoto 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. 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.

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.

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.