Progettare e realizzare un sistema di (micro)pagamenti
Monetizzare il mio blog con caffè, Apple Pay e Mollie
- Pubblicato
- Aggiornato
- (creato )
- Scritto da
- Willem L. Middelkoop
- Argomenti
- Amsterdam · design · iPad · lemmid-store · denaro · pagamenti · programmazione · server · tablet · vim · lavoro
- Versione umana di questo articolo
- https://willem.com/it/2020-03-25_progettare-e-realizzare-un-sistema-di-micro-pagamenti/
- English
- Designing and implementing a (micro) payment system
- Nederlands
- Het ontwerpen en implementeren van een (micro)betaalsysteem
- Deutsch
- Design und Implementierung eines (Mikro-)Zahlungssystems
- Español
- Diseño e implementación de un sistema de (micro)pagos
- Français
- Concevoir et mettre en place un système de (micro)paiement
- Português
- Conceber e implementar um sistema de (micro)pagamentos
- Papiamentu
- Desèño i implementá un sistema di pago (mikro)
- Frysk
- In (mikro)betelsysteem ûntwerpe en ymplemintearje
- Lingue
- Tradotto dall’originale inglese da un modello linguistico in due passaggi (traduzione e correzione) con un glossario e un controllo ortografico; non ancora letto da un madrelingua.
Riassunto
I pagamenti online sono più importanti che mai ora che il virus COVID-19 mette in crisi le aziende. Questo spinge i miei clienti a cercare nuovi modi per guadagnare online. Io ho progettato e realizzato un sistema di (micro)pagamenti. Questo articolo parla di come arrivare alla semplicità risolvendo sfide complesse.
Testo completo
Capire la nuova tecnologia
Quando sviluppo nuove tecnologie e nuove app cerco sempre di immaginare come funzionerebbero al meglio. Il modo più semplice per scoprirlo è progettare il prodotto per te stesso. Proprio come Steve Jobs ha fatto sviluppare ad Apple la sua app per le presentazioni, Keynote, per sé. È una delle sue battute famose sul fatto di essere un beta tester sottopagato

Se progetti il prodotto per te stesso, pensa a cosa vorresti davvero, davvero. Per me significa il modello di interazione più semplice in assoluto: voglio che il mio software sia semplice, facile.
Caso d'uso: offrimi un caffè
Per sviluppare la tecnologia di pagamento mi sono inventato un caso d'uso: aggiungere al mio sito un pulsante "offrimi un caffè". Se funziona bene, chi vuole può usarlo per dimostrare il proprio apprezzamento per questo blog offrendomi un caffè. Secondo me questo caso d'uso è la sfida perfetta per progettare (e costruire) un sistema di (micro)pagamenti.
Schizzare le idee
Prima di scrivere una sola riga di codice, spesso progetto il software schizzando le idee a mano. Trovo che il processo creativo del disegno aiuti a esplorare idee, layout, processi. È uno dei motivi per cui mi piace tanto lavorare su un tablet: schizzare le idee in digitale mi permette di esplorarne molte copiando e incollando in più iterazioni.

Prototipo
Quando hai esplorato le idee per la tua interfaccia utente, è il momento di sviluppare un prototipo. Con un prototipo puoi provare l'interfaccia su dispositivi diversi e vedere che aspetto e che sensazione dà.

Durante la prototipazione guardo spesso lo schizzo del progetto mentre programmo la prima versione. Su iPad puoi farlo con lo schermo diviso: metto lo schizzo accanto al mio codice, scritto con VIM in tmux tramite Mosh con la fantastica app Blink per iPadOS. La tazzina di caffè l'ho disegnata con Picta Graphic for iPad, una bellissima app di disegno che esporta immagini vettoriali (SVG).

Sviluppo del frontend
Il passo successivo è sviluppare un'interfaccia utente pienamente funzionante, facendo lavorare i pulsanti. Durante lo sviluppo spesso devi capire cosa sta succedendo, rintracciare i bug e mettere a punto i meccanismi. Io uso Inspect Browser per iPadOS, così ho una piccola interfaccia touch funzionante proprio accanto al mio codice. Mi permette di provare e perfezionare l'interfaccia in fretta.

Sviluppo del backend
Un altro passo fondamentale è sviluppare la tecnologia di backend che prepara e tiene traccia dei pagamenti online. È tecnologia lato server che gestisce la comunicazione tra l'interfaccia utente (il sito) e il fornitore di pagamenti (banche, carte di credito, Apple Pay, ecc.).
Progettare il server di backend è di solito un po' più astratto che progettare un'interfaccia (visibile). Trovo molto utile schizzare diagrammi di sequenza UML per capire quali chiamate API devono avvenire e in che ordine. I diagrammi di sequenza mostrano le interazioni di un programma nel tempo.

Nel diagramma di sequenza del processo di pagamento vedi tre colonne: frontend, backend e fornitore di pagamenti. Ogni colonna è un computer diverso che comunica con gli altri. Il frontend gira sul dispositivo dell'utente, il server di backend gira su un VPS gestito da me e il fornitore di pagamenti è un server esterno. L'utente interagisce con il sito cliccando sul pulsante "offrimi un caffè", e questo avvia una catena di chiamate API che scorre da destra a sinistra.
Il "server di backend" si occupa di calcolare l'importo che l'utente deve pagare. Il calcolo avviene sul server e non nel client, per evitare che utenti malintenzionati manipolino il prezzo (la tecnologia di frontend si può manipolare dal browser).
Una sessione di pagamento si prepara informando il fornitore di pagamenti che l'utente effettuerà un pagamento di un certo importo. Per farlo si usa una chiave API segreta, che permette al fornitore di sapere su quale conto bancario vanno accreditati i pagamenti. Il fornitore restituisce un URL di pagamento, che serve a reindirizzare l'utente alla vera pagina di pagamento.

Il fornitore di pagamenti che uso è Mollie, un'azienda con sede ad Amsterdam e una piattaforma di pagamento fantastica. Le loro API sono ben documentate e offrono dei pacchetti per integrare facilmente il loro sistema di pagamento nel tuo server di backend.

In armonia con i miei altri server di backend, ho scelto di realizzare questo server in NodeJS. Gira praticamente su tutto (da un minuscolo Raspberry PI a grandi cloud di calcolo). In alternativa puoi usare PHP, Ruby, Python o uno degli altri pacchetti disponibili. La Mollie API reference offre informazioni dettagliate sui valori che puoi aspettarti.
Aggiornamenti asincroni dello stato del pagamento
Pochi si rendono conto che recuperare lo stato di un pagamento è un processo asincrono, con stati diversi. In un mondo perfetto sapresti subito se un pagamento è riuscito o fallito. Ma a causa della natura distribuita dei pagamenti online, in cui i backend comunicano con server diversi (banche, carte di credito, ecc.), non sai mai con precisione quando un pagamento verrà completato.
Pensa a quando un utente chiude la pagina di pagamento, lascia il dispositivo incustodito, o a quando una banca ha un'interruzione del suo sistema di home banking. Succede, ed è compito tuo progettare il server di backend in modo che gestisca gli aggiornamenti di stato separatamente dal processo principale di interazione con l'utente.

Il fornitore di pagamenti chiama un webhook sul nostro server di backend. Consegna un messaggio del tipo "Guarda, è cambiato qualcosa nel pagamento XYZ". Il messaggio dice solo che qualcosa è cambiato, non quale sia il nuovo stato. Lo fa per motivi di sicurezza: altrimenti utenti malintenzionati potrebbero imitare la chiamata al nostro webhook. Il nostro server di backend, invece, chiede lo stato reale del pagamento attraverso un canale sicuro, usando la nostra chiave API segreta. Il fornitore restituisce lo stato del pagamento, che poi viene gestito dal nostro server. A seconda dello stato si intraprendono le azioni adatte, come inviare notifiche via e-mail o avviare la consegna della merce.
Fullstack: unire frontend e backend
L'ultimo passo è collegare il frontend con la tecnologia di backend, in modo che l'intero processo funzioni. È quello che si chiama "sviluppo fullstack", perché lavori sull'intero sistema. Lo sviluppo fullstack è un'arte diversa, che pochi sviluppatori padroneggiano davvero: devi lavorare (fare debug e sviluppare) su più fronti contemporaneamente, spesso in linguaggi di programmazione diversi allo stesso tempo!
Nella pratica significa tenere d'occhio le varie parti del programma e vedere se funzionano bene insieme. Guardi i log del server mentre cerchi di fare un pagamento con il frontend appena creato. È dura, ma è anche molto gratificante, perché il risultato è un prodotto funzionante!

Il pulsante "offrimi un caffè" che ne risulta è, per l'utente, un processo ingannevolmente semplice in 3 passi:
- passo 1: clicca un semplice pulsante "offrimi un caffè", niente complicati moduli d'ordine, niente irritanti codici captcha: solo un pulsante
- passo 2: l'interfaccia si espande sul posto, mantenendo il contesto e offrendo la possibilità di lasciare un messaggio o di offrirmi più tazze di caffè. Inoltre, gli altri elementi dell'interfaccia, come i pulsanti dei social media, vengono nascosti automaticamente per mettere a fuoco l'interfaccia del caffè
- passo 3: la schermata del fornitore di pagamenti permette all'utente di pagare con qualsiasi metodo disponibile, per esempio Apple Pay. Quando il pagamento va a buon fine, è ora di bere il caffè!

Conclusione
Progettare e realizzare un sistema di pagamento non è così difficile, una volta che sai cosa devi fare. Però ci vogliono tanti passi per arrivare a capirlo. Il mio pulsante "offrimi un caffè" sembra semplice, ma per farlo ho dovuto risolvere molte sfide diverse di progettazione e programmazione.
È difficile esagerare l'importanza della semplicità, eppure spesso è molto difficile da ottenere, perché richiede di capire tutti gli aspetti della sfida. Per citare Einstein: "La definizione di genio è prendere ciò che è complesso e renderlo semplice." Ora provalo pure tu stesso, il pulsante: è proprio qui ⬇️