Estimation d'une intégration de paiement
Comment évaluer une intégration de paiement : environnement de test vs production, remboursements, webhooks, idempotence, périmètre PCI. La discussion qui doit avoir lieu avant que le moindre chiffre ne soit arrêté.
Le ticket indique « ajouter Stripe ». Le texte mentionne « la moitié d’un quart ».
Les paiements disposent d’une interface API publique qui tient sur une seule page et d’une interface de décision privée qui, elle, ne tient pas sur une seule page. Le choix d’un prestataire représente un pic de travail d’une journée. La mise en place du parcours d’achat standard prend quelques jours. Tout ce qui vient ensuite (le processus de remboursement, la politique de réessai des webhooks, les clés d’idempotence, le rapport de rapprochement comptable que le service financier demandera au cours du deuxième mois) constitue la fonctionnalité proprement dite, et rien de tout cela ne figure sur le ticket.
La « story » intitulée « intégrer Stripe » est rarement celle qui fait l’objet de l’estimation. La « story » estimée est en réalité : « nous pouvons encaisser de l’argent, le rembourser, prouver que nous l’avons bien encaissé et faire face à un litige concernant un prélèvement ». Tant que l’équipe n’a pas voté sur cette portée, le chiffre ne représente qu’une estimation portant sur un autre sujet.
Ce qui se dit dans la salle
Backend : « Le fonctionnement du bac à sable est simple. La bibliothèque se charge de l’essentiel. »
SRE : « Les webhooks doivent être idempotents. Quelle est notre stratégie de nouvelle tentative si Stripe effectue une nouvelle transmission ? »
Finance : « Comment les remboursements sont-ils comptabilisés ? Qu’en est-il des remboursements partiels ? »
Conformité : « Traitons-nous des numéros de carte bancaire, ou restons-nous au niveau SAQ-A ? »
PM : « Que dit l’e-mail signalant un paiement non abouti, et qui l’écrit ? »
Questions qu’il convient de se poser avant de voter
- Commencer uniquement par l’environnement de test, ou inclure les clés de production dès le premier jour ?
- Remboursements et remboursements partiels : via l’interface utilisateur (UI), l’API ou réservé aux administrateurs ?
- Idempotence des webhooks et gestion des nouvelles tentatives : à qui appartient la table de déduplication ?
- Champ d’application de la norme PCI : respectons-nous les exigences du SAQ-A en ne traitant jamais le PAN ?
- Rapprochement : qui établit le rapport, et par rapport à quelle source de référence ?
- Expérience utilisateur en cas d’échec : les cartes refusées, les cartes périmées et les problèmes liés à la 3DS sont-ils tous pris en compte ?
Dans ce genre de situation, la meilleure approche consiste souvent à scinder le projet en plusieurs parties. « Encaisser l’argent » constitue une partie ; « rembourser l’argent » en est une autre ; « rapprocher les comptes » en est une troisième. Si vous les traitez comme un seul et même projet, l’intégration sera livrée dès la troisième semaine, mais le service financier vous demandera où en est le rapport dès la huitième semaine.
Votez pour « prouver que nous avons reçu l’argent et que nous avons surmonté le litige », et non pour « appeler l’API de paiement ».
À ce sujet : erreurs courantes au « planning poker » liées à un fractionnement trop tardif des stories ; techniques d’estimation pour un travail aussi flou. Consultez les autres exemples d’estimation détaillés, ou lancez une session gratuite de « planning poker » lorsque le raffinement sera prêt.