Il est tentant d'intégrer la Verification of Payee, de voir revenir une correspondance et de considérer que c'est terminé. Mais la valeur de la VoP réside dans les moments où la réponse n'est pas une correspondance nette — et ce sont exactement les cas qu'un test rapide saute. Un plan sandbox sérieux les couvre tous.
Testez chaque résultat
Une sandbox devrait vous permettre de reproduire chaque résultat de schéma à la demande, généralement en envoyant des noms ou IBAN de test spécifiques. Assurez-vous que votre UI et votre code font ce qu'il faut pour chacun.
- Correspondance (MTCH) — confirmez que le paiement peut se poursuivre proprement.
- Correspondance partielle (CMTC) — confirmez que vous affichez le nom vérifié suggéré à confirmer ou corriger.
- Absence de correspondance (NMTC) — confirmez que vous montrez un avertissement clair et ne procédez pas automatiquement.
- Non applicable (NOAP) — confirmez que vous gérez « impossible à vérifier » avec élégance, pas comme une erreur.
N'oubliez pas les chemins d'erreur
Au-delà des quatre résultats, testez ce qui se passe avec un IBAN malformé, un nom de bénéficiaire manquant, une credential expirée et un timeout. C'est là que les intégrations fragiles cassent en production.
Gardez les tests déterministes
Utilisez une sandbox avec des données de test documentées et déterministes pour qu'une entrée donnée renvoie toujours le même résultat. Cela rend vos tests d'intégration reproductibles en CI et signifie qu'un échec pointe vers une vraie régression, pas un répondeur instable.
De la sandbox à la production
Une fois que chaque résultat et chemin d'erreur se comporte correctement, la mise en production se résume généralement à changer l'URL de base et les credentials. RoxPay fournit une sandbox avec des cas de test pour chaque résultat, pour que vous puissiez valider tout le flux avant de pointer vers la production.