Une passerelle de paiement régionale, et le coût d'un enum

Les fournisseurs mondiaux comme Stripe ont un support vraiment limité ou inexistant sur certains marchés — les réseaux de cartes locaux, les rails bancaires et les exigences de conformité ne sont pas toujours couverts par un fournisseur qui n'a pas été construit avec ce marché comme cible de première classe. Pour une plateforme sur un de ces marchés, une passerelle régionale construite pour son traitement de cartes et sa conformité est souvent la seule option réaliste, pas un choix stylistique.

La forme de toute intégration de passerelle de paiement est globalement la même quel que soit le fournisseur :

[App]        → crée un enregistrement de paiement (statut : pending), obtient une pay_url du fournisseur
[Utilisateur] → redirigé vers pay_url, complète le paiement
[Fournisseur] → renvoie un webhook avec le résultat
[App]        → vérifie que le webhook vient vraiment du fournisseur, met à jour le statut

La vérification du webhook est la partie la plus susceptible d'être ratée

Tout webhook de paiement doit vérifier indépendamment que la requête entrante vient vraiment du fournisseur — typiquement une vérification de signature contre un secret partagé — avant de faire confiance à son contenu. Traiter un callback non vérifié comme faisant autorité est un chemin direct vers un attaquant qui POST un faux webhook « paiement réussi » et obtient un accès gratuit à ce que le paiement était censé verrouiller. Une des choses les plus lourdes de conséquences à bien faire dans toute intégration de paiement, précisément parce que s'y tromper est invisible jusqu'à ce que quelqu'un l'exploite. (J'ai découvert plus tard que la route de webhook de mon fournisseur était @Public() et atteignable par le vrai fournisseur pendant tout le temps où les paiements étaient censément « débranchés » — la protection que j'ai ajoutée pour désactiver les paiements devait la couvrir aussi.)

Le coût de conception rétrospectif

Modéliser le fournisseur comme un enum à valeur unique marche très bien tant qu'il y a vraiment un fournisseur, et fige un vrai coût dès qu'un second est nécessaire — un secours, ou une expansion vers un marché que le premier ne couvre pas. Ajouter une valeur d'enum nécessite une migration ; une simple colonne de chaîne, validée dans le code applicatif, aurait pris en charge un nouveau fournisseur avec juste un changement de code. S'il y a une chance réelle d'un second fournisseur un jour, modélise « quel fournisseur » comme une chaîne ouverte, pas un enum fermé, même avec une seule valeur aujourd'hui.

Les plans d'échéancier sont leur propre entité liée, séparée des paiements uniques — un plan avec plusieurs éléments programmés, chacun avec sa propre date d'échéance, son statut et son paiement de règlement optionnel, est vraiment différent de traiter chaque paiement comme un coup unique. C'est de la modélisation de domaine — les frais sont vraiment découpés en échéances — pas un détail de fournisseur de paiement. La passerelle traite juste chaque paiement d'échéance individuel.