Étude de cas · SaaS B2B mondial confidentiel
Comment UnlockLive a livré une pile de paiements et d’abonnements Airwallex de niveau production sur Python et FastAPI — cinq devises en service en 12 semaines, 99,99 % de livraison des webhooks, alignée PCI-DSS et une baisse de 65 % du churn lié aux paiements échoués.
Un SaaS B2B en expansion de l’Amérique du Nord vers l’APAC et l’EMEA avait besoin d’une infrastructure de paiement capable d’encaisser en cinq devises, de gérer la facturation d’abonnements, de traiter les nouvelles tentatives avec élégance et de réussir une revue de sécurité. Il avait dépassé une configuration à processeur unique — les marges de change absorbaient 1,8 % du chiffre d’affaires, le règlement prenait plusieurs jours et son gestionnaire de webhooks perdait des événements sous charge. Le directeur financier voulait Airwallex pour le change et les rails mondiaux ; le directeur technique voulait conserver sa pile FastAPI existante et ne pas faire des paiements un service distinct que l’équipe ne pourrait pas exploiter.
La demande : livrer en un seul trimestre une intégration Airwallex en production sur FastAPI + PostgreSQL, avec une fiabilité des webhooks à toute épreuve, une véritable machine à états d’abonnement, une architecture alignée PCI-DSS et un dispositif d’exploitation clair pour que l’ingénieur d’astreinte à 2 h du matin n’ait pas à appeler le directeur technique.
Nous avons construit une intégration Airwallex ciblée autour de trois idées d’ingénierie : un modèle de domaine de paiement typé, un pipeline de webhooks selon le modèle outbox et une machine à états pour le cycle de vie des abonnements que le reste de l’application peut lire mais que seul le code de paiement peut écrire.
Côté API, toutes les données de carte sont collectées avec les éléments de paiement hébergés d’Airwallex, de sorte que le backend de l’application ne touche jamais un PAN — le périmètre PCI reste au niveau SAQ A. Le service FastAPI expose une petite API de paiements typée (modèles Pydantic v2, documentée OpenAPI) que l’équipe produit consomme ; les appels à l’API Airwallex sont encapsulés dans un client unique avec clés d’idempotence, nouvelles tentatives exponentielles et coupe-circuit.
Côté webhooks, chaque événement Airwallex arrive sur un point de terminaison signé et vérifié qui ne fait qu’une chose : persister l’événement brut dans une table `inbox` au sein d’une seule transaction. Un worker distinct traite l’inbox dans l’ordre, avec une livraison au moins une fois et des gestionnaires idempotents. Ce modèle seul a réglé complètement le problème des événements perdus — même lors d’un pic de trafic multiplié par 4 au lancement.
La machine à états des abonnements gère l’essai, l’actif, l’impayé, la relance, la pause, l’annulation et la réactivation, avec des transitions autorisées explicites et un journal d’audit à chaque changement d’état. Les paiements échoués suivent désormais un calendrier de nouvelles tentatives intelligent (et non le backoff exponentiel par défaut) adapté aux habitudes de jour de facturation du client, ce qui a produit la baisse de 65 % du churn lié aux paiements échoués.
Nous avons cartographié les parcours existants de paiement, d'abonnement, de relance et de remboursement ; documenté chaque endroit touchant à l'argent ou aux données de carte ; et produit un document de cadrage PCI d'une page définissant précisément quelles surfaces resteraient dans le périmètre SAQ A. Nous avons aussi passé en revue les chiffres de change sur le mix de devises prévu afin de confirmer le business case d'Airwallex avant d'écrire la moindre ligne de code.
Nous avons conçu un domaine de paiements typé (Pydantic v2 + un petit modèle de dépôt), le pipeline de webhooks inbox/outbox, la machine à états des abonnements et le contrat d'idempotence pour le client Airwallex. Chaque appel externe reçoit une clé d'idempotence dérivée de l'événement métier, de sorte qu'une nouvelle tentative ne peut jamais créer un paiement en double.
Nous avons livré une devise et un parcours d'abonnement à la fois derrière des feature flags, en commençant par le nouveau marché le moins risqué. Chaque gestionnaire de webhook a été livré avec un test de rejeu : nous capturions de vrais événements du bac à sable Airwallex, puis démontrions que le gestionnaire restait correct en cas de désordre, de doublon et de défaillance partielle.
Avant la mise en production, nous avons présenté au responsable de la revue de sécurité le périmètre PCI et le modèle de menaces, déployé des tableaux de bord Datadog pour le retard des webhooks, le taux de nouvelles tentatives, l'entonnoir de relance des impayés et l'exposition au change, et rédigé un véritable playbook d'astreinte qu'un ingénieur peut suivre à 2 h du matin sans réveiller le responsable. Nous sommes restés sous contrat de suivi pendant 8 semaines d'ajustements post-lancement.
“Nous sommes passés d'une configuration à processeur de paiement unique qui perdait des webhooks sous charge à une intégration Airwallex en laquelle notre équipe financière a confiance et que notre responsable de la revue de sécurité a validée du premier coup. La refonte de la relance des impayés a suffi à rentabiliser le projet.”
Utilisez le modèle inbox. L'endpoint HTTP fait exactement deux choses : vérifier la signature Airwallex et enregistrer l'événement brut dans une table de base de données au sein d'une seule transaction. Un worker distinct vide la table dans l'ordre, avec une livraison au moins une fois et des handlers idempotents. Cette séparation garantit qu'un handler lent, un déploiement ou une panne en aval ne peut jamais vous faire perdre ou traiter en double un webhook.
Collectez toutes les données de carte avec les éléments de paiement hébergés d'Airwallex (ou leur Drop-in / Hosted Payment Page). Votre backend ne voit jamais que des identifiants et des jetons Airwallex, jamais un PAN, un CVV ou une date d'expiration. Nous documentons ce périmètre dans une note de cadrage PCI d'une page que votre responsable sécurité peut valider, puis nous mettons en place des garde-fous dans le code afin qu'un futur ingénieur ne puisse pas, par accident, faire entrer des données de carte dans le backend.
Oui : le modèle asynchrone de FastAPI est excellent pour la nature liée aux E/S des API de paiement. La fiabilité vient des modèles qui l’entourent : clés d’idempotence sur chaque appel Airwallex, modèle inbox pour les webhooks, disjoncteur pour le client Airwallex et véritable machine à états d’abonnement. Nous avons livré des piles de paiement FastAPI traitant des dizaines de milliers de paiements par jour avec une livraison des webhooks à cinq neuf.
Airwallex a tendance à l'emporter pour les entreprises qui encaissent dans plus de 4 devises, grâce à de meilleures marges de change et à un règlement transfrontalier plus rapide. Stripe l'emporte généralement pour les SaaS exclusivement nord-américains qui valorisent son écosystème tiers bien plus vaste. Nous intégrons les deux et avons aidé des clients à les faire fonctionner côte à côte par région : les modèles d'intégration que nous utilisons (domaine typé, webhooks en inbox, machine à états) sont indépendants du processeur de paiement.
De 10 à 16 semaines pour une intégration de qualité production couvrant le paiement, les abonnements, les webhooks, le recouvrement, les remboursements et les rapports, pour une seule devise et un seul produit. Chaque devise ou flux d’abonnement supplémentaire ajoute ensuite généralement 1 à 2 semaines. Nous travaillons par tranches serrées derrière des feature flags pour que vous puissiez lancer la première devise avant que la seconde ne soit terminée.
SaaS8x Baisse de la latence p95 sur les points d'accès les plus sollicités (1,8 s → 220 ms)Comment nous avons repensé l’architecture d’une API Python/FastAPI très sollicitée avec une couche de cache Redis à plusieurs niveaux pour faire passer la latence p95 de 1,8 s à 220 ms tout en réduisant de 70 % la charge de PostgreSQL pour un SaaS B2B nord-américain.
Éducation50K+ Appels quotidiens à l'API Canvas, largement dans le quota de l'universitéComment UnlockLive a remplacé une synchronisation nocturne fragile de Canvas LMS par une intégration événementielle Python et FastAPI qui gère plus de 50 000 appels d’API par jour, zéro incident de limite de débit et une fenêtre de synchronisation réduite de 90 % — sans casser un seul système en aval.
SaaS beauté / gestion de studios12+ h Économisés par mois sur le rapprochement des commissionsComment UnlockLive a fusionné trois outils déconnectés — réservations par calendrier, caisse en studio et feuille de calcul des commissions — en un seul SaaS de bout en bout pour un studio américain de maquillage permanent. Réservation publique avec acompte Stripe, paiement en studio via Stripe, répartition automatisée des gains des artistes via Stripe Connect, tableau de bord financier pour le propriétaire, portail en libre-service des gains pour les artistes — économisant plus de 12 heures par mois de rapprochement et éliminant les litiges sur les gains depuis le lancement.
Parlez à l'équipe qui a construit Paiements et abonnements multidevises sur FastAPI + Airwallex pour un SaaS B2B mondial. Nous définirons le périmètre de votre projet, vous remettrons une proposition à prix fixe et vous présenterons l'exemple le plus proche de notre portfolio.
Réserver un appel stratégiqueUnlockLive IT Limited : siège de Toronto en contact avec les clients et gestion de projet ; centre d’ingénierie dédié à Dhaka, au Bangladesh. Société enregistrée au Royaume-Uni n° 15563368 (UnlockLive IT Limited, Londres).
Copyright© UnlockLive .Tous droits réservés 2008 - 2026