Laravel SISP 0.6.4 rend les états de paiement explicites

Les paiements ne cassent pas seulement quand la passerelle tombe.

Ils cassent quand une transaction reste en attente trop longtemps, quand un retry peut être appelé sans signature, quand la somme des articles ne correspond pas au total, quand une facture regroupe les lignes de la mauvaise façon, ou quand le package publié pointe vers un fichier qui n’existe pas.

C’est ce que j’ai traité comme Laravel SISP 0.6.4.

Techniquement, il y a eu une 0.6.3 la veille. En pratique, 0.6.3 et 0.6.4 appartiennent au même mouvement : nettoyer le socle opérationnel du package pour qu’une application Laravel puisse intégrer SISP avec moins de surprises en production.

D’abord, sortir le bruit du package

La 0.6.3 a réglé des choses qui semblent petites jusqu’à ce qu’elles bloquent quelqu’un.

Le package avait des metadata Node mal alignées et pointait vers un entrypoint absent. Cela ne change pas le flux de paiement, mais cela change la confiance de qui installe, audite ou automatise le package. Un manifest de package erroné est une promesse rompue en miniature.

J’ai aussi corrigé le fingerprint sérialisé dans le callback et stabilisé la génération des identifiants de marchand. Ces deux points vivent au sol de l’intégration. Personne n’achète le package parce qu’ils existent. Mais quand ils échouent, tout ce qui est au-dessus devient suspect.

C’était la première partie de la release : retirer le bruit pour que le comportement réel du package soit plus facile à croire.

Ensuite, protéger l’argent

La 0.6.4 a resserré les règles aux endroits où trop de tolérance devient un bug financier.

Le package valide désormais les totaux des articles de paiement avant d’aller plus loin. Si la somme des articles ne se boucle pas avec le montant attendu, cela doit apparaître tôt. La facture, la réconciliation et le support client dépendent tous de ce détail.

Les remboursements sont aussi devenus plus explicites : le package exige des reversements du montant total. Cela évite un état à moitié supporté, à moitié imaginé, où l’application croit avoir fait une chose alors que la passerelle en représente peut-être une autre.

Les retries exigent maintenant des requêtes signées. Les routes qui changent l’état ont reçu un middleware configurable. C’est le genre de changement qui ne doit pas devenir un beau titre, mais qui doit exister dans tout package qui touche à l’argent.

Le point central : en attente n’est pas final

La fonctionnalité la plus importante de la 0.6.4 est la réconciliation des paiements en attente.

Dans SISP, comme dans toute vraie passerelle, la réponse finale n’arrive pas toujours au moment où l’application la veut. Le callback peut être en retard. La réponse peut arriver incomplète. La transaction peut exister sans être encore prête à être traitée comme un succès ou un échec.

Avant, ce genre d’état intermédiaire était facile à laisser comme un problème opérationnel. Maintenant le package a une requête de statut documentée et un chemin de réconciliation pour les paiements en attente.

Cela change la posture de l’intégration. Au lieu de prétendre que chaque paiement se termine au premier aller-retour, le package admet que des états intermédiaires existent et doivent devenir des décisions explicites.

Le contre-argument

Oui, cela ressemble à une petite release.

Il n’y a pas de nouvelle API tape-à-l’œil. Il n’y a pas de nouveau frontend. Il n’y a pas de nouveau flux à vendre dans le README.

Mais c’est justement le point. Une intégration de paiement ne gagne pas en maturité juste en ajoutant de la surface. Elle gagne en maturité quand elle retire l’ambiguïté des endroits où la production a l’habitude de présenter la facture : callbacks, retries, totaux, factures, remboursements et états en attente.

Laravel SISP 0.6.4 est ce genre de release.

Moins de promesse. Plus de contrat.

Dans les paiements, la meilleure release transforme les états ambigus en décisions explicites.