Solução de problemas

O dashboard só considera o SDK ativo quando recebe eventos de clientes reais. Confira, na ordem:

1. O snippet está publicado? Veja o código-fonte da página de checkout publicada e procure Proteside Start. Limpe caches do site, do tema e da CDN.
2. Está no domínio certo? O snippet precisa estar nas páginas em que o checkout roda de fato, que podem ficar em outro domínio ou subdomínio.
3. Alguém abriu o checkout? Abra a página você mesmo e recarregue o dashboard depois de alguns segundos.
4. O SDK carrega? Rode Proteside.getStatus() no console. Se der erro, veja o item seguinte.
5. Os eventos saem? Na aba Rede, POST …/api/sdk/events deve responder 202. Veja o item O SDK roda, mas nada chega ao dashboard.

Se a página Saúde do SDK mostra Só verificação sintética, o verificador do Proteside encontrou o snippet, mas nenhum cliente real passou pelo checkout ainda.

O shield.js não carregou. Causas comuns:

• o snippet não está publicado, ou só o bootstrapper foi colado;
• a Content Security Policy não permite https://cdn.proteside.com em script-src (o console mostra Refused to load the script);
• uma extensão de bloqueio de anúncios ou rastreadores bloqueou o arquivo (teste em uma janela anônima sem extensões);
• um plugin de otimização alterou ou removeu a tag.

Espere alguns segundos: o SDK só termina de iniciar depois de buscar a configuração (até 2 s). Se continuar false:

• Falta o data-key na tag do shield.js. Sem ele, o SDK não inicializa e não mostra aviso.
• A chave tem formato inválido. O console mostra [Proteside] Initialization failed silently com Invalid apiKey format. A chave começa com pk_live_.
• A tag foi carregada como type="module". Remova esse atributo.

O SDK envia esse aviso, e getStatus().installationOrderValid fica false, quando existe algum <script> na página antes do bootstrapper.

Para ver quais são os dois primeiros scripts da página, rode no console:

Array.from(document.scripts).slice(0, 2).map((s) => s.src || s.textContent.slice(0, 40))

• O primeiro item começa com "use strict"; (seguido de var __ProteBoots ou, se a loja tem regras inline, de window.__PROTE_INLINE__=): o bootstrapper é o primeiro script e a ordem está correta.
• O primeiro item começa com window.__PROTE_INLINE__= e o segundo com "use strict";var __ProteBoots: é o caso 1.
• Qualquer outra coisa: é o caso 2.

Depois de corrigir, resolva o alerta no dashboard. Se ele não voltar no próximo acesso à página, a ordem está certa.

Esse aviso não entra no status de conformidade em Evidências PCI DSS.

Caso 1: snippet antigo, com a linha window.__PROTE_INLINE__ numa tag própria. Em lojas com regras de bloqueio ou containers GTM permitidos, o snippet do dashboard trazia a configuração num <script> separado, antes do bootstrapper. Hoje ela vem no início do próprio <script> do bootstrapper. A partir do SDK 1.1.2, a tag antiga não conta como script anterior, desde que contenha só a atribuição window.__PROTE_INLINE__={…};. Se o aviso continua:

• veja em Saúde do SDK se a página ainda usa uma versão anterior à 1.1.2;
• confira se ninguém acrescentou código à linha window.__PROTE_INLINE__ nem reescreveu o JSON: com qualquer outro conteúdo, a tag volta a contar como script anterior;
• ou recole o snippet de Páginas e Domínios. O formato atual tem uma única tag inline e não depende da versão do SDK.

Não apague a configuração window.__PROTE_INLINE__ para fazer o aviso sumir: é ela que bloqueia scripts desde o primeiro byte da página.

Caso 2: há outro script antes do snippet. Mova o snippet para o topo do <head> e publique de novo. Se o script anterior vem do tema, de um plugin ou da própria plataforma e não pode ser movido, a proteção continua funcionando, mas com cobertura parcial: o que aquele script fizer antes do bootstrapper não é observado. Em Next.js, confira a ordem final das tags no código-fonte da página publicada.

Essas detecções dependem do bootstrapper. Se só a tag do shield.js foi colada, ou se um plugin de otimização transformou o bootstrapper em arquivo externo ou adiado, o SDK roda com cobertura reduzida, e getStatus() não indica isso. Confira no console:

typeof window.__PROTE_BOOT_TS__ === 'number' // deve ser true

Se for false, recole o snippet completo e exclua-o das otimizações de JavaScript.

A URL do shield.js (canal stable ou latest) está escrita no snippet. Depois de trocar o canal em Proteção do pagamento, copie o snippet de novo em Páginas e Domínios e publique.

Se a Saúde do SDK mostra mais de uma versão ativa por alguns dias, verifique se todas as páginas usam o mesmo snippet. Logo depois de uma atualização, é normal ver duas versões por causa do cache do navegador e da CDN.

Mensagens comuns no console e o que liberar:

A mensagem de script inline informa o hash 'sha256-…' a incluir. Veja Content Security Policy e headers.

Com Containers GTM permitidos preenchido, o SDK bloqueia qualquer gtag/js com ID fora da lista, inclusive as tags do Google Analytics 4 (G-…) e do Google Ads (AW-…) disparadas pelo próprio GTM. A lista só aceita IDs GTM-…, então não há como liberar esses IDs.

Para resolver:

1. Em Proteção do pagamento, esvazie a lista Containers GTM permitidos e clique em Salvar alterações.
2. Copie o snippet de novo em Páginas e Domínios e publique. A lista também fica gravada no snippet e continua bloqueando no início do carregamento até você recolar.

O bloqueio vale nos dois modos de proteção, Monitorar e Bloquear.

• O script está no HTML da página. Scripts escritos no HTML executam antes de o SDK carregar e não podem ser impedidos no navegador. Em Scripts, eles aparecem com o aviso de que continuam carregando pelo HTML. Remova a tag do HTML ou do tema.
• A regra é por Hash de conteúdo. O SDK não aplica regras desse tipo. Use Domínio ou URL do script.
• A regra está inativa. Regras inativas não são enviadas ao SDK.
• A mudança ainda não chegou. Veja Uma mudança no dashboard não chegou ao checkout.

1. Em Regras, desative a regra que casa com o script afetado. Lembre-se de que uma regra por Domínio bloqueia o domínio inteiro e todos os subdomínios.
2. Copie o snippet de novo em Páginas e Domínios e publique: as regras ficam gravadas no snippet.
3. Se ligou o modo Bloquear, volte para Monitorar enquanto investiga.

Ligar o Modo desenvolvedor não desfaz os bloqueios gravados no snippet. Veja Pausa e modo desenvolvedor.

É o esperado. Todo script novo encontrado pelo SDK entra no inventário com o status Precisa revisão e espera a sua decisão. Para cumprir o PCI DSS 4.0, requisito 6.4.3, autorize cada script legítimo com uma justificativa ou bloqueie os indevidos. Você pode autorizar todos os scripts próprios de uma vez e criar políticas para automatizar decisões recorrentes.

Um script autorizado volta para Precisa revisão quando o conteúdo muda ou quando a validade da autorização vence. Veja Scripts e Políticas.

• Cache da configuração: a configuração pode ficar em cache por 60 segundos, e a CDN pode servir a versão anterior por alguns minutos a mais. Aguarde e recarregue o checkout.
• Regras e containers GTM: ficam gravados no snippet. Recole o snippet depois de mudá-los.
• Canal de release: exige recolar o snippet.

Veja a resposta de GET …/api/sdk/config e de POST …/api/sdk/events na aba Rede:

Um domínio que já enviou eventos ficou 24 horas sem sessões reais. Verifique se o snippet ainda está publicado (uma atualização de tema ou de template pode removê-lo) e se o checkout recebeu visitas no período. O alerta é resolvido sozinho quando o tráfego volta.

• Nenhum cliente pagou com Pix ainda com o SDK na página. O status muda com a primeira leitura válida.
• O código Pix está em um campo <input> ou <textarea>. O SDK lê só texto. Exiba o código como texto. Veja Integridade de pagamento e Pix.
• O snippet não está na página que mostra o Pix, por exemplo uma página de pagamento separada do checkout.
• O código está dentro de um iframe do provedor de pagamento. O SDK lê só a página principal, não o conteúdo de iframes.

O recebedor lido no código não está entre os Recebedores confiáveis. Antes de tratar como ataque, confira:

• se a chave cadastrada é a mesma que aparece no código copia e cola gerado pelo seu provedor de pagamento. Alguns provedores geram o código com uma chave própria, diferente da chave da loja;
• se todas as chaves usadas pela loja estão cadastradas e ativas.

Se a chave do código não pertence à loja nem ao seu provedor, trate como incidente: abra o alerta em Alertas.

Um BRCode dinâmico traz uma URL de cobrança em vez da chave do recebedor, então não há chave para comparar com a lista de confiáveis. O SDK continua comparando o código exibido com a primeira leitura da página. Se o código traz o valor, informe também o valor esperado com Proteside.expectPayment().