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.

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.