La API Verification of Payee

Sí. Una llamada de verificación responde de forma síncrona, normalmente en mucho menos de un segundo, e incluye el BIC del banco respondedor y el tiempo de procesamiento del PSP para monitorizar el rendimiento.

Las llamadas se autentican con un bearer token sobre HTTPS. También puede usar el panel RoxBusiness para comprobaciones puntuales sin escribir código.

Un resultado normalizado (MATCH, CLOSE_MATCH, NO_MATCH, NOT_APPLICABLE), el código de tipo de coincidencia del esquema SEPA, un id de verificación, el BIC respondedor, el tiempo de procesamiento y su id externo opcional.

Sí - llame al endpoint por registro para verificar un fichero entero de proveedores o beneficiarios antes de una remesa. Está construida para alto rendimiento.

Sí. El endpoint no tiene estado, así que puede llamarlo cada vez que se crea un beneficiario - por ejemplo, en el alta de un vendedor o un proveedor - y de nuevo justo antes de cada pago. Reverificar en el momento del pago detecta datos bancarios que cambiaron después del alta, que es donde suele ocurrir el fraude por redirección de facturas y pagos.

La verificación es una llamada REST por registro, así que un fichero de pago con miles de beneficiarios se gestiona como un lote: recorra el fichero, llame al endpoint por registro y reúna los resultados antes de liberar la remesa. Como la API está construida para alto rendimiento, puede marcar el ritmo del bucle según su propia ventana de liberación en lugar de quedar limitado por el onboarding banco por banco. Cuéntenos sus volúmenes y dimensionamos el rendimiento con usted.

Sí. La misma verificación está disponible en el panel RoxBusiness, así que un equipo de finanzas u operaciones puede comprobar un beneficiario concreto - una comprobación de tipo 'know your payee' antes de enviar dinero - mientras los desarrolladores usan la API para flujos automatizados.

Sí. El control compara el nombre enviado con el titular de la cuenta registrado, ya sea una persona física o una empresa, y se usa en el flujo de mandatos SEPA Direct Debit de RoxPay como comprobación previa.

NO_MATCH no es un error de transporte - es una respuesta 200 válida que indica que el nombre no pertenece al IBAN. Trátela como una parada en firme en su UI o remesa: muestre una advertencia clara, bloquee la aprobación automática y haga revisar el beneficiario antes de enviar.

CLOSE_MATCH (código de esquema CMTC) significa que el nombre es casi correcto - falta un segundo nombre, una razón social vs un nombre comercial. La respuesta lleva el nombre verificado del titular, así que puede mostrarlo como sugerencia y pedir confirmación al pagador en lugar de rechazar el pago.

Para personas jurídicas el esquema permite la verificación frente al identificador de la organización (por ejemplo, la Partita IVA / Codice Fiscale italiana) además del nombre. Envíe el identificador en la solicitud y la API devuelve el resultado estándar de coincidencia - útil cuando la razón social y el nombre comercial difieren.

Sí. Para una remesa, recorra su fichero de proveedores o nóminas y llame al endpoint de verificación por registro antes de liberar el lote. Construida para alto rendimiento, permite a los equipos financieros validar en masa los IBAN frente a los nombres antes de cada remesa.

Sí. Envíe una solicitud JSON con el nombre del beneficiario y el IBAN y recibirá el resultado, el nombre verificado (en una coincidencia parcial) y el BIC respondedor. Consulte una solicitud y una respuesta completas en nuestro ejemplo de VoP, o los payloads y códigos de esquema en la documentación de la API.

Trate la llamada de verificación como un paso más antes de autorizar el pago. Autentíquese con un bearer token, envíe por POST el nombre y el IBAN del beneficiario, lea el resultado y ramifique: continúe con MATCH, muestre el nombre sugerido y pida confirmación con CLOSE_MATCH, bloquee la aprobación automática con NO_MATCH y deje decidir al pagador con NOT_APPLICABLE. Como el endpoint no tiene estado, la misma llamada encaja en un checkout, en el alta de proveedores, en una remesa o en un lote de pagos sin cambiar sus raíles de pago.

Es ambas cosas, según la tarea. Como comprobador de beneficiarios responde a '¿a quién pertenece este IBAN?' para un solo beneficiario, algo útil para un equipo de finanzas o para quien paga antes de enviar dinero. Como API de validación de pagos ejecuta la misma comprobación dentro de un flujo automatizado, de modo que cada pago o abono se valida frente al titular antes de salir.

'Know your payee' es el hábito práctico de confirmar el nombre del titular antes de pagar, en lugar de fiarse de los datos de una factura o un correo. La API convierte ese hábito en un paso automatizado: el nombre se compara con el IBAN y obtiene una respuesta clara de coincidencia, coincidencia parcial, sin coincidencia o no posible en mucho menos de un segundo.

Confirmation of Payee (CoP) es el esquema británico de control de nombres; Verification of Payee (VoP) es el esquema EPC usado en toda la UE y SEPA. Si necesita ambos, busque un proveedor que cubra el esquema SEPA VoP con una sola integración y devuelva los resultados estandarizados, para que su código no cambie según el mercado. RoxPay ofrece la VoP como una única API REST con los códigos de esquema, el BIC respondedor y el tiempo de procesamiento en cada respuesta.

Cinco cosas. Cobertura: a qué bancos y países llega el proveedor en toda SEPA. Latencia: si los resultados caben de forma fiable dentro de la ventana de los pagos instantáneos. Precisión: cómo trata el control de nombres las coincidencias parciales y las razones sociales frente a los nombres comerciales. Direcciones: si la VoP de solicitud y la de respuesta llegan con la misma integración. Y soporte: quién monitoriza el servicio y qué ocurre cuando un PSP respondedor no está disponible. Pida por escrito el payload de respuesta y los códigos de error: le dirán más que una lista de funciones.

Ramifique según el código del esquema, no según la etiqueta que se muestra. En su UI, trate MTCH como un paso silencioso, CMTC como una advertencia suave que muestra el nombre sugerido y pide confirmación al pagador, y NMTC como una advertencia firme que bloquea la aprobación automática. NOAP no es ninguna de las dos: significa que la comprobación no se pudo completar, así que indique al pagador que la verificación no estaba disponible y deje que decida. Mantener los cuatro códigos separados en su código es lo que hace predecible el comportamiento de las advertencias.

Sí, y debería. El endpoint no tiene estado, así que la misma llamada verifica a un beneficiario cuando se crea el registro - el alta de un vendedor, un proveedor o un empleado - y de nuevo justo antes de mover el dinero. Reverificar en el momento del pago es lo que detecta datos bancarios que cambiaron después del alta, que es donde suele ocurrir el fraude por redirección de pagos. Un solo endpoint sirve para ambos momentos, así que no mantiene dos comprobaciones.

Sí. Las credenciales de sandbox se emiten por separado de las de producción, así que puede ejecutar flujos de coincidencia, coincidencia parcial y sin coincidencia contra la API antes de salir en producción. Esas mismas credenciales también dan acceso al panel RoxBusiness, donde puede hacer comprobaciones puntuales sin escribir código.

Recibe NOT_APPLICABLE (código de esquema NOAP) como una respuesta 200 válida, no como un error de transporte. Significa que la comprobación no se pudo completar para ese IBAN en ese momento. Trátelo como un desconocido y no como un fallo: informe al pagador de que la verificación no estaba disponible y deje que decida si continúa. Los fallos técnicos reales usan códigos de estado 4xx y 5xx con un código de error legible por máquina.