Tous les projets
Purse · 2025 — 4 mois

Lien de paiement

Un générateur qui permet aux équipes support de créer et d’envoyer elles-mêmes un lien de paiement, sans passer par l’API.

Purse — générateur de liens de paiement
Rôle
Seul Product Designer : benchmark, recherche, UI, stratégie design, passation
Équipe
PM, frontend, responsable support
Utilisateurs
Équipes support et service client
Périmètre
Générateur de liens, prévisualisation, page de paiement hébergée, tableau de données
En bref

Quand un client ne pouvait pas payer sur le site, le support n’avait rien à proposer, et le seul contournement passait par l’API. Le besoin défini était de générer un lien. J’ai poussé plus loin : une prévisualisation avant l’envoi, que les PM jugeaient superflue et que les utilisateurs citent aujourd’hui comme la fonctionnalité qui fait la différence.

  • −80 %de tickets liés aux liens de paiement (25 à 30 par mois avant)
  • 55liens créés en moyenne par mois et par client, sans développeur
  • +10 %de revenus, grâce aux paiements récupérés
Contexte

Impossible d’être payé en dehors du site

Purse ne pouvait encaisser un paiement que dans le tunnel du marchand, en temps réel. Dans tous les autres cas, qu’il s’agisse d’une commande par téléphone, d’une carte refusée ou d’une facture réglée deux jours plus tard, il n’existait aucune solution. C’étaient les équipes support qui en absorbaient les conséquences.

Le problème

Il n’existait aucun moyen de générer une demande de paiement et de laisser le client payer plus tard, en dehors du site.

  • Le seul contournement était un appel API, donc le support dépendait d’un développeur pour chaque cas.
  • L’utilisation manuelle de l’API produisait des liens mal formés, qui revenaient aussitôt en tickets.
  • Le chiffre d’affaires était tout simplement perdu quand un client ne pouvait pas payer sur le moment.
Ma démarche

Concevoir pour la personne au téléphone

  1. Benchmark

    Les autres prestataires proposent des liens, mais l’agent les envoie à l’aveugle. Aucun ne montre ce que le client va recevoir.

  2. Entretiens utilisateurs

    Aux côtés des agents support, en plein appel. Leur crainte n’était pas de créer le lien, mais d’envoyer une erreur au client.

  3. Tests d’utilisabilité

    Le générateur testé sur de vrais cas, en chronométrant l’envoi d’un lien. La prévisualisation rassurait les agents au moment d’envoyer.

  4. Passation

    Livraison des états, des cas limites et des règles d’expiration sous forme de composants du design system.

Arbitrages

Les choix qui ont façonné le produit

Faut-il montrer le lien avant de l’envoyer ?

Une prévisualisation avant l’envoi

J’ai ajouté une prévisualisation de la page de paiement telle que le client la verra : montant, référence, expiration. L’agent vérifie avant d’envoyer, au lieu de découvrir l’erreur dans un ticket.

Ce qui a tranché : l’analyse des concurrents, qui n’en proposent pas, et les entretiens, où la peur de l’erreur revenait à chaque session.

Écarté : La génération seule, comme le prévoyait le besoin initial : plus rapide à livrer, sans la réassurance qui fait choisir notre outil plutôt que l’API.

Qui crée le lien ?

L’interface d’abord, l’API ensuite

Chaque champ a une valeur par défaut pertinente : le chemin le plus court se résume au montant, puis à l’envoi.

Ce qui a tranché : le lien doit partir pendant l’appel, envoyé par la personne qui parle au client.

Écarté : L’API seule avec sa documentation : l’option la moins chère, et celle qui générait déjà les bugs et les tickets que nous voulions supprimer.

Que peut modifier un agent ?

Un ensemble fermé de personnalisations

Les agents modifient ce qui touche au paiement : montant, référence, expiration, message. L’identité visuelle reste verrouillée au compte marchand.

Ce qui a tranché : une page de paiement hors charte inquiète le client au pire moment, celui de payer.

Écarté : Un éditeur libre, qui aurait multiplié les pages de paiement cassées ou hors charte.

Convaincre

Défendre une fonctionnalité jugée superflue

Pour les PM, la prévisualisation ne servait à rien : le besoin défini était de générer un lien, pas de le montrer. J’ai répondu avec l’analyse du marché et les entretiens : aucun concurrent ne la proposait, et chaque agent redoutait d’envoyer une erreur.

Au-delà de la fonctionnalité, j’ai proposé une stratégie design fondée sur la stickiness : rendre notre interface plus utile qu’un appel API, pour que les clients passent par notre produit. Elle rejoignait la stratégie produit et tech de l’entreprise, et c’est ce qui a emporté la décision.

Ce que disent les utilisateurs

  • La prévisualisation, c’est ce qui fait la différence. Je sais exactement ce que mon client va recevoir.

    Agent support

  • Avec l’aperçu, on n’a plus aucune raison de passer par l’API.

    Responsable support

Résultat : la prévisualisation est livrée, et les utilisateurs la citent comme la raison de passer par notre produit plutôt que par l’API.

Impact

Le support envoie ses liens sans les devs

Le lien de paiement est passé d’un service rendu par les devs à une action du support. Les tickets liés aux liens sont passés de 25 à 30 par mois à environ 5. Chaque client crée en moyenne 55 liens par mois, et une partie du chiffre d’affaires qui disparaissait après un paiement échoué est désormais encaissée un ou deux jours plus tard.

Le volet revenus a été reconstitué après le lancement, le générateur n’étant pas instrumenté dès le départ.

  • Tickets liés aux liens de paiement−80 %
  • Liens créés par mois et par client55
  • Revenus, grâce aux paiements récupérés+10 %
Ce que j’en retiens

L’amélioration du support la moins chère n’était pas un meilleur centre d’aide. C’était de confier l’outil à la personne qui parle déjà au client.

Ce que je ferais différemment : instrumenter le générateur dès le premier jour. Nous avons mesuré la baisse des tickets, mais reconstitué le volet revenus après coup.