O que a Adyen cobre vs. o que continua a ser seu
A Adyen, como qualquer processador PCI DSS Nível 1, atesta o código que corre dentro do seu próprio iframe. Não atesta a página que o enquadra. Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 regem os scripts da sua página de pagamento no navegador do consumidor, e a maioria desses scripts é sua. O limite de propriedade de scripts é o bordo da frame da Adyen, e desloca-se conforme a integração da Adyen que implementa.
"Usamos a Adyen" diz ao seu QSA onde os dados do cartão são processados. Não lhe diz o que o seu gestor de etiquetas, a sua analítica, a sua ferramenta de consentimento e o seu carregador do SDK estão a fazer no navegador enquanto um comprador digita um cartão. Este artigo mapeia esse limite para cada tipo de integração da Adyen para que saiba com precisão quais os scripts que a Adyen lhe tira do prato e quais os que tem de inventariar, autorizar e monitorizar.
O limite conforme o tipo de integração da Adyen
A Adyen oferece várias integrações de front-end, e cada uma desenha o limite do iframe num lugar diferente. Quanto mais dentro de uma frame servida pela Adyen estiverem os campos do cartão, menor é a parte do caminho dos dados de pagamento que é sua, mas os scripts da página envolvente são seus em todos os casos.
| Integração da Adyen | Onde os campos do cartão renderizam | SAQ típico | A Adyen controla (o seu iframe) | Você controla ao abrigo de 6.4.3 / 11.6.1 |
|---|---|---|---|---|
| Hosted Payment Pages (redirecionamento) | Domínio da Adyen, redirecionamento completo | SAQ A | Entrada do cartão e a página alojada | Os scripts da página a partir da qual redireciona |
| Drop-in | iframe da Adyen, montado pelo SDK da Adyen | SAQ A | Entrada do cartão dentro da frame Drop-in | O carregador do SDK + todos os outros scripts da página-mãe |
| Components (Custom Card) | Um iframe da Adyen por campo | SAQ A | Cada frame de campo de entrada alojado | O carregador do SDK, o JS de layout, todos os scripts envolventes |
| Só API (servidor para servidor) | O seu próprio DOM, sem iframe da Adyen | SAQ D | Nada do lado do cliente | Todo o formulário e cada script que o consiga ler |
O padrão é consistente. A responsabilidade da Adyen termina no bordo do iframe. O carregador que obtém e monta o SDK da Adyen é o seu script, servido a partir da sua origem, e está em âmbito. E também tudo o que o rodeia.
Hosted Payment Pages: o caso mais leve, mas não nulo
Um redirecionamento completo para uma página de pagamento alojada pela Adyen é o caso mais limpo para os dados do cartão. O PAN é introduzido no domínio da Adyen, por isso nunca toca o seu DOM. Este é o cenário clássico de SAQ A.
A armadilha está em assumir que "redirecionamento" significa "sem âmbito do lado do cliente". A página a partir da qual redireciona, a sua página de carrinho ou de início de checkout, continua a correr os seus scripts e continua a fazer parte da jornada de pagamento do cliente. Um script manipulado aí pode sobrepor um formulário de cartão falso antes do redirecionamento, ou reescrever o destino do redirecionamento para um processador falsificado. Desde a alteração do SAQ A de janeiro de 2025, a própria elegibilidade depende de confirmar que a sua página de pagamento não é suscetível a ataques baseados em scripts, por isso as páginas que controla ainda precisam de uma narrativa defensável sobre os seus scripts.
Drop-in e Components: a falha mais comum
Drop-in e Components são onde a maioria das equipas aterra, e onde o limite é mais mal interpretado. A Adyen serve os campos reais do cartão dentro de um iframe, o que mantém o PAN fora do seu DOM e suporta o SAQ A. Bom. Mas para renderizar essa frame, a sua página carrega o Adyen Web SDK e corre um script carregador que você escreveu e aloja. Esse carregador é um script de página de pagamento ao abrigo de 6.4.3, ponto final.
À sua volta está o resto do seu checkout: Google Tag Manager, analítica, repetição de sessões, chat, gestão de consentimento, SDKs de fraude e o que quer que o marketing publicou no último sprint. Nenhum desses é da Adyen. Todos executam no mesmo contexto de navegador que a frame da Adyen, na sua origem, e qualquer um deles pode ser comprometido através de um ataque à cadeia de fornecimento de scripts de terceiros.
O incidente da Polyfill[.]io de 2024 é a versão concreta deste risco: um único script de terceiros fidedigno incorporado em mais de 490 000 sites tornou-se malicioso de um dia para o outro e serviu código de redirecionamento e skimming a páginas de pagamento (Sansec, 2024). Um comerciante com Adyen Drop-in e campos de cartão perfeitamente isolados ficava igualmente exposto, porque o código malicioso entrou na própria página do comerciante, não no iframe da Adyen.
Só API: o limite desaparece
Uma integração só API, de servidor para servidor, remove o iframe da Adyen inteiramente. Você recolhe os dados do cartão no seu próprio formulário, no seu próprio DOM, e envia-os para a Adyen a partir do seu servidor. Não há isolamento do lado do cliente, pelo que este caminho normalmente o deixa no SAQ D com o conjunto de controlos mais pesado.
Para 6.4.3 e 11.6.1 este é o pior caso. Cada script da página está agora no caminho direto dos dados em bruto do cartão à medida que são digitados. O inventário, a justificação por escrito, a verificação de integridade e a deteção de manipulação que lhe cabem já não protegem a página à volta de um iframe seguro; protegem o próprio campo do cartão. Um único script injetado ou modificado pode ler o PAN da entrada a cada tecla e exfiltrá-lo. A maioria das equipas que escolhe só API fá-lo pelo controlo do checkout, e herda toda a carga de monitorização do lado do navegador como preço.
O que 6.4.3 e 11.6.1 exigem, independentemente da integração
O tipo de integração move o limite, mas os dois controlos nunca o abandonam. Tornaram-se obrigatórios em 31 de março de 2025 (PCI Security Standards Council, PCI DSS v4.0.1).
- Inventarie cada script da página de pagamento (6.4.3). Enumere cada script que carrega no navegador no seu fluxo de pagamento, incluindo o carregador do SDK da Adyen e cada etiqueta de terceiros, com uma razão escrita de lá estar.
- Autorize antes de publicar (6.4.3). Aprove cada script e cada alteração. Uma etiqueta não revista disparada por uma ferramenta de marketing falha isto por si só.
- Confirme a integridade (6.4.3). Verifique que cada script autorizado não foi alterado sem aprovação.
- Detete manipulação e alerte (11.6.1). Execute um mecanismo de deteção de alterações que alerte sobre modificação não autorizada de scripts da página de pagamento e de cabeçalhos HTTP com impacto na segurança, avaliados tal como recebidos pelo navegador do consumidor pelo menos a cada sete dias ou conforme a sua análise de risco direcionada.
- Mantenha evidência que sobreviva a uma auditoria (6.4.3 / 11.6.1). Conserve versões dos scripts, aprovações e histórico de alterações para que um QSA veja registos, não afirmações.
Nenhum destes é satisfeito pela Adyen, porque nenhum deles é sobre onde os dados do cartão são processados. São sobre o que corre no navegador, e o navegador é a metade que a Adyen lhe devolve.
Como a cside cobre a metade que a Adyen lhe deixa
A versão manual, uma folha de cálculo de scripts mais um diff de capturas de ecrã semanal, parte no momento em que um gestor de etiquetas injeta scripts dinamicamente, que é a norma num checkout real da Adyen. Também produz o tipo de evidência de que os auditores desconfiam.
A cside PCI Shield é construída para a fatia exata que a Adyen não cobre:
- Inventário e justificação automatizados (6.4.3). A cside descobre cada script na página de pagamento, incluindo o carregador do SDK da Adyen e todas as etiquetas de terceiros, constrói o inventário e regista a autorização e a justificação num só lugar.
- Integridade e deteção de manipulação em tempo real (11.6.1). A cside monitoriza scripts e cabeçalhos HTTP com impacto na segurança de forma contínua e alerta sobre alterações não autorizadas, em vez de amostrar num cron semanal e esperar que nada tenha escapado.
- Evidência pronta para auditoria. A cside arquiva cada versão de cada script com histórico completo, para que entregue a um QSA registos forenses que mapeiam de forma limpa o lado do comerciante na repartição de responsabilidades.
A cside não substitui a Adyen. A Adyen retira os dados do cartão de âmbito dentro do seu iframe; a cside cobre os scripts da página-mãe que 6.4.3 e 11.6.1 lhe deixam, seja qual for a integração que executar.
Mais leituras sobre a cside
- Pode usar a Adyen para PCI DSS?
- A Stripe torna-o conforme com PCI? O que 6.4.3 e 11.6.1 ainda exigem
- Guia de conformidade do lado do cliente do PCI DSS 4.0.1
- cside PCI Shield
A partir de 2026-06-18, trate isto como orientação operacional, não como aconselhamento jurídico. Confirme o texto exato dos controlos e a sua elegibilidade para o SAQ com o seu QSA, o seu conselheiro jurídico ou o responsável de risco.
