Produção e segurança

SDK e scripts oficiais

Use @soarlabz/security-sdk@1.2.0 ou uma versão posterior compatível. A versão 1.1.1 usava o fluxo Zendry anterior; não combina com o contrato data-only atual.

O wrapper carrega https://api.zendry.co/sdk/v1/zendry.js. Não use o script antigo de cdn.zendry.com, nem ZendrySDKThreeds.init_threeds. A chamada atual é Zendry.threeDS() antes da cobrança e Zendry.completeThreeDS(action) quando a cobrança solicitar autenticação.

Content Security Policy

Base de CSP para coleta de device Zendry, substituindo a API pela origem real da sua integração:

Content-Security-Policy:
  script-src 'self' https://api.zendry.co;
  connect-src 'self' https://api-dash.unipaybr.com https://api.zendry.co;

O SDK relata falhas e timeout no carregamento. A CSP não deve ser desabilitada para contornar um erro; ajuste apenas as origens aprovadas. A Finance API é chamada pelo seu backend e não exige liberação de navegador.

Chaves e contexto do comprador

• Apenas a chave pública pk_ fica no navegador. Chaves secretas e credenciais Zendry ficam no backend.
• Nunca envie a chave secreta a uma página de teste ou use Basic com segredo no frontend.
• Envie o device oficial em toda venda Zendry, com o offset UTC em horas com sinal.
• IP e user-agent precisam representar o comprador final em uma integração em cadeia.
• No link da plataforma, a Server Action assina o contexto com CHECKOUT_FORWARDING_SECRET, configurado somente nos servidores web e API. A assinatura vincula timestamp, link, chave de idempotência, IP e user-agent.
• Na Vercel, a origem do IP é o header x-vercel-forwarded-for definido pela plataforma. Um ambiente próprio só deve habilitar CHECKOUT_TRUST_FORWARDED_HEADERS quando seu ingress substituir headers externos por valores confiáveis.
• Sem contexto confiável em produção, o link interrompe a solicitação de cartão antes da cobrança. Nunca substitua o IP por um endereço inventado.

Cartão e tokenização

A tokenização no navegador permite enviar um token ao seu backend em vez de PAN/CVV. Essa integração reduz a exposição dos dados, mas o enquadramento PCI depende da arquitetura real, dos scripts e controles da página e da avaliação aplicável.

Não registre PAN, CVV, action, token ou segredo em logs. Não persista dados do cartão em localStorage/sessionStorage. A recuperação do link usa somente referência de tentativa, estado e uma action que ainda não foi iniciada; o identificador da sessão é removido da recuperação antes de iniciar o challenge.

Confirmação e idempotência

Crie uma chave por intenção e reutilize-a na preparação, criação e recuperação da cobrança. Após timeout ou perda de conexão, consulte a mesma referência. Nunca repita a mutação financeira com outra chave para descobrir o que aconteceu.

Valide a assinatura do webhook no backend ou reconsulte a cobrança na adquirente. O retorno authorized do navegador serve à experiência visual; o pedido só pode ser liberado quando o servidor confirmar a captura e concluir os efeitos financeiros. O link aguarda captured com confirmation_pending false antes do sucesso e redirecionamento.

Navegadores e homologação

Use HTTPS e navegadores com fetch, AbortController, Promise e crypto.randomUUID. Verifique scripts e iframes no navegador desktop e móvel usado pelos compradores. O SDK browser não foi projetado para execução de device/challenge no servidor.

O sandbox Zendry não possui challenge real. Testes locais com respostas simuladas verificam os estados da aplicação; a homologação de produção deve também comprovar emissor, webhook/reconsulta e registro financeiro. Nunca confunda um build aprovado ou a coleta de device com confirmação de pagamento.