Estimation d'une intégration de paiement
Comment évaluer une intégration de paiement : environnement de test vs environnement de production, remboursements, webhooks, idempotence, périmètre PCI. La discussion qui doit avoir lieu avant que le moindre chiffre ne soit arrêté.
Sur le ticket, il est indiqué « ajouter Stripe ». Le document 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 « happy path » 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 vous 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 ce périmètre, le chiffre ne représente qu’une estimation portant sur un autre sujet.
Ce qui se dit dans la salle
Backend : « Le fonctionnement de la sandbox 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 échec de paiement, 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 — UI, 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 touchant jamais au PAN ?
- Rapprochement : qui établit le rapport, et par rapport à quelle source de référence ?
- Expériences utilisateur liées aux échecs : carte refusée, carte périmée, demande d’authentification 3DS — tout cela est-il pris en compte ?
Dans le cas d’un scénario comme celui-ci, la bonne approche consiste souvent à le diviser. « Encaisser de l’argent » constitue un scénario ; « rembourser de l’argent » en est un autre ; « rapprocher les comptes » en est un troisième. Si vous les traitez comme un seul et même scénario, 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 concernant la division des stories trop tardive ; techniques d’estimation pour un travail aussi flou. Consultez les autres exemples d’estimation concrets, ou lancez une session gratuite de Planning Poker lorsque le raffinement est prêt.