Onetip

Le point de départ

Il y avait déjà une app tablette, posée sur le comptoir pour recevoir les pourboires. Je l'ai reprise telle qu'elle était, avec son code et ses habitudes.

• Une app tablette pour une flotte d'appareils dédiés, sans mise à jour à distance du code. Chaque changement passe par une nouvelle installation.
• Un serveur central qui fait le lien entre les paiements, les équipes et les établissements.
• Pas d'app pour le client ni pour les serveurs, pas d'outil pour suivre les versements, pas de paiement sans la tablette.

Ce qui a été construit

Autour de la tablette, une série d'outils branchés sur le même serveur. Chacun sert une personne précise.

• Les versements aux équipes passent par Stripe Connect, chaque personne ayant son propre compte.
• Un abonnement et une commission se calculent côté serveur, avec des tests qui figent les règles d'argent.
• Les apps mobiles existent en trois langues.

Comment ça marche

Le parcours d'un pourboire, du client jusqu'à l'équipe.

1. Le client arrive sur un écran de remerciement, en scannant un QR code, en approchant son téléphone d'un tag NFC ou en passant par la tablette du comptoir.
2. Il choisit la personne à remercier, puis un montant.
3. Il paie par carte, avec Apple Pay ou Google Pay quand son téléphone le permet. Une vérification 3D Secure s'ajoute si sa banque l'exige.
4. Le serveur enregistre le paiement une seule fois, calcule la part de la plateforme et attribue le reste à la personne.
5. La personne voit le pourboire dans son app et le reçoit sur son compte bancaire, par un versement Stripe Connect.
6. Le gérant et l'équipe Onetip suivent l'ensemble dans leur back-office.

Ce qui a été difficile

Une plateforme où passe de l'argent ne pardonne pas les erreurs de calcul ni les doublons. Voici cinq problèmes réels, avec leur cause et ce qui a été fait.

1. Un abonnement prélevé deux fois en début de mois

   Pendant les premiers jours du mois, certains comptes étaient débités de plus que prévu.

   Le calcul du mois d'abonnement se trompait de période et comptait certains paiements plusieurs fois. J'ai écrit les tests qui figent le comportement attendu, corrigé le calcul sur le fuseau de Paris, puis vérifié sur un vrai compte en production.

2. Un collaborateur ajouté deux fois

   En ajoutant quelqu'un à l'équipe, un double appui sur le bouton créait deux fiches.

   Une transaction ne suffit pas ici, car le SDK client ne sait pas lire une requête en transaction. Chaque fiche a désormais un identifiant calculé à partir de la personne et de l'établissement, et l'ajout se fait en une seule écriture groupée.

3. Une caisse qui ne demandait plus ses permissions

   Après l'un de mes correctifs, la tablette démarrait sans demander l'accès dont elle a besoin pour encaisser.

   Ma règle attendait que l'app soit au premier plan, mais Android ne l'indique pas encore au démarrage. La caisse restait muette. Je l'ai vu et corrigé le jour même, en retirant cette condition.

4. Une app iOS qui se figeait en choisissant une photo

   Sur iPhone, ouvrir le sélecteur de photo bloquait l'écran.

   L'app ouvrait le sélecteur pendant qu'une fenêtre était encore en train de se fermer, et iOS refuse cette superposition. L'action attend désormais que la fenêtre soit fermée. Android n'était pas concerné.

5. Le retour de la vérification 3D Secure ne revenait pas

   Après la validation chez la banque, la page restait ouverte ou affichait une erreur de route.

   La bibliothèque de paiement ne recevait jamais l'adresse de retour sur iOS. J'ai branché l'écoute de ce lien moi-même et fait en sorte que l'app l'absorbe sans changer d'écran. Le parcours est validé sur iOS et Android.

La stack

React Native avec Expo pour les apps tablette et mobile, Next.js pour les deux back-offices et la page de paiement NFC, Firebase pour la base, l'authentification et les fonctions serveur en Node et TypeScript, Stripe et Stripe Connect pour les paiements et les versements. Les règles d'argent du serveur sont couvertes par des tests automatisés.