MyBankMatch

Preparar a conexão

1. Tenha uma licença ativa com o produto MY_BANK_MATCH e cota disponível.
2. Abra Clientes · MyBankMatch com a sua sessão autenticada e a licença correspondente.
3. Clique em Connect bank e conclua a autenticação na janela hospedada pela Wealthreader. A conexão tokenizada fica associada à sua api_key; o token bancário não é entregue ao navegador nem é um parâmetro de consulta.
4. Atualize o estado em Clientes. Se o banco exigir uma nova autenticação, use Reconnect. O painel também oferece um teste explícito de IBAN/nome e as últimas consultas mascaradas.

O emissor usa um link assinado de uso único e uma continuação vinculada ao navegador. Se o link tiver expirado ou essa continuação se perder, solicite outro em Clientes.

Enviar uma consulta a partir do backend

POST https://api.wealthreader.com/my-bank-match/
Content-Type: application/x-www-form-urlencoded

Não se envia JSON nem se usa X-API-Key: a chave faz parte do corpo codificado como formulário, assim como em /entities/.

curl --request POST 'https://api.wealthreader.com/my-bank-match/' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'api_key=<SU_API_KEY>' \
  --data-urlencode 'iban=ES9321005707250200257112' \
  --data-urlencode 'name=Wealthreader S.L.'

<SU_API_KEY> é um marcador, não uma chave utilizável. O IBAN e o nome ilustram a solicitação de aceitação; não foi verificado aqui que produzam um veredito concreto. A consulta pode ser faturável: não a dispare como uma atualização automática da interface.

O MyBankMatch devolve o veredito do banco. Ele não substitui essa resposta por um cálculo local de similaridade de nomes. Também não cria, autoriza nem executa uma ordem de pagamento.

Interpretar a resposta

HTTP 200 indica que foi obtido um resultado do produto, não que o nome necessariamente coincida. Verifique success e, em seguida, payload.result.

Exemplo ilustrativo de correspondência parcial (nome e SESSION simulados):

{
  "success": true,
  "payload": {
    "result": "PARTIAL_MATCH",
    "suggested_name": "TITULAR DE EJEMPLO S.L."
  },
  "statistics": {
    "SESSION": "0000000000000000",
    "execution_time": 0.42,
    "warnings": []
  }
}

statistics.SESSION identifica esta consulta para diagnóstico e execution_time é expresso em segundos. Uma resposta correta não inclui um objeto error nem devolve o token da conexão bancária.

Em caso de correspondência parcial, mostre separadamente o nome informado e suggested_name; não substitua silenciosamente o primeiro. Se você os apresentar em HTML, escape-os como texto.

A URL de preparação de NOT_CONFIGURED e REAUTH_REQUIRED é:

https://www.wealthreader.com/clients/#my-bank-match

Por exemplo, uma reautenticação pode devolver este payload:

{
  "result": "REAUTH_REQUIRED",
  "setup_url": "https://www.wealthreader.com/clients/#my-bank-match",
  "reason_code": 2000
}

reason_code deve ser um inteiro entre 2000 e 2999; por exemplo, 2000 corresponde a uma falha de credenciais. Reconecte a partir de Clientes em vez de repetir a verificação indefinidamente.

NOT_POSSIBLE pode se dever a uma indisponibilidade transitória, uma resposta bancária inválida, a falta de um IBAN pagador utilizável ou um adaptador indisponível. Guarde reason para diagnóstico, mas não converta esses casos em uma confirmação de titularidade nem em uma correspondência negativa.

Validação, cota e erros

Os erros de validação ou de licença seguem o envelope habitual: success: false, payload, error.code, error.message e statistics com SESSION, duração e avisos. As validações controladas respondem HTTP 400; a mensagem pode incluir informações de diagnóstico e não deve ser usada como identificador estável.

Os erros de entrada e os resultados não conclusivos não consomem a cota de consultas faturáveis. A cota é consumida quando o banco devolve MATCH, PARTIAL_MATCH ou NO_MATCH; se outra chamada a esgotar simultaneamente, é devolvido o erro de limite em vez de confirmar o resultado como correto.

O preço de 0,10 EUR corresponde apenas aos três resultados conclusivos do contrato. O modo de faturamento por consulta e a exclusão de sessões de vinculação verificadas estão implementados, mas exigem o esquema prévio e a ativação/revisão das consultas de faturamento por um operador; esta página não comprova essa implantação. Somente uma associação verificada pelo servidor permite excluir uma sessão do cálculo padrão de credenciais/produtos: um operation_id do navegador não basta. Tentativas expiradas, não auditadas ou históricas sem essa procedência não têm isenção automática, nem são garantidos outros efeitos gratuitos no contador.

Limites desta versão

• A verificação usa a conexão tokenizada própria do cliente com o Santander Particulares. A compatibilidade bancária real ainda não foi validada, e a publicação desta página não garante disponibilidade comercial.
• O fluxo hospedado contempla credenciais e desafios OTP/push, seleção de método e QR raster limitado. Os desafios por script, OAuth, CAPTCHA ou multicontrato não estão implementados e produzem um erro seguro; você pode solicitar um novo link em Clientes.
• O painel exige uma sessão autenticada. Carregar o estado, voltar da janela do banco e atualizar o histórico não envia verificações ao banco: somente o envio explícito do formulário realiza uma consulta potencialmente faturável.
• Mantenha a api_key no seu servidor e não registre credenciais, tokens bancários nem nomes completos em logs de integração desnecessários. Use SESSION para o suporte e respeite a distinção entre veredito, erro e estado de configuração.