Service de taux de change Laravel : comment nous avons résolu les litiges de remboursement multi-devises

"J'ai payé 102,30 et vous avez rendu 99,85 ? Ce n'est pas un remboursement, c'est une pénalité."

Alex avait commandé des baskets sur notre plateforme transfrontalière pour 16 500 ¥, soit 102,30 € au moment du paiement. Quelques jours plus tard, la taille ne lui convenait pas, il a donc demandé un remboursement. Tout s'est bien passé du point de vue opérationnel… jusqu'à ce que l'argent arrive sur sa carte.

Nous avons renvoyé 16 500 ¥, mais le taux du yen par rapport à l'euro avait changé depuis son achat. Il a reçu 99,85 €, soit 2,45 € de moins que ce qu'il avait payé. La cause première n’était pas une erreur de calcul. C'était notre gestion naïve du taux de change : nous utilisions le taux en vigueur au moment du remboursement, et non le taux en vigueur au moment du paiement initial.

Le vrai problème : un taux de change à la dérive

Notre plateforme est un monolithe Laravel qui alimente une place de marché reliant les acheteurs européens aux vendeurs de baskets japonais. Les montants des commandes sont exprimés dans la devise locale du vendeur : le yen. Mais nous facturons nos clients dans leur devise préférée (euros, dollars, etc.), et tous les rapports financiers sont dans une autre devise de base. Cela signifiait que chaque opération de transfert d’argent franchissait une limite tarifaire.

Pour un achat, nous récupérons le tarif en direct auprès d'un fournisseur exte...
[Courte citation de 8% de l'article original]