A API Verification of Payee

Sim. Uma chamada de verificação responde de forma síncrona, normalmente em muito menos de um segundo, e inclui o BIC do banco respondente e o tempo de processamento do PSP para monitorizar o desempenho.

As chamadas são autenticadas com um bearer token sobre HTTPS. Também pode usar o painel RoxBusiness para verificações pontuais sem escrever código.

Um resultado normalizado (MATCH, CLOSE_MATCH, NO_MATCH, NOT_APPLICABLE), o código de tipo de correspondência do esquema SEPA, um id de verificação, o BIC respondente, o tempo de processamento e o seu id externo opcional.

Sim - chame o endpoint por registo para verificar um ficheiro inteiro de fornecedores ou beneficiários antes de uma remessa. Está construída para alto débito.

Sim. O endpoint não guarda estado, pelo que pode chamá-lo sempre que um beneficiário é criado - um passo de onboarding de vendedor ou fornecedor - e de novo imediatamente antes de cada pagamento. Reverificar no momento do pagamento deteta dados bancários alterados após o onboarding, que é onde costuma acontecer a fraude de desvio de faturas e pagamentos.

A verificação é uma chamada REST por registo, pelo que um ficheiro de pagamento com milhares de beneficiários é tratado como um lote: percorra o ficheiro, chame o endpoint por registo e recolha os resultados antes de libertar a remessa. Como a API está construída para alto débito, pode regular o ciclo conforme a sua própria janela de libertação, em vez de ficar limitado pelo onboarding banco a banco. Fale connosco sobre os seus volumes e dimensionamos o débito consigo.

Sim. A mesma verificação está disponível no painel RoxBusiness, pelo que uma equipa financeira ou de operações pode verificar um único beneficiário - uma verificação de 'know your payee' antes de enviar dinheiro - enquanto os programadores usam a API para fluxos automatizados.

Sim. A verificação compara o nome submetido com o titular da conta registado, seja uma pessoa singular ou uma empresa, e é usada no fluxo de mandatos SEPA Direct Debit da RoxPay como pré-verificação.

NO_MATCH não é um erro de transporte - é uma resposta 200 válida que indica que o nome não pertence ao IBAN. Trate-a como uma paragem firme na sua UI ou remessa: mostre um aviso claro, bloqueie a aprovação automática e faça reverificar o beneficiário antes do envio.

CLOSE_MATCH (código de esquema CMTC) significa que o nome está quase certo - falta um nome do meio, uma razão social vs um nome comercial. A resposta traz o nome verificado do titular, pelo que pode mostrá-lo como sugestão e pedir confirmação ao pagador em vez de rejeitar o pagamento.

Para pessoas coletivas o esquema permite a verificação face ao identificador da organização (por exemplo, a Partita IVA / Codice Fiscale italiana) além do nome. Envia o identificador no pedido e a API devolve o resultado padrão de correspondência - útil quando a razão social e o nome comercial diferem.

Sim. Para uma remessa, percorra o seu ficheiro de fornecedores ou salários e chame o endpoint de verificação por registo antes de libertar o lote. Construída para alto débito, permite às equipas financeiras validar em massa os IBAN face aos nomes antes de cada remessa.

Sim. Envia um pedido JSON com o nome e o IBAN do beneficiário e recebe o resultado, o nome verificado (numa correspondência parcial) e o BIC respondente. Veja um pedido e uma resposta completos no nosso exemplo de VoP, ou os payloads e códigos de esquema na documentação da API.

Trate a chamada de verificação como um passo adicional antes de o pagamento ser autorizado. Autentique-se com um bearer token, envie por POST o nome e o IBAN do beneficiário, leia o resultado e ramifique: avance em MATCH, mostre o nome sugerido e peça confirmação em CLOSE_MATCH, bloqueie a aprovação automática em NO_MATCH e deixe o pagador decidir em NOT_APPLICABLE. Como o endpoint não guarda estado, a mesma chamada encaixa no checkout, no onboarding de fornecedores, numa remessa ou num lote de pagamentos sem alterar os seus canais de pagamento.

É as duas coisas, consoante a tarefa. Como verificador de beneficiário, responde a 'a quem pertence este IBAN?' para um único beneficiário - útil para uma equipa financeira ou para quem paga antes de enviar dinheiro. Como API de validação de pagamentos, executa a mesma verificação dentro de um fluxo automatizado, pelo que cada pagamento ou transferência é validado face ao titular da conta antes de sair.

'Know your payee' é o hábito prático de confirmar o nome do titular da conta antes de pagar, em vez de confiar nos dados de uma fatura ou de um email. A API transforma esse hábito num passo automatizado: o nome é comparado com o IBAN e obtém uma resposta clara - correspondência, correspondência parcial, sem correspondência ou não possível - em muito menos de um segundo.

Confirmation of Payee (CoP) é o esquema britânico de verificação de nomes; Verification of Payee (VoP) é o esquema EPC usado em toda a UE e no espaço SEPA. Se precisar dos dois, procure um fornecedor que cubra o esquema SEPA VoP através de uma única integração e devolva os resultados normalizados, para que o seu código não mude de mercado para mercado. A RoxPay fornece a VoP como uma única API REST, com os códigos de esquema, o BIC respondente e o tempo de processamento em cada resposta.

Cinco coisas. Cobertura: que bancos e países o fornecedor consegue alcançar em toda a SEPA. Latência: se os resultados cabem de forma fiável na janela dos pagamentos instantâneos. Precisão: como a correspondência de nomes trata as correspondências parciais e os nomes comerciais face às razões sociais. Direções: se o pedido e a resposta da VoP passam pela mesma integração. E apoio: quem monitoriza o serviço e o que acontece quando um PSP respondente está inacessível. Peça por escrito o payload da resposta e os códigos de erro - dizem-lhe mais do que uma lista de funcionalidades.

Ramifique pelo código do esquema, não pelo rótulo apresentado. Na sua UI, trate MTCH como uma passagem silenciosa, CMTC como um aviso suave que mostra o nome sugerido e pede confirmação ao pagador, e NMTC como um aviso firme que bloqueia a aprovação automática. NOAP não é nenhum dos dois: significa que a verificação não pôde ser concluída, por isso diga ao pagador que a verificação não estava disponível e deixe-o decidir. Manter os quatro códigos separados no seu código é o que torna o comportamento dos avisos previsível.

Sim, e deve. O endpoint não guarda estado, pelo que a mesma chamada verifica um beneficiário quando o registo é criado - um passo de onboarding de vendedor, fornecedor ou colaborador - e de novo imediatamente antes de o dinheiro sair. Reverificar no momento do pagamento é o que deteta dados bancários alterados após o onboarding, que é onde costuma acontecer a fraude de desvio de pagamentos. Um único endpoint serve os dois momentos, pelo que não mantém duas verificações.

Sim. As credenciais de sandbox são emitidas separadamente das de produção, para que possa testar os fluxos de correspondência, correspondência parcial e sem correspondência contra a API antes de entrar em produção. As mesmas credenciais dão também acesso ao painel RoxBusiness, onde pode fazer verificações pontuais sem escrever código.

Recebe NOT_APPLICABLE (código de esquema NOAP) como uma resposta 200 válida, não como um erro de transporte. Significa que a verificação não pôde ser concluída para esse IBAN naquele momento. Trate-a como uma incógnita e não como uma falha: informe o pagador de que a verificação não estava disponível e deixe-o decidir se quer continuar. As falhas técnicas reais usam códigos de estado 4xx e 5xx com um código de erro legível por máquina.