Segurança e testes de pagamentos

Controles incluídos

• Credencial de alta entropia usada apenas em chamadas de servidor para servidor, com permissão de pagamentos separada.
• Intenção duradoura antes de qualquer início externo.
• Perfil, beneficiário, conceito, valor e instituição definidos e validados pelo servidor.
• Estado sensível criptografado; token do widget vinculado à empresa, intenção, expiração e origem, preservado apenas como hash.
• Identificadores determinísticos das tentativas e fencing para impedir uma reiniciação automática após um resultado ambíguo.
• Retorno de chamada dedicado, consumo único, versão otimista e controle de locação.
• Auditoria com dados sensíveis removidos: nunca inclui chaves de acesso, IBAN completo, IP, retornos de chamada, respostas completas ou status opaco.
• Destinos e redirecionamentos explicitamente permitidos, com HTTPS, tempos máximos e respostas limitadas.
• Mensagens de widgets com origem exata, validação event.source e esquema versionado.

Integrar o sandbox

Pergunte Wealth Reader:

1. um código de acesso privado autorizado para pagamentos e para o perfil exigido;
2. a HTTPS fonte exata que hospedará o widget;
3. os limites acordados de quantidade e frequência;
4. Acesso ao modo sandbox, que não move dinheiro.

Sempre verifique profile-institutions; no sandbox, ele retornará apenas uma instituição simulada. Crie a intenção com expected_mode: "mock" e verifique se a atestação da resposta também indica mock antes de entregar a token ao navegador.

Tente pelo menos:

• repetição da criação com a mesma chave e conflito com outro corpo;
• instituição ou modo alterado;
• token expirou e a origem não foi permitida;
• popup bloqueado e retorno SCA;
• status intermediário pendente, reconciliação e fechamento do widget;
• Confirmação somente após o recebimento payment_status: settled.

Solicitar Ativação Real

Antes de um teste de dinheiro, confirme com Wealth Reader:

• que a instituição aparece na pré-consulta para seu código de acesso;
• que o perfil e sua versão sejam aprovados;
• que a origem, callback e fluxo SCA eram validados de ponta a ponta;
• que existem limites para quantidade, frequência, reconciliação e desativação de emergência;
• que existe um humano autorizado responsável pelo teste mínimo.

A conta de origem pode ser exigida por uma instituição e, nesse caso, é solicitada pelo widget durante a autorização. O endereço de rede do usuário é derivado na fronteira controlada do API; o cliente não deve enviá-lo. Nem esses dados nem a IBAN do devedor são expostos em eventos.

A sequência com curl prepara e consulta a intenção, mas não completa a autenticação bancária. O usuário deve continuar no navegador bancário ou no aplicativo.

A ativação do perfil exige três controles de implantação independentes e exatos: WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04 e inclusão da empresa associada à credencial em WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. Esses valores não substituem a permissão de pagamentos nem ativam, por si só, uma instituição real.

O contrato publicado atualmente indica que psuIp não é utilizado, mas testes históricos do conector exigiram isso. Wealth Reader mantém a ativação travada até que a implantação alvo seja verificada, por meio de um teste aprovado de ponta a ponta e de opções, tanto o campo exato quanto a política de proxy confiável. Não deve ser ativado usando cabeçalhos encaminhados arbitrários ou assumindo que a declaração publicada reflete comportamento histórico.

A resolução privada de DNS e a terminação TLS para o serviço interno dependem de cada implantação: esse SDK não presume que eles existam ou sejam alcançáveis. Eles devem ser verificados a partir do tempo de execução API antes de permitir conexões de saída ou aceitar novas intenções.

O que não fazer

• Envie a chave API , o beneficiário completo ou dados internos para o navegador.
• Inventando uma instituição que não foi devolvida pela pré-consulta.
• Repita automaticamente um início ambíguo.
• Registre IBAN, endereço de rede, callback ou resposta completa do banco.
• Interprete o fim da interação como liquidação.
• Reutilize rotas de agregação bancária, tokens ou callbacks.