La frontiera dei pagamenti elettronici vede nell’IoT una delle sfide più importanti e l’In-Things Purchase, di cui si è trattato in un precedente articolo a firma di Giovanni Miragliotta e Antonio Capone, Responsabili Scientifici Osservatorio Internet of Things del Politecnico di Milano, dovrà trovare supporto in forme di pagamento appropriate per i vari scenari d’uso, che coinvolgono gli oggetti smart.
Con In-Thing Purchase si definisce un acquisto che, effettuato direttamente nel corso dell’interazione con un oggetto intelligente connesso, ne attivi extra-funzionalità o extra-servizi che potenziano il valore del proprio utilizzo.
In uno scenario siffatto, appare necessario osservare due aspetti trasversali a qualsiasi use case: identità (dell’oggetto) e pagamento. In estrema sintesi, gli oggetti interconnessi devono poter(si) identificare e compiere pagamenti in autonomia. Nel processo di ordine e approvvigionamento si potrà inserire un sistema di autorizzazione. La transazione di pagamento dovrà essere garantita, non ripudiabile ed avere valore liberatorio. Una puntale disamina del “as is” ci permette di entrare nel dettaglio di ciò che, oggigiorno e in una prospettiva di breve termine, viene rappresentato nella Fig.1
L’identificazione di uno smart-object negli scenari attuali e in una prospettiva di breve termine
Per quanto attiene alla necessità di identificazione (parte sinistra della Fig.1), l’oggetto intelligente può avere una propria identità “ereditata” dal soggetto che possiede uno (o più) strumenti di pagamento, siano essi carte di credito piuttosto che conti correnti da cui avviare bonifici (anche istantanei) o sui quali ricevere addebiti diretti.
Per realizzare in concreto questa fase è necessario che avvenga un processo di autenticazione del soggetto pagatore nel momento in cui l’oggetto gli viene associato [1]. Il pagamento sarà avviato ed eseguito nel rispetto di quanto previsto in materia di Strong Customer Authentication, come disposto dall’impianto normativo in tema di servizi e pagamenti elettronici che in Europa è definito dalla direttiva 2366/2015 (altresì nota come “PSD2”) e dalle regole tecniche sulla sicurezza e l’autenticazione di EBA (European Banking Authority) recepite nel regolamento delegato UE 2018/389.
Sebbene teoricamente fattibile, la possibilità di collegare l’identità di uno smart-object all’identità digitale di un soggetto in possesso di uno strumento quale quello reso disponibile (in Italia) da SPID, o, in un contesto sovranazionale offerto da un soggetto fiduciario (IDP – Identity Provider) eIDAS compliant, non è ancora implementata (parte sinistra in basso della Fig.1).
A onor del vero, stante l’attuale mancanza della gestione di attributi qualificati che potrebbero facilitare l’impiego transazionale di uno strumento di pagamento sincrono rispetto al processo di autorizzazione, ponendo le basi per la realizzazione del modello “I am, then I pay” descritto dall’autore di questo articolo nel lontano 2014, assegnare un’identità ad un oggetto intelligente partendo dall’identità digitale del possessore avrebbe ben poco senso. Ogni qualvolta lo smart-object avviasse una transazione di In-Things Purchase, infatti, dovrebbe iniziare un processo di selezione dello strumento di pagamento adottabile. Una procedura, questa, che non può essere ovviamente eseguita dall’oggetto in autonomia.
Il pagamento di uno smart-object negli scenari attuali e in una prospettiva di breve termine
Guardando alla sola componente transazionale del pagamento “iniziato” da uno smart-object (parte destra della Fig.1), negli scenari di In-Things Purchase gioca un ruolo estremamente promettente un processo chiamato “tokenizzazione”, al momento applicato ai soli strumenti basati su carda (credito debito o prepagata).
Il token, valore surrogato del PAN (Primary Account Number) ovvero il numero identificativo della carta di pagamento, può essere generato dal titolare della carta e attribuito ad uno specifico oggetto, consentendo al medesimo di operare secondo i paradigmi descritti nell’articolo di Miragliotta e Capone, per un trasferimento di fondi finalizzato al compimento di un acquisto presso un soggetto deputato alla vendita. Nella attualità tecnologica che stiamo descrivendo, è importante osservare che tale interazione viene facilitata quando l’operazione di In-Things Purchase si realizza con un’entità (meglio, una “legal entity”) che è già identificata e nota, ovvero possiede un’identificazione che le attribuisce lo status di soggetto economico autorizzato all’intermediazione commerciale. Mutuando dal settore dell’eCommerce, può essere un merchant o un marketplace, piuttosto che il brand stesso legato al “veicolo” o “contenitore” dello smart-object (p.e. esempio la marca di automobili o il rivenditore dei servizi/prodotti aggiuntivi per una macchina fotografica).
Tale precisazione è utile poiché, come si vedrà nel seguito, la transazione di pagamento con un token associato a una carta di credito avviene allorché il merchant (ossia la controparte della relazione commerciale instaurata dall’oggetto intelligente) è convenzionato da un acquirer; processo, quello di convenzionamento, che esclude la possibilità di contrattualizzare “qualcuno” che non abbia una partiva IVA e/o un’iscrizione alla camera di commercio. In pratica, viene al momento preclusa la possibilità di convenzionare “qualcosa” – più che “qualcuno” – che, negli scenari di sviluppo strategico descritti più avanti, potrebbe indicarsi come un’entità algoritmica o, se si preferisce, un agent di Intelligenza Artificiale.
In parole più semplici, vediamo cosa succede, oggi, nella pratica di impiego dei token di pagamento.
Prendendo ad esempio il caso illustrato nella matrice disegnata da Miragliotta e Capone di On-off purchase per Extra Product Feature relativo a una macchina fotografica, il percorso di acquisto, rectius di In-Things Purchase, avviene in (almeno) quattro step, così schematizzabili:
- Assertion: è la fase in cui l’oggetto connesso si identifica e viene riconosciuto nei confronti del rivenditore di filtri/obiettivi. Visto che parliamo di oggetti che comunicano, la macchina fotografica è come se dicesse queste parole: “Buongiorno [rivenditore di filtri/obiettivi], sono la macchina fotografica xyz”.
- Event trigger 1: nel passaggio successivo, l’oggetto segnala con un alert che qualcosa è successo, ovvero che il proprietario dell’apparecchio ha dimostrato la volontà di estendere le funzionalità del prodotto, comunicando un’intenzione di acquisto, di fatto un ordine, denominata action: “Il proprietario della macchina fotografica vuole estendere funzionalità prodotto, ergo voglio sbloccare dette funzionalità”.
- Payment: questo è il punto cruciale in cui avviene, tramite il token, una pre-autorizzazione al pagamento; è ancora l’oggetto che fa una richiesta: “Voglio pagare”.
- Event trigger 2: il processo si conclude con lo sblocco della funzionalità aggiuntiva (che può avvenire anche in un secondo momento per via di possibili latenze dipese dalla rete di trasmissione), momento in cui avviene la conferma del pagamento, “All’attivazione della funzionalità aggiuntiva, pago”: questo è l’istante in cui il merchant di riferimento, in questo caso il rivenditore di filtri e obiettivi, fa processare il token all’acquirer con cui ha contrattualizzato un convenzionamento e incassa (o incasserà, funzione delle condizioni stipulate nel contratto di acquiring) il pagamento.
Il token, dunque, è la “credenziale digitale” con cui viene facilitato il pagamento sicuro da parte di un oggetto connesso; “sostituto” del PAN di una carta di pagamento, può essere usato in sua vece, evitando il rischio legato al passaggio di dati sensibili e riservati.
Il token può avere una durata definita (dal titolare della carta) e può essere, eventualmente, abbinato ad un determinato merchant, circoscritto per un determinato tipo di prodotto.
Per poter consentire l’impiego dei token nell’In-Things Purchase è necessario che il proprietario della macchina fotografica (per riprendere l’esempio poc’anzi presentato) si autentichi con il portale dell’Issuer (potrebbe essere, anche in questo caso, l’accesso ad un’area specifica dell’home banking della banca issuer); è in questa fase che l’associazione token-oggetto avviene.
Naturalmente, il portale dell’issuer (o l’area specifica nell’home banking della banca emettitrice) dovrà offrire una gamma di servizi aggiuntivi che permettano di gestire l’intero life-cycle del token: blocco, sblocco, revoca, cambio di eventuali limiti di importo, modifica del perimetro di spendita del token (ad esempio si vuole includere nuovi rivenditori di filtri e obiettivi, oppure si vuole escludere taluni che in precedenza non hanno soddisfatto le aspettative) e così via.
Parimenti, il medesimo portale dovrà permettere una rendicontazione delle spese e segnalare eventuali impieghi non corretti del token.
Osservando in dettaglio la parte destra della Fig.1, notiamo che oggigiorno esistono diverse iniziative nel settore dei token sia nei contesti di standardizzazione (EMVco, PCI, …) sia in quelli di offerta off-the-shelf, come è il caso di Mastercard con la propria soluzione Mastercard Digital Enablement Service (MDES), oppure di Visa con Visa Token Service (VTS).
Il token dell’IBAN e le opportunità offerte dai TPP
Un’evoluzione piuttosto interessante nel settore della tokenizzazione, riguarda l’opportunità di associare un token a un IBAN (del pagatore) da impiegare in quei contesti d’innovazione abilitati dalla già menzionata PSD2 che si delineano con i cc.dd. “Servizi di accesso ai conti”. In particolare, questo potrebbe essere un ambito di applicazione dei nuovi TPP (Third Party Payment Services Provider) autorizzati ad operare in qualità di PISP (Payment Initiatior Services Provider), che consentono di avviare bonifici (anche istantanei) intermediando la relazione tra pagatore (ossia il proprietario della macchina fotografica, per riprendere l’esempio di cui sopra) e la banca presso cui è radicato il proprio Conto Corrente. Uno scenario, questo, peraltro fortemente “coopetitivo”, attesa la necessità di collaborazione tra banca presso cui sono radicati i C/C dei pagatori e PISP che vuole giocare il proprio ruolo nel mercato delle soluzioni di In-Things Purchase.
La qualità del token e le opportunità offerte da SPID
Concludiamo questa prima parte dell’articolo osservando un problema di “qualità” del token, intesa come garanzia dell’associazione titolare effettivo della carta (o correntista) – token. Necessario è infatti precisare come, in assenza di un sistema d’identificazione e verifica del reale possessore della carta (o dell’intestatario del Conto Corrente), il token, che, è bene ricordarlo, è sempre generato su iniziativa del possessore del “veicolo” o “contenitore” dello smart-object, potrebbe non necessariamente riflettere l’identità del titolare legittimo.
In tale direzione potrebbe rendersi utile un sistema quale SPID (per ritornare alle prime riflessioni sull’identità dell’oggetto), impiegato per autenticare il possessore del “veicolo” o “contenitore” dello smart-object nel momento in cui volesse generare uno (o più) token da associare ai propri oggetti intelligenti.
L’evoluzione degli scenari d’innovazione dell’In-Things Purchase
Nella seconda parte di questo contributo analizzeremo alcuni scenari d’innovazione dell’In-Things Purchase, presentando le opportunità che consentirebbero di realizzare appieno il c.d. “Embedded Commerce”, una declinazione, questa, che, prendendo spunto dall’articolo di Miragliotta e Capone, non deve confondersi con l’“Embedded purchase”, ma che invece, ad opinione di chi scrive, pur basandosi sullo stesso framework dell’In-Things Purchase, potrebbe rappresentarne un’estensione in quei contesti dove lo smart-object è in grado di eseguire operazioni evolute di trading.
Sono scenari, quelli che vedremo, sviluppabili in una previsione temporale di medio termine, che potrebbero alimentare due trend socio-economici in forte crescita in questi anni: la sharing economy (o, meglio ancora, la “smart sharing economy”) e la prosumer economy.
Bibbliografia e sitografia
- “Come usare al meglio l’Internet delle Cose”, M. Casani – M. Majonchi, Tecniche Nuove, gennaio 2017;
- “Tutto su blockchain”, R. Garavaglia, Hoepli, aprile 2018;
- “Dall’In-App Purchase all’In-Things Purchase: l’App economy si estende alle cose”, G. Miragliotta – A. Capone, Internet4Things.it, 14/1/2019;
- “eIDAS: un regolamento Europeo per le Identità Digitali interoperabili … ma non solo”, R. Garavaglia, PagamentiDigitali.it, 23/9/2014;
- “Apple Pay, ma è vera innovazione?”, R. Garavaglia, Cor.Com, 18/11/2014.
NOTE
[1] Di norma tale processo avviene registrando lo smart-object tramite l’accesso autenticato all’home banking della banca presso cui il Conto Corrente è radicato.
