Qu'est-ce qu'une migration de fournisseur de paiement ?

La migration de fournisseur de paiement consiste simplement à déplacer votre passerelle de paiement, PSP, acquéreur ou orchestrateur de paiement vers un autre PSP. Pour les entreprises SaaS, la migration implique généralement le basculement des intégrations, de la logique de routage, des données de facturation récurrente et des jetons, le processus de paiement fonctionnant sans interruption. La tokénisation est une procédure où les PAN (numéros de compte principaux) sont échangés contre des jetons, ce qui permet aux systèmes de gérer des jetons et de potentiellement modifier les niveaux d'exposition PCI.

Le changement de fournisseurs de paiement peut affecter divers aspects de l'activité et des opérations. Les principales caractéristiques englobent des niveaux de taux d'autorisation spécifiques, des structures de frais de traitement des paiements variables, une surveillance de la fraude modifiée, la disponibilité géographique et les aspects d'interaction utilisateur influencés par les taux de succès des transactions.

Pour les entreprises SaaS, cela devrait être associé à divers résultats :

•       Une augmentation de 2 à 4 % des taux d'autorisation.
•       Les taux de rétrofacturation affichent une valeur mesurable.
•       Le coût par transaction est enregistré à un chiffre spécifique inférieur.
•       Moins de tickets de support client.
•       La protection des données sensibles peut impliquer des jetons.

Le processus de migration des paiements implique diverses composantes, et la compréhension des risques associés se rapporte à des considérations opérationnelles ou procédurales.

•       L'analyse explore les facteurs d'interruptions, de temps d'arrêt et d'échecs de transaction, ainsi que leur importance pour les revenus et la confiance des clients.
•       Une gamme de fonctionnalités de transfert de jetons est proposée par différents fournisseurs ; certains n'incluent pas de capacités d'importation ou d'exportation.
•       La cartographie des données, dans le contexte du déplacement des enregistrements confidentiels des clients et des transactions, peut présenter des différences.
•       Le maintien du périmètre PCI DSS et du niveau de conformité tout au long du processus de migration.
•       Une baisse temporaire des taux d'autorisation a été constatée suite au changement.
•       Les perturbations qui suscitent des retours clients impactent l'expérience utilisateur.
•       La parité des webhooks, les tentatives et les remboursements doivent fonctionner correctement sur différents systèmes.
•       La continuité de la facturation récurrente doit être soigneusement planifiée afin de ne pas interrompre les abonnés.

Identifiez d'abord en profondeur tous les composants, flux, frais, contrats et méthodes de paiement de votre système. Vous devez vérifier votre inventaire de jetons, les dépendances de facturation récurrente, les paramètres de fraude et les exigences de rapport pour lister tous les points d'intégration et les impacts. Vous devez également vous assurer que la transition est planifiée avec vos options de déploiement et de restauration, ainsi qu'avec les métriques de succès. Enfin, préparez votre équipe au changement en testant dans un environnement de test avec votre nouveau fournisseur et en effectuant des “lancements progressifs” pour réduire les perturbations lorsque la migration finale aura lieu.

Une migration de fournisseur de paiement bien exécutée implique une série d'actions : auditer, sélectionner, implémenter, migrer et décommissionner dans cet ordre précis.

1.   Analysez votre infrastructure actuelle, vos niveaux de performance et vos exigences commerciales.
2.   Décidez des fournisseurs à choisir.
3.   Gérer les aspects techniques. Assurez-vous que l'aspect technique de la modification de votre système est couvert.
4.   Déplacer les données et les jetons. Transférez le contenu vers votre nouveau système.
5.   Effectuer des tests et des transactions en direct parallèles. Détectez les erreurs lors de tests approfondis et faites fonctionner les deux systèmes pour vous familiariser avec le nouveau.
6.   Le processus implique un arrêt progressif de l'ancien système, suivi de son démantèlement. Vous pouvez démanteler l'ancien système ou ne pas le faire du tout, mais le démanteler par étapes.

Le choix des fournisseurs en fonction de facteurs qui influencent leurs performances et leur adaptabilité aux changements futurs est essentiel. Les critères devraient inclure 

• vitesse d'autorisation, 
• gamme de paiements pris en charge, 
• les zones couvertes, 
• portabilité des jetons, 
• outils de lutte contre la fraude, 
• rapports détaillés, 
• disponibilité garantie/SLA, 
• outils pour développeurs, etc.

Maintenez la passerelle existante en fonctionnement comme solution de repli, et mettez en place une surveillance en temps réel de vos métriques clés. Suivez-les en continu pour détecter les problèmes à un stade précoce :

• Taux d'autorisation et la latence.
• Observations liées aux codes d'erreur et aux états opérationnels des webhooks.
• Volumes de remboursements.
• Demandes de support client.

Assurez-vous que votre actuel passerelle de paiement reste entièrement actif et opérationnel pendant la phase d'intégration et de test du nouveau système. Ensuite, redirigez un volume de trafic relativement faible vers le nouveau système en effectuant un routage canary de chaque transaction à titre de test jusqu'à la bascule complète. La stratégie des systèmes en production est souvent associée à une interruption réduite, ce qui peut faciliter la migration en direct sans nécessiter de temps d'arrêt planifié.