Come avviamo le transazioni dei punti vendita a livello globale

Attualmente, i pagamenti presso i punti vendita rappresentano ancora la maggior parte del volume globale. Eppure la quasi totalità dei sistemi per punti vendita sono obsoleti e ingombranti, richiedono notevoli costi di installazione e non consentono di implementare rapidamente nuove funzionalità. Come sviluppatori POS di Adyen, di recente abbiamo adottato una nuova API per semplificare la configurazione deipagamenti POS.

La maggior parte delle configurazioni POS comprende un registratore di cassa (gestito dal personale del negozio) unterminale di pagamento(in cui il cliente inserisce la carta) e una connessione seriale tra i due. Nel registratore di cassa è incorporata una libreria che facilita la comunicazione tra il registratore stesso e il terminale di pagamento. In genere, queste librerie sono create e gestite dall'azienda che fornisce i terminali, come Adyen.

L'utilizzo delle librerie implica una serie di problemi:

Un'integrazione profonda tra il registratore di cassa e la libreria richiede una notevole quantità di lavoro di configurazione e sviluppo, perché la libreria sarà inclusa nel software del registratore di cassa.

Inoltre, molti grandi rivenditori al dettaglio preferiscono adottare soluzioni centralizzate per il software di cassa. Ciò significa che il software deve essere configurato in modo da avviare una transazione su un terminale di pagamento nel negozio instradando le richieste dal centro dati alla rete del negozio. Per fare questo, i commercianti devono utilizzare il port forwarding per gestire i pagamenti in più sedi, un IP fisso per ciascun terminale o eventualmente una configurazione VPN per la sicurezza. Tutte queste possibilità comportano una complessa configurazione di rete che prosciuga le risorse operative.

Idealmente, avevamo bisogno di una soluzione che fosse indipendente da qualsiasi piattaforma specifica, in grado di essere utilizzata per le connessioni seriali, la rete locale e i trasferimenti via internet, e che supportasse un formato di messaggio con funzionalità avanzate come le notifiche asincrone.

Per rispondere a questi requisiti, abbiamo eliminato la necessità di librerie e creato Terminal API adottando il protocollo Nexo: uno standard di pagamento con carta che facilita la comunicazione tra il registratore di cassa e il terminale.

Il modello di interazione di base di Nexo si fonda sui messaggi di richiesta/​risposta JSON. Ciò significa che un pagamento con Terminal API comporta l'invio di messaggi di richiesta-risposta e tutti gli eventi informativi, come la notifica della fase del processo di pagamento in cui si trova il terminale, vengono comunicati tramite i webhook JSON eventualmente implementati.

L'utilizzo di questo approccio è vantaggioso per i seguenti motivi:

L'utilizzo di Terminal API nella rete dei negozi è stato un ottimo primo passo. Tuttavia, non ha risolto il problema posto dal disporre i pagamenti da un luogo centralizzato come un centro dati.

Per semplificare l'investimento nella configurazione ed eliminare i costi di tutta questa complessità, abbiamo anche adattato il nostro Terminal API per il cloud. L'architettura dei punti vendita faceva affidamento sul registratore di cassa e sul backend del commerciante per comunicare con il terminale, come indicato di seguito:

Nella versione cloud dell'API, abbiamo aggiunto la possibilità per il commerciante di avviare un pagamento sul terminale direttamente con il backend di Adyen.

Uno dei vantaggi delle connessioni seriali è che offrono una comunicazione bidirezionale, per cui sia il registratore di cassa che i terminali di pagamento possono avviare la comunicazione e lo scambio di dati relativi allo stato della transazione. Con il nostro Terminal API in rete, le transazioni diventano messaggi di richiesta e risposta https. Il registratore di cassa avvia una richiesta di pagamento inviando una richiesta https al terminale.

Tuttavia, su internet, disporre di un canale in cui entrambe le parti possono avviare la comunicazione è complicato, in quanto i terminali "NATed" non possono essere raggiunti senza aprire il firewall e configurare il port forwarding. Ci serviva una soluzione in grado di abilitare facilmente la comunicazione bidirezionale e l'abbiamo trovata nel protocollo WebSocket. Questa tecnologia viene utilizzata da diverse piattaforme per le notifiche push, come ad esempio nei feed delle notizie, e l'abbiamo sfruttata per la comunicazione tra i terminali e il backend di Adyen.

Per consentire la comunicazione bidirezionale, abbiamo creato una singola richiesta https dal terminale di pagamento e abbiamo aggiunto intestazioni per richiedere un aggiornamento della connessione a un WebSocket, come mostrato di seguito. A questo punto, abbiamo stabilito un canale di comunicazione bidirezionale tra il nostro backend e il terminale di pagamento.

Un flusso standard avviene come segue:

​La ridondanza è un fattore chiave nella nostra architettura di sistema. È importante che le transazioni non vengano influenzate dagli aggiornamenti delle applicazioni o dalle operazioni di manutenzione. Il nostro layer per l'accettazione dei pagamenti è costituito da più server in più centri dati in tutto il mondo. Questo aiuta a ridurre la latenza e a garantire la ridondanza. (Nota: per maggiori informazioni sul nostro approccio alla ridondanza e alla configurazione dei database consulta: ​Updating a 50 terabyte PostgreSQL database)

Questa infrastruttura garantisce la ridondanza e la possibilità di bilanciare i carichi in caso di necessità di manutenzione. Tuttavia, solleva un'altra questione: cosa succede se un terminale avvia una connessione con il server A e un registratore di cassa la apre con il server B? La nostra configurazione prevede che se un terminale si connette al server A, viene attivato un messaggio da quel server ad altri server che dice “Ora sono connesso con questo terminale”. Se un registratore di cassa si connette al server B, questo può cercare quale server dispone della connessione WebSocket e instradare il messaggio attraverso quel server.

Se dobbiamo effettuare aggiornamenti dell'applicazione oppure operazioni di manutenzione su un server, questo invia un messaggio al terminale in modo che si riconnetta ad un altro server. Una volta interrotte tutte le connessioni, possiamo iniziare.

Il nostro Terminal API semplifica l'implementazione e fa in modo che i commercianti siano in grado di stare al passo con gli ultimi aggiornamenti del software. Tuttavia, ci sono modi più innovativi in cui può essere utilizzato. Ad esempio, poiché i pagamenti in negozio possono essere avviati da remoto, i commercianti potrebbero creare un'esperienza in cui un cliente avvia un ordine in-app, entra in un negozio, scansiona un codice QR con il proprio telefono per disporre il pagamento sul terminale e ritira l'articolo acquistato. Queste possibilità ci incuriosiscono molto e non vediamo l'ora di scoprire in che modo i commercianti utilizzeranno questa tecnologia.

Per maggiori informazioni sul nostro Terminal API, consulta la documentazione sulla sua integrazione e l'articolo nel blog sui vantaggi commerciali che offre: “Presentazione di Terminal API”.