Concevoir et mettre en place un système de (micro)paiement

Résumé

Les paiements en ligne sont plus importants que jamais, maintenant que le virus COVID-19 bouleverse les entreprises. Mes clients cherchent donc de nouvelles façons de gagner de l'argent en ligne. J'ai conçu et mis en place un système de (micro)paiement. Cet article parle de la simplicité qu'on atteint en résolvant des problèmes complexes.

Texte intégral

Comprendre une nouvelle technologie

Quand je développe une nouvelle technologie ou des applis, j'essaie toujours d'imaginer comment ça marcherait le mieux. Le moyen le plus simple de le savoir, c'est de concevoir le produit pour soi-même. Exactement comme Steve Jobs a fait développer Keynote, l'appli de présentation d'Apple, pour lui-même. C'est l'une de ses blagues célèbres sur le fait d'être un bêta testeur sous-payé

Si tu conçois le produit pour toi, pense à ce que tu voudrais vraiment, vraiment. Pour moi, ça veut dire le modèle d'interaction le plus simple qui soit : je veux que mon logiciel soit simple, facile.

Cas d'usage : offre-moi un café

Pour développer cette technologie de paiement, j'ai imaginé un cas d'usage : ajouter un bouton « offre-moi un café » sur mon site. Si ça marche bien, les gens pourront s'en servir pour montrer qu'ils apprécient ce blog en m'offrant un café. Je trouve que ce cas d'usage est un défi parfait pour concevoir (et construire) un système de (micro)paiement.

Esquisser des idées

Avant d'écrire la moindre ligne de code, je conçois souvent mes logiciels en esquissant des idées à la main. Dessiner m'aide à explorer des idées, des mises en page, des processus. C'est l'une des raisons pour lesquelles j'aime autant travailler sur une tablette : esquisser en numérique me permet d'explorer plusieurs pistes à toute vitesse, en copiant-collant chaque idée dans de nouvelles versions.

Prototypage

Une fois que tu as exploré des idées pour ton interface, il est temps de développer un prototype. Avec un prototype, tu peux tester l'interface sur différents appareils et voir ce qu'elle donne à l'écran et sous les doigts.

Pendant le prototypage, je regarde souvent l'esquisse pendant que je programme la première version. Sur iPad, je fais ça en écran partagé : l'esquisse à côté de mon code, avec VIM dans tmux via Mosh grâce à la formidable appli Blink pour iPadOS. J'ai dessiné la tasse de café avec Picta Graphic for iPad, une superbe appli de dessin qui exporte en images vectorielles (SVG).

Développement frontend

L'étape suivante, c'est de développer une interface pleinement fonctionnelle, avec des boutons qui marchent. Pendant le développement, il faut souvent comprendre ce qui se passe, traquer des bugs et affiner des mécanismes. J'utilise le navigateur Inspect Browser pour iPadOS : j'ai ainsi une interface tactile miniature qui fonctionne juste à côté de mon code. Je peux tester et peaufiner l'interface très vite.

Développement backend

Autre étape cruciale : développer la technologie backend qui prépare et suit les paiements en ligne. C'est la partie côté serveur, qui gère la communication entre l'interface frontend (le site web) et le prestataire de paiement (banques, cartes de crédit, Apple Pay, etc.).

Concevoir le serveur backend est en général un peu plus abstrait que concevoir une interface frontend (visible). Pour savoir quels appels d'API doivent se faire, et dans quel ordre, je trouve très utile de dessiner des diagrammes de séquence UML. Les diagrammes de séquence visualisent les interactions d'un programme dans le temps.

Tu vois trois colonnes dans le diagramme de séquence du processus de paiement : le frontend, le backend et le prestataire de paiement. Chaque colonne est un ordinateur différent qui communique avec les autres. Le frontend tourne sur l'appareil de l'utilisateur, le serveur backend tourne sur un VPS que je gère moi-même, et le prestataire de paiement est un serveur externe. L'utilisateur interagit avec le site en cliquant sur le bouton « offre-moi un café », ce qui déclenche une chaîne d'appels d'API qui circulent de droite à gauche.

Le « serveur backend » calcule le montant que l'utilisateur doit payer. Ce calcul se fait sur le serveur, pas chez le client, pour empêcher les utilisateurs malveillants de manipuler le prix (car la technologie frontend peut être manipulée via le navigateur).

On prépare une session de paiement en informant le prestataire que l'utilisateur va effectuer un paiement d'un certain montant. Pour cela, on utilise une clé d'API secrète qui permet au prestataire de savoir sur quel compte bancaire les paiements doivent arriver. Le prestataire renvoie une URL de paiement, qui sert à rediriger l'utilisateur vers la vraie page de paiement.

Le prestataire de paiement que j'utilise est Mollie, une entreprise basée à Amsterdam et dotée d'une plateforme de paiement fantastique. Leurs API sont bien documentées et ils fournissent des paquets pour intégrer facilement leur système de paiement à ton serveur backend.

En harmonie avec mes autres serveurs backend, j'ai choisi de développer celui-ci en NodeJS. Ça tourne sur pratiquement n'importe quoi, d'un minuscule Raspberry PI jusqu'aux grands clouds de calcul. Tu peux aussi utiliser PHP, Ruby, Python ou n'importe lequel des autres paquets disponibles. La référence de l'API Mollie détaille les valeurs auxquelles tu peux t'attendre.

Mises à jour asynchrones du statut de paiement

Peu de gens se rendent compte que récupérer le statut d'un paiement est un processus asynchrone, qui peut avoir différents statuts. Dans un monde parfait, tu saurais tout de suite si un paiement réussit ou échoue. Mais comme les paiements en ligne sont distribués, avec des backends qui communiquent avec des serveurs différents (banques, cartes de crédit, etc.), on ne sait jamais exactement quand un paiement va aboutir.

Pense aux situations où l'utilisateur ferme la page de paiement, laisse son appareil sans surveillance, ou quand une banque a une panne de son système de banque en ligne. Ça arrive, et c'est à toi de concevoir le serveur backend pour qu'il traite les mises à jour du statut de paiement séparément du processus d'interaction principal.

Le prestataire de paiement appelle un webhook sur notre serveur backend. Il envoie un message du genre « Regarde, quelque chose a changé sur le paiement XYZ ». Ce message dit seulement que quelque chose a changé, pas quel est le nouveau statut. C'est pour des raisons de sécurité : sinon, des utilisateurs malveillants pourraient imiter l'appel à notre webhook. À la place, notre serveur backend demande le vrai statut du paiement par un canal sécurisé, avec notre clé d'API secrète. Le prestataire renvoie le statut, que notre serveur backend traite ensuite. Selon le statut, on déclenche les actions adaptées : envoyer des notifications par e-mail, lancer la livraison de marchandises.

Fullstack : combiner frontend et backend

La dernière étape consiste à relier le frontend à la technologie backend pour que tout le processus fonctionne. C'est ce qu'on appelle le « développement fullstack », puisque tu travailles sur l'ensemble du système. Le développement fullstack est un art à part, que peu de développeurs maîtrisent vraiment : il faut travailler (déboguer et développer) sur plusieurs fronts en même temps, et souvent dans des langages de programmation différents !

En pratique, ça veut dire que tu surveilles différentes parties du programme pour voir si elles fonctionnent bien ensemble. Tu regardes les logs du serveur pendant que tu essaies d'effectuer un paiement avec le frontend tout neuf. C'est dur, mais c'est aussi très gratifiant, parce que ça donne un produit qui marche !

Le bouton « offre-moi un café » qui en résulte offre à l'utilisateur un processus en 3 étapes d'une simplicité trompeuse :

• étape 1 : clique sur un simple bouton « offre-moi un café », sans formulaire de commande compliqué ni captcha agaçant : juste un seul bouton
• étape 2 : l'interface se déploie sur place, ce qui préserve le contexte et permet de laisser un message ou de m'offrir plusieurs tasses de café. Les autres éléments de l'interface, comme les boutons de réseaux sociaux, se masquent automatiquement pour mieux se concentrer sur le café
• étape 3 : l'écran du prestataire de paiement permet à l'utilisateur de payer avec n'importe quel moyen de paiement disponible, comme Apple Pay. Quand le paiement réussit, il est temps de boire du café !

Conclusion

Concevoir et mettre en place un système de paiement n'est pas si difficile quand on sait ce qu'il faut faire. Mais il faut passer par beaucoup d'étapes pour arriver à le comprendre. Mon bouton « offre-moi un café » a l'air simple, pourtant il a fallu résoudre une foule de défis de conception et de programmation.

On n'insistera jamais assez sur l'importance de la simplicité, et pourtant elle est souvent très difficile à atteindre, parce qu'il faut comprendre tous les aspects du problème. Pour citer Einstein : « Le génie, c'est prendre ce qui est complexe et le rendre simple. » Maintenant, essaie le bouton toi-même : il est juste ici ⬇️