Codes de réponse de l'API Verification of Payee

À retenir

Les quatre codes de schéma sont MTCH (correspondance), CMTC (correspondance partielle), NMTC (pas de correspondance) et NOAP (non applicable).
NO_MATCH est un résultat valide, pas une erreur de transport — branchez dessus, ne levez pas d'exception.
Les vraies erreurs (IBAN invalide, auth, limite de débit) utilisent HTTP 4xx/5xx avec un code lisible par machine.

Le bug d'intégration le plus courant avec la Verification of Payee est de traiter un NO_MATCH comme une requête échouée. Ce n'en est pas une. Une vérification réussie qui dit « ce nom n'appartient pas à cet IBAN » reste une réponse 200 avec des données utiles. Confondez les deux et vous avalerez des signaux de fraude ou montrerez des erreurs alarmantes aux utilisateurs.

Les quatre codes de schéma

Chaque réponse Verification of Payee correspond à l'un des quatre codes standardisés du schéma SEPA. Branchez sur le code, pas sur du texte libre :

MTCH — MATCH : le nom correspond au titulaire du compte. Poursuivez.
CMTC — CLOSE_MATCH : presque exact (deuxième prénom manquant, nom commercial vs raison sociale). Affichez le nom vérifié suggéré et demandez au payeur de confirmer.
NMTC — NO_MATCH : le nom n'appartient pas à l'IBAN. Avertissez clairement et bloquez l'approbation automatique.
NOAP — NOT_APPLICABLE : la vérification n'a pas pu être complétée (ex. banque réceptrice injoignable). Laissez l'utilisateur décider avec une prudence supplémentaire.

Résultat vs erreur

Si le statut HTTP est 200, vous avez un résultat de vérification — lisez scheme_code. S'il est 4xx/5xx, vous avez une erreur — lisez le code d'erreur. Ne mappez jamais NO_MATCH sur votre chemin d'erreur.

Bien gérer le CLOSE_MATCH

Le CLOSE_MATCH est là où la bonne UX se gagne ou se perd. La réponse peut porter le nom vérifié du titulaire ; présentez-le comme une suggestion (« Vouliez-vous dire… ? ») pour que le payeur confirme ou corrige plutôt que d'abandonner le paiement. Traiter CMTC comme un échec net frustre les utilisateurs légitimes.

Vrais codes d'erreur

Distincts des résultats de schéma, les problèmes au niveau du transport renvoient des erreurs HTTP standard — par exemple invalid_iban (400), unauthorized (401), rate_limited (429) et scheme_unavailable (503). Chacune porte un request id pour que le support puisse la tracer. Passez un external id stable à chaque appel afin que les reprises restent idempotentes et que les journaux se réconcilient.

Tous les articles

FAQ

Questions fréquentes

Que signifie CLOSE_MATCH (CMTC) dans le code ?

Cela signifie que le nom est presque exact — un deuxième prénom manquant, ou un nom commercial vs un nom enregistré. La réponse peut inclure le nom vérifié dans suggested_name, pour inviter le payeur à confirmer au lieu de rejeter le paiement.

Comment gérer une erreur NO_MATCH ?

NO_MATCH (NMTC) n'est pas une erreur — c'est un résultat 200 valide. Traitez-le comme un arrêt net dans votre UI ou votre cycle de paiement : avertissez l'utilisateur, bloquez l'approbation automatique et exigez une nouvelle vérification avant l'envoi.

En quoi les vraies erreurs diffèrent-elles d'une absence de correspondance ?

Les vraies erreurs utilisent des codes de statut HTTP 4xx/5xx avec un code d'erreur lisible par machine (ex. invalid_iban, unauthorized, rate_limited). Une absence de correspondance est une réponse 200 dont le scheme_code est NMTC.

Continuer la lecture

Documentation de l'API Endpoint, payloads, codes et exemples. Correspondance, partielle, aucune Les mêmes résultats, pour les non-développeurs.

Codes de réponse et d'erreur de l'API Verification of Payee, expliqués