Nexi Dev Training Program: Nexi SmartPOS

Scopri di più sul programma e iscriviti gratuitamente!

Il commercio oggi non avviene solo online o offline, ma attraverso tutti i mezzi possibili.

Mobile Commerce, Voice Commerce e Conversational Commerce, tra gli altri, sono solo alcuni esempi di quello che viene generalmente chiamato Omni-Channel Commerce. E con le recenti innovazioni come l’internet degli oggetti, il modo in cui i vari sistemi fisici e processi interagiscono tra loro è totalmente diverso dai modi tradizionali di collegare le cose. Questa evoluzione della tecnologia e delle interazioni tra sistemi fisici e virtuali, i comportamenti di acquisto dei clienti e la capacità di costruire esperienze omni-canale richiede un approccio diverso dalla semplice costruzione di API. I sistemi e i componenti della piattaforma Commerce devono essere progettati e costruiti per l’interconnettività, l’interoperabilità e l’estensibilità, consentendo così agli sviluppatori di costruire nuove esperienze di acquisto.

Il Nexi SmartPOS®, prodotto dalla società americana POYNT è tra i device più avanzati nel settore con la possibilità per gli sviluppatori di creare applicazioni dedicate mantenendo sempre un elevato livello di sicurezza. Prima di entrare nei dettagli del Nexi SmartPOS®, esaminiamo i componenti essenziali di un terminale di pagamento e che tipo di ruolo svolgono.

Tradizionalmente i terminali di pagamento sono utilizzati principalmente per l’elaborazione di una transazione di pagamento basata su carta (credito/debito). Essi sono tipicamente costituiti da:

• Card Reader – il componente centrale di un terminale che fornisce tutte le interfacce fisiche e logiche per la lettura delle carte di pagamento (Magnetic Swipe, Chip e NFC).
• Display – per visualizzare le richieste di inserimento dati da parte del cliente/commerciante (come l’importo da addebitare o la richiesta al cliente di inserire il pin o il tipo di pagamento).
• Interfacce hardware esterne – forniscono connettività in/out attraverso varie interfacce fisiche (RJ11/seriale/USB) e di rete (Ethernet/Wifi/Cellulare). Queste interfacce esterne sono l’unico modo per le applicazioni di pagamento di autorizzare i pagamenti e interagire con accessori esterni, come ad esempio una stampante fiscale esterna.
• Stampante – È molto comune nella maggior parte dei terminali di pagamento fornire una stampante integrata per la stampa delle ricevute di transazione.
• Tastiera – una tastiera numerica per l’immissione sicura di PIN, importo e altri dettagli necessari per elaborare una transazione di pagamento.
• Applicazione di pagamento – software che riunisce tutto per consentire a un commerciante di elaborare un pagamento. Organizza il lettore di carte, il display e altre interfacce in base alle esigenze del merchant o dell’acquirente.

Oltre a queste sul terminale stesso, la maggior parte dei fornitori di terminali fornisce alcuni altri servizi/caratteristiche come:

• Gestione Terminale/Stato – questo fornisce un modo per gestire a distanza ogni terminale per la manutenzione, gli aggiornamenti software, l’assistenza tecnica, ecc.
• Gestione della sicurezza – fornisce un modo per gestire le configurazioni dei lettori di carte, le chiavi di crittografia, ecc.

Sfortunatamente, la maggior parte dei terminali li tratta come componenti indipendenti e fornisce un accesso di basso livello ai componenti fisici e logici (quasi a livello di driver del dispositivo nella maggior parte dei casi). Anche se questo sembra molto flessibile per gli sviluppatori, essendo in grado di utilizzare questi componenti in qualsiasi modo essi vogliano, porta le sfide con integrazioni, sicurezza e certificazioni.

Sfide con l’integrazione

Tutti i terminali sono dotati di un sistema operativo (chiamato anche “application controller”) con diversi livelli di programmabilità e accesso alle caratteristiche principali dell’hardware del terminale. In genere tutti forniscono un SDK per gli sviluppatori di applicazioni per costruire le loro applicazioni, che al termine vengono presentate per le certificazioni e le approvazioni prima di poter essere installate su terminali di pagamento reali presso i punti vendita.

Ogni applicazione fornisce un insieme distinto di caratteristiche e sono esposte al commerciante attraverso l’interfaccia del controller dell’applicazione sul terminale. Sfortunatamente non c’è quasi nessuna struttura o interfacce fornite per aiutare queste applicazioni a collaborare tra loro, con il risultato di un lungo elenco di applicazioni completamente autonome. Un esempio di questo è quello che vediamo quando acquistando in un negozio, il commerciante che cerca di selezionare diverse combinazioni di pulsanti per richiamare diverse applicazioni per diverse esigenze (ad esempio, carta regalo vs carta di credito, credito vs debito, ecc.

Sfide per la sicurezza

Le applicazioni che sono costruite per queste piattaforme tipicamente girano all’interno di ambienti sicuri necessari per soddisfare tutti i requisiti di sicurezza del PCI Council, Card Networks e Acquiring Bank.

Purtroppo, sebbene questi requisiti di sicurezza siano essenziali per proteggere le informazioni sensibili sulle carte di pagamento dei consumatori, hanno un costo:

• Requisiti aggiuntivi che aumentano i costi di sviluppo delle applicazioni di pagamento
• Lunghi cicli di collaudo e certificazione

Il tempo prolungato di implementazione rallenta significativamente l’efficacia del rilascio di nuove funzionalità e la mancanza di flessibilità nella gestione del software ha un forte impatto sul ciclo di sviluppo del software.

Sfide con le certificazioni

Come accennato in precedenza, ogni terminale di pagamento deve passare attraverso una lunga lista di certificazioni necessarie alle varie organizzazioni normative e finanziarie prima di poter operare in un punto vendita per elaborare le transazioni.

Queste includono certificazioni che sono tipicamente chiamate certificazioni L1 (hardware e livello di comunicazione per Contact e Contactless), L2 (EMVCo per Contact e per ogni rete di pagamento per Contactless), e, non ultimo, un altro lungo ciclo di certificazione con ogni acquirer con cui l’applicazione di pagamento in esecuzione sul terminale si integra.

Questi processi di certificazione richiedono l’accesso a strumenti di test aggiuntivi (solitamente piuttosto costosi) per eseguire e valutare tutti i casi di test definiti dalle reti di pagamento prima di presentare le necessarie approvazioni.

Costruire la piattaforma

Con le sfide a portata di mano e l’obiettivo di consentire integrazioni più semplici ed esperienze integrate, l’approccio del Nexi SmartPOS® è iniziato con la scomposizione dei componenti hardware e software in diversi livelli di astrazione, esponendo le funzionalità come API in base alle esigenze di integrazione eseguendo alcuni principi fondamentali:

• API per ogni componente del terminale (API First) – questo va dal rendering di un messaggio personalizzato dell’interfaccia utente sul display, all’elaborazione di una transazione attraverso il processore.
• I dati e le API si estendono oltre il terminale – disponibili come semplici interfacce esterne RESTful per qualsiasi altro sistema o applicazione che ne abbia bisogno.
• L’interoperabilità sia all’interno delle applicazioni che con i componenti esterni è un must.
• Nessuna integrazione personalizzata 1:1 tra le applicazioni.
• Sicurezza integrata.
• Facilità di integrazione – non sono necessari strumenti personalizzati; gli sviluppatori dovrebbero essere in grado di utilizzare i moderni strumenti di sviluppo e risoluzione dei problemi più comunemente utilizzati.

Utilizzando questi principi, sono stati definiti i seguenti servizi di base per astrarre le funzionalità come appropriato:

Card Reader Service – invece di fornire l’accesso a interfacce di basso livello per il lettore di carte che darebbero accesso ai dati sensibili della carta a tutti, sono state create API funzionali per elaborare i dati della carta in base alle esigenze dell’applicazione. Ciò include l’esecuzione di una transazione con carta per elaborare un pagamento, la lettura di una carta di non pagamento per fedeltà e altri casi d’uso. Tutti i dati sono criptati all’interno dei servizi di lettura della carta, evitando completamente l’esposizione di qualsiasi dato sensibile alle applicazioni e quindi la necessità di una conformità PCI.

Commerce Services – forniscono il supporto per le varie funzionalità relative al commercio come la gestione degli ordini, la gestione delle transazioni, la gestione dei clienti, cataloghi/prodotti, ecc. e anche una rappresentazione coerente delle varie risorse dati relative al commercio. Questi servizi per il commercio diventano anche il punto di integrazione centrale per tutte le applicazioni in esecuzione sul terminale per interagire tra loro al servizio di vari aspetti di un’attività commerciale.

Payment Experiences – forniscono un’esperienza standardizzata per tutti i metodi di pagamento ed eliminano l’inutile onere di certificazioni di pagamento ripetute per ogni integrazione.

Accessory Management Service – fornisce un elenco di vari servizi che gestiscono la connettività agli accessori esterni (stampanti, bilance, cassetti di cassa, registratori di cassa, ecc) collegati al terminale e un modo più semplice per interagire con loro. Diversi API Contracts sono definiti per diverse tipologie di accessori. Ad esempio, un’interfaccia accessori per cassetto cassa ha semplici metodi “open()” e “isOpen()” piuttosto che un comando USB di basso livello per inviare uno specifico valore di byte grezzo per aprire un cassetto allegato.

Accessory Management Service – fornisce un elenco delle varie capability installate sulle piattaforme e la possibilità di collegarle e utilizzarle. Le funzionalità includono l’elaborazione delle transazioni, la stampa delle ricevute, le carte fedeltà, i buoni sconto, la gestione dei clienti, ecc. La gestione delle capability gioca il ruolo più importante nell’interoperabilità tra le varie applicazioni in esecuzione sul terminale.

External Connector Service – fornisce un’interfaccia per esporre la maggior parte delle interfacce disponibili sul terminale ad applicazioni esterne collegate tramite USB, BT o rete.

Cloud Services – fornisce le interfacce necessarie per estendere i servizi sul terminale oltre il terminale stesso. Questi servizi forniscono l’accesso alle stesse funzionalità e, cosa ancora più importante, l’accesso agli stessi dati commerciali tramite cloud, fornendo un accesso più facile alle applicazioni in esecuzione nel cloud. Il servizio Cloud fornisce anche la necessaria gestione della configurazione per vari componenti come il lettore di schede, la gestione delle chiavi di sicurezza, ecc.

Per illustrare come questi componenti si uniscono dal punto di vista dell’implementazione e dell’integrazione, esamineremo un flusso di transazioni di pagamento end-to-end sul Poynt Smart Terminal e successivamente la creazione di una applicazione per la gestione degli ordini.

Sul Terminale, ogni transazione inizia da un’applicazione che l’esercente sta utilizzando per gestire la propria attività. Il seguente diagramma di flusso vi guida attraverso i vari passaggi e fasi di una transazione di pagamento sul Poynt Smart Terminal. Le chiamate evidenziate in rosso indicano le API funzionali fornite dai servizi corrispondenti.

Mentre questo sembra un processo lungo, alcuni importanti insegnamenti che vorrei richiamare sono:

• API funzionali – riducono enormemente lo sforzo di integrazione attraverso l’astrazione ad alto livello.
• Service Discovery – essere in grado di scoprire i servizi disponibili sul terminale aggiunge la flessibilità di trovare un servizio appropriato che meglio si adatta alle esigenze dell’applicazione. Che si tratti di un servizio per inviare e-mail, o di un servizio per elaborare una transazione, o di un servizio per rendere una schermata specifica per raccogliere dati dal consumatore – la possibilità di scoprire e connettersi programmaticamente non solo aggiunge un valore significativo per gli sviluppatori di applicazioni e fornisce anche una buona piattaforma per l’estensibilità.
• Modelli di risorse – mentre le API per ogni componente possono differire in termini di formati di protocollo in base al tipo di componente/servizio, fornire e mantenere modelli di dati coerenti tra loro gioca un ruolo molto importante per l’interoperabilità. Questo non solo aiuta a far passare i dati attraverso diverse API senza richiedere molte trasformazioni, ma aiuta anche ad estendere i modelli di dati come API RESTful per le applicazioni in esecuzione nel cloud.
• API standardizzate per l’interoperabilità – mentre il Service Discovery fornisce un modo piacevole per trovare i servizi disponibili quando è necessario, essi aggiungono poco valore quando si tratta di integrazione se le loro interfacce di servizio non sono standardizzate e predefinite dalla piattaforma. Definire e fornire il framework per le interfacce standard per tutte le possibili capability e servizi accessori della piattaforma è un passo necessario per l’estensibilità della piattaforma. Non c’è modo di prevedere le esigenze e le caratteristiche di ogni possibile capacità e accessorio – quindi è molto importante mantenere un processo aperto per questo per consentire agli sviluppatori un ecosistema che li aiuti a definirli.

Mentre l’approccio API-First è un passo necessario in qualsiasi azienda o prodotto, concentrarsi su come sistemi e applicazioni (sia interne che esterne) si integrano e interagiscono tra loro è essenziale per il successo di qualsiasi piattaforma.

Vediamo come questi concetti si applicano allo sviluppo di una applicazione per la gestione degli ordini tramite una applicazione di gestione nativa.

Un’applicazione nativa di gestione dell’ordine può essere costruita per lavorare con Poynt. Ecco i passi da seguire:

1. Implicit Authorization, tramite l’inserimento dei seguenti permessi nel manifest della nostra App Android

a. Order Service: poynt.permission.ORDER_SERVICE
b. Customer Service: poynt.permission.CUSTOMER_SERVICE

Quando un merchant abilita l’ App, questi permessi sono implicitamente abilitati

2. Creazione di un client (esempio di chiamata e risposta)

Esempio Chiamata

Esempio Risposta

Il valore “id” (in questo caso 45494460) corrisponde all’ID cliente. Questo valore può essere passato all’ordine per visualizzare i dettagli del cliente.

3. Creazione di un ordine (esempio di chiamata e risposta)

Esempio Chiamata

Esempio Risposta

A questo punto l’Ordine è stato creato con successo. Un messaggio Poynt Cloud viene inviato al terminale per l’ordine appena creato.

4. Sottoscrizione all’interno del Activity della applicazione agli Intent di tipo “ORDER DETAILS INTENT”

5. Quando un utente tappa sulla notifica di ordine sul terminale, un Intents.ACTION_GO_TO_ORDER_DETAILS può essere intercettato per creare una view di dettaglio custom all’interno dell’applicazione.

Questo esempio mostra come si può gestire in modo semplice la notifica di un nuovo ordine, garantendo allo stesso tempo sicurezza e integrità delle informazioni.