Proteside Proteção do pagamento
Cadastre recebedores confiáveis, escolha entre monitorar e bloquear e ajuste as listas que o SDK usa no checkout da loja.
Configurações → Proteção do pagamento define como o SDK se comporta no checkout da loja selecionada. As mudanças chegam às páginas pela configuração remota do SDK, sem mexer no site, com uma exceção: o canal de release.
Esta página explica cada ajuste do ponto de vista de quem usa o painel. Os detalhes técnicos estão em Configuração do SDK.
Antes de começar
- Só proprietários e administradores alteram esta tela. Os demais papéis veem tudo, mas sem os botões de edição, e a faixa do topo avisa "Somente proprietários e administradores podem alterar estas configurações."
- A tela diz que as alterações chegam ao SDK em até 60 segundos. Em lojas com pouco tráfego, a resposta antiga pode continuar sendo servida por mais alguns minutos. Para testar uma mudança, aguarde alguns minutos e recarregue o checkout.
- Recebedores confiáveis são salvos na hora. Todo o resto só vale depois de Salvar alterações.
Recebedores confiáveis
São as chaves que recebem os pagamentos da sua loja. O SDK compara o recebedor de cada código Pix, endereço cripto, VPA UPI ou boleto exibido no checkout com esta lista e alerta na primeira divergência. Sem recebedor cadastrado para um método, essa verificação fica desligada para ele.
Escolha o método
Na área Recebedores confiáveis (1), escolha o Método: Pix, Bitcoin, Ethereum, UPI ou Boleto (banco).
Informe a chave
- Pix: CPF, CNPJ, e-mail, telefone (
+55…) ou chave aleatória. - Bitcoin: endereço
bc1q…,1…ou3…. - Ethereum: endereço
0xcom 40 caracteres hexadecimais. - UPI: VPA no formato
nome@banco. - Boleto (banco): código do banco emissor (3 dígitos) ou a linha digitável completa.
Se quiser, preencha um Rótulo (até 80 caracteres), por exemplo "conta principal".
Clique em Adicionar
O recebedor é salvo na hora e aparece na tabela com a chave mascarada.
O Proteside guarda só o hash SHA-256 e uma máscara da chave: a chave completa nunca é armazenada. Por isso não é possível ver ou editar a chave depois de salva. Para trocá-la, cadastre a nova e remova a antiga.
Na tabela, use a chave Ativa para desligar um recebedor sem apagá-lo, ou o ícone de lixeira para removê-lo.
Também dá para chegar aqui pelo botão Cadastrar da tela Integridade de Pagamento, que já abre o formulário no método certo. Como a verificação funciona no checkout está em Recebedores confiáveis.
Modo de proteção
O Modo de proteção (2) define o que o SDK faz quando detecta uma adulteração.
| Modo | O que acontece |
|---|---|
| Monitorar (recomendado nas primeiras semanas) | O SDK detecta e gera alertas, sem corrigir nada na página. |
| Bloquear | Além de alertar, o SDK tenta desfazer a adulteração: remove scripts desconhecidos injetados, restaura o destino original de formulários, remove elementos sobrepostos ao checkout, reescreve códigos Pix, boleto e cripto adulterados, restaura a área de transferência e remove service workers fora da lista. |
Regras e lista de GTM bloqueiam também no modo Monitorar
A tela descreve o Monitorar como "sem interferir na página". Na prática, as Regras de bloqueio e a lista de containers GTM permitidos impedem scripts de carregar nos dois modos. Se você quer só observar, não crie regras de bloqueio e deixe a lista de GTM vazia.
Teste antes de ativar o Bloquear
No modo Bloquear, uma regra errada pode quebrar o checkout. Fique algumas semanas em Monitorar, revise os alertas e os scripts, e teste o Bloquear em uma página de pouco tráfego antes de ativar.
Algumas detecções, como tentativas de envio de dados para fora, keyloggers e valores adulterados, só geram alerta em qualquer modo. A lista completa está em Modo monitor e modo bloqueio.
Modo desenvolvedor
O Modo desenvolvedor (3) pausa o SDK: ele envia só um registro de visita por carregamento de página e não executa nenhuma proteção. Use durante integrações e testes.
Não esqueça de desligar
Com o modo desenvolvedor ligado, a loja fica sem proteção e a Saúde do SDK mostra o SDK como pausado. As regras de bloqueio gravadas no snippet continuam valendo, mas sem gerar nenhum evento no painel.
Canal de release do SDK
O Canal de release do SDK (4) escolhe qual versão do SDK a loja carrega:
stable(padrão): versão validada.latest: a publicação mais recente, para testar novidades antes.
Trocar o canal exige recolar o snippet
A tela diz que não é preciso reinstalar. Mas o canal está escrito no endereço do SDK dentro do snippet: o snippet já publicado continua carregando o canal antigo. Depois de trocar o canal e salvar, copie o snippet de novo em Páginas e Domínios e publique.
Salvar
Quando há mudanças pendentes, a barra no canto inferior direito mostra Alterações não salvas. Clique em Salvar alterações (5). O botão fica desabilitado se algum valor estiver fora da faixa permitida (borda vermelha no campo). Toda alteração salva fica registrada na Auditoria.
Listas permitidas
Mais abaixo ficam as listas que dizem ao SDK o que é legítimo no checkout. Lista vazia significa nenhuma restrição para aquele item.
Origens de iframe esperadas
Hosts dos iframes de pagamento legítimos, como o do seu provedor de pagamento e o da autenticação 3DS. Com a lista preenchida, o SDK alerta iframes de provedores fora dela dentro do checkout.
- Digite o host (por exemplo
checkout.psp.com) e clique em Adicionar ou tecle Enter. Se você colar uma URL inteira, só o host é aproveitado. Use*.para incluir subdomínios. - Em Sugestões (PSPs do catálogo) (1), clique em um provedor para incluí-lo. As sugestões priorizam provedores do país da loja, definido em Loja. Use a busca ou Ver todos para encontrar outros.
- Até 50 hosts.
Containers GTM permitidos
IDs do Google Tag Manager autorizados, no formato GTM-XXXXXXX (2). Com a lista preenchida, containers fora dela são
bloqueados no checkout. Até 20 containers.
A lista de GTM também bloqueia Google Analytics 4 e Google Ads
Com a lista preenchida, tags do Google Analytics 4 (G-…) e do Google Ads (AW-…) carregadas por JavaScript,
inclusive pelo próprio GTM, também são bloqueadas, e não há como incluí-las na lista. Antes de preencher, confirme
com quem cuida do marketing se a loja usa essas tags no checkout. Lembre-se também de recolar o snippet: ele guarda
uma cópia desta lista.
Service workers permitidos
Caminhos dos service workers legítimos do site, como /sw.js (3). O caminho começa com / e não tem espaços. Com a
lista preenchida, um service worker fora dela gera alerta e, no modo Bloquear, é removido. Até 20 caminhos.
Métodos de pagamento
Marque os métodos que a loja oferece (4): Pix, cartão de crédito, boleto, cripto e métodos instantâneos de outros países.
Desmarcar um método não desliga a detecção
A tela diz que desmarcar métodos reduz ruído e que, sem nenhum método marcado, a verificação fica desativada. Na prática, o SDK continua reconhecendo e validando todos os métodos, e uma lista vazia é tratada como Pix e cartão. Use a lista para refletir o que a loja oferece, não para silenciar alertas.
Campos sensíveis
Campos que o SDK vigia contra leitura por scripts de terceiros, como número do cartão, CVV e documento (5).
- Com Usar a lista padrão da Proteside ligado, vale a lista padrão do SDK.
- Desligado, informe seus próprios seletores, um por linha ou separados por vírgula (até 100). A sua lista substitui a padrão; inclua também os campos de cartão que você quer manter vigiados.
Avançado
Ajustes finos que normalmente não precisam mudar:
- Calibração (segundos): tempo depois do carregamento em que o SDK aprende os scripts da página. De 10 a 120, padrão 30.
- Verificação de overlay (ms): intervalo entre verificações de elementos sobrepostos ao checkout. A partir de 500, padrão 2000.
- Ordem de instalação: o que fazer quando o snippet não é o primeiro script do
<head>. Avisar (alerta) (padrão) gera um alerta; Silenciar não gera.