L'API Verification of Payee

Oui. Un appel de vérification répond de manière synchrone, généralement en bien moins d'une seconde, et inclut le BIC de la banque répondante et le temps de traitement du PSP pour surveiller les performances.

Les appels sont authentifiés avec un bearer token sur HTTPS. Vous pouvez aussi utiliser le tableau de bord RoxBusiness pour des contrôles ponctuels sans écrire de code.

Un résultat normalisé (MATCH, CLOSE_MATCH, NO_MATCH, NOT_APPLICABLE), le code de type de correspondance du schéma SEPA, un id de vérification, le BIC répondant, le temps de traitement et votre id externe optionnel.

Oui - appelez l'endpoint par enregistrement pour vérifier un fichier entier de fournisseurs ou bénéficiaires avant une remise. Elle est conçue pour de gros volumes.

Oui. L'endpoint est sans état, vous pouvez donc l'appeler à chaque création de bénéficiaire - une étape d'onboarding vendeur ou fournisseur - et de nouveau juste avant chaque paiement. Le re-contrôle au moment du paiement détecte les coordonnées bancaires modifiées après l'onboarding, là où se produit généralement la fraude au détournement de facture et de paiement.

La vérification est un appel REST par enregistrement : un fichier de paiement de milliers de bénéficiaires se traite donc comme un lot - parcourez le fichier, appelez l'endpoint par enregistrement et rassemblez les résultats avant de libérer la remise. Comme l'API est conçue pour un débit élevé, vous cadencez la boucle selon votre propre fenêtre de remise, sans être plafonné par un onboarding banque par banque. Parlez-nous de vos volumes et nous dimensionnerons le débit avec vous.

Oui. La même vérification est disponible dans le tableau de bord RoxBusiness : une équipe finance ou opérations peut contrôler un bénéficiaire unique - un contrôle « know your payee » avant d'envoyer de l'argent - pendant que les développeurs utilisent l'API pour les flux automatisés.

Oui. Le contrôle compare le nom soumis au titulaire du compte enregistré, qu'il s'agisse d'une personne physique ou d'une entreprise, et est utilisé dans le flux des mandats SEPA Direct Debit de RoxPay comme pré-contrôle.

NO_MATCH n'est pas une erreur de transport - c'est une réponse 200 valide indiquant que le nom n'appartient pas à l'IBAN. Traitez-la comme un arrêt net dans votre UI ou votre remise : affichez un avertissement clair, bloquez l'approbation automatique et faites revérifier le bénéficiaire avant l'envoi.

CLOSE_MATCH (code de schéma CMTC) signifie que le nom est presque exact - un deuxième prénom manquant, une raison sociale vs un nom commercial. La réponse contient le nom vérifié du titulaire, vous pouvez donc l'afficher comme suggestion et demander confirmation au payeur plutôt que de rejeter le paiement.

Pour les personnes morales, le schéma permet la vérification par rapport à l'identifiant de l'organisation (par ex. la Partita IVA / le Codice Fiscale italien) ainsi qu'au nom. Vous soumettez l'identifiant dans la requête et l'API renvoie le résultat standard - utile lorsque la raison sociale et le nom commercial diffèrent.

Oui. Pour une remise, parcourez votre fichier de fournisseurs ou de paie et appelez l'endpoint de vérification par enregistrement avant de libérer le lot. Conçue pour de gros volumes, elle permet aux équipes financières de valider en masse les IBAN par rapport aux noms avant chaque remise.

Oui. Vous envoyez une requête JSON avec le nom et l'IBAN du bénéficiaire et recevez en retour le résultat, le nom vérifié (en cas de correspondance proche) et le BIC répondant. Retrouvez une requête et une réponse complètes dans notre exemple VoP, ou les payloads et codes de schéma dans la documentation API.

Traitez l'appel de vérification comme une étape supplémentaire avant l'autorisation du paiement. Authentifiez-vous avec un bearer token, envoyez en POST le nom et l'IBAN du bénéficiaire, lisez le résultat, puis branchez : poursuivez sur MATCH, affichez le nom suggéré et demandez confirmation sur CLOSE_MATCH, bloquez l'approbation automatique sur NO_MATCH et laissez le payeur décider sur NOT_APPLICABLE. L'endpoint étant sans état, le même appel s'insère dans un checkout, un onboarding fournisseur, une remise ou un lot de paiements sans modifier vos rails de paiement.

Des deux, selon l'usage. Comme contrôle de bénéficiaire, elle répond à la question « à qui appartient cet IBAN ? » pour un bénéficiaire unique - utile pour une équipe finance ou un payeur avant d'envoyer de l'argent. Comme API de validation des paiements, elle exécute le même contrôle dans un flux automatisé, de sorte que chaque paiement ou versement est validé par rapport au titulaire du compte avant de partir.

« Know your payee » désigne le réflexe pratique de confirmer le nom du titulaire du compte avant de payer, plutôt que de faire confiance aux coordonnées d'une facture ou d'un e-mail. L'API transforme ce réflexe en étape automatisée : le nom est comparé à l'IBAN et vous obtenez une réponse claire - correspondance, correspondance proche, aucune correspondance ou non applicable - en bien moins d'une seconde.

Confirmation of Payee (CoP) est le schéma britannique de contrôle de nom ; Verification of Payee (VoP) est le schéma EPC utilisé dans toute l'UE et l'espace SEPA. Si vous avez besoin des deux, cherchez un fournisseur qui couvre le schéma SEPA VoP via une seule intégration et renvoie les résultats standardisés, pour que votre code ne change pas d'un marché à l'autre. RoxPay fournit la VoP comme une seule API REST, avec les codes de schéma, le BIC répondant et le temps de traitement dans chaque réponse.

Cinq choses. La couverture : quelles banques et quels pays le fournisseur peut atteindre dans tout l'espace SEPA. La latence : si les résultats tiennent de façon fiable dans la fenêtre des paiements instantanés. La précision : comment le rapprochement des noms gère les correspondances proches et les noms commerciaux face aux raisons sociales. Les sens : si la VoP en demande et en réponse passe par la même intégration. Et le support : qui surveille le service et ce qui se passe quand un PSP répondant est injoignable. Demandez par écrit le payload de réponse et les codes d'erreur : ils vous en disent plus qu'une liste de fonctionnalités.

Branchez sur le code du schéma, pas sur le libellé affiché. Dans votre UI, traitez MTCH comme un passage silencieux, CMTC comme un avertissement souple qui affiche le nom suggéré et demande confirmation au payeur, et NMTC comme un avertissement ferme qui bloque l'approbation automatique. NOAP n'est ni l'un ni l'autre : cela signifie que le contrôle n'a pas pu être mené à bien, donc indiquez au payeur que la vérification était indisponible et laissez-le décider. C'est en gardant les quatre codes distincts dans votre code que le comportement des avertissements devient prévisible.

Oui, et c'est même recommandé. L'endpoint est sans état : le même appel vérifie un bénéficiaire à la création de la fiche - une étape d'onboarding vendeur, fournisseur ou salarié - puis de nouveau juste avant que l'argent ne parte. C'est le re-contrôle au moment du paiement qui détecte les coordonnées bancaires modifiées après l'onboarding, là où se produit généralement la fraude au détournement de paiement. Un seul endpoint sert ces deux moments : vous ne maintenez donc pas deux contrôles.

Oui. Les identifiants du sandbox sont émis séparément de ceux de production, ce qui vous permet de dérouler des scénarios de correspondance, de correspondance proche et de non-correspondance sur l'API avant de passer en production. Les mêmes identifiants donnent aussi accès au tableau de bord RoxBusiness, où vous pouvez lancer des contrôles ponctuels sans écrire de code.

Vous recevez NOT_APPLICABLE (code de schéma NOAP) comme réponse 200 valide, et non comme erreur de transport. Cela signifie que le contrôle n'a pas pu être mené à bien pour cet IBAN à ce moment-là. Traitez-le comme une inconnue plutôt que comme une panne : informez le payeur que la vérification était indisponible et laissez-le décider s'il poursuit. Les vraies défaillances techniques utilisent les codes de statut 4xx et 5xx avec un code d'erreur lisible par une machine.