Migration

Cette section couvre deux opérations très différentes. La première remplace votre prestataire de paiement actuel par Wajub. La seconde conserve Wajub et fait passer votre intégration d'une version datée de l'API à la suivante. Aucune ne doit faire l'objet d'une bascule brutale.

Méthode commune aux deux migrations

1. 1

   Dupliquez

   Conservez l'ancien parcours comme référence. Envoyez le même trafic au nouveau dans la sandbox et comparez les réponses. Rien ne change encore pour le client.

2. 2

   Déplacez

   Envoyez un pourcentage du trafic live vers le nouveau parcours. Utilisez une répartition déterministe pour qu'une commande reste toujours du même côté. Augmentez ce pourcentage tant que les mesures restent stables.

3. 3

   Basculez

   Lorsque l'ancien parcours ne reçoit plus aucun trafic, retirez-le. Supprimez l'adaptateur, le flag et les identifiants au lieu de les laisser inutilisés.

L'étape de déplacement est souvent ignorée alors qu'elle vous protège. Une fonction de répartition fondée sur l'identifiant de la commande vous offre cent positions au lieu d'un simple interrupteur.

Ce qui ne change pas

Votre checkout, la livraison de vos commandes et vos fiches clients restent en place. Une migration remplace uniquement l'appel qui encaisse les fonds et le message qui confirme le paiement. Si votre logique de paiement est répartie entre plusieurs contrôleurs, commencez par la placer derrière une interface unique. Cet effort devient immédiatement utile lorsque deux prestataires fonctionnent en parallèle.

Ce qui change

La dernière ligne piège les équipes qui viennent d'un prestataire fondé uniquement sur une redirection. Le retour du payeur sur votre site ne prouve pas le paiement et ne le prouvera jamais.