Sem a conformidade, a IATA restringe o cartão do seu cliente.

Não exatamente, e a diferença importa. A Resolução 812 condiciona a autorização para usar o Customer Card Payment Method à conformidade com o PCI DSS. Se a sua agência aceita cartão contra o próprio credenciamento ou emite bilhete com cartão do passageiro, a exigência se aplica. Se a operação não aceita, não transmite nem armazena dado de cartão em nenhum momento, existe uma declaração específica para esse caso, que substitui a evidência de conformidade.

A Resolução 812 trata a não conformidade como um evento de risco e determina que a IATA restrinja imediatamente o uso do Customer Card Payment Method. A agência continua no BSP, mas para de emitir com o cartão do cliente. Se o provedor do sistema de emissão não conseguir aplicar a restrição, as companhias aéreas do BSP são informadas. A restrição permanece até a agência demonstrar que atende aos requisitos. Uma única ocorrência registrada também pesa no histórico de risco, o que pode levar a exigência de garantia financeira.

Não encontramos previsão de multa da IATA no texto da Resolução 812. O que a IATA faz é restringir o método de pagamento e registrar o evento de risco. Multas existem no ecossistema de cartões, mas são das bandeiras, previstas nos contratos e cobradas pelo adquirente, normalmente após um incidente de vazamento. São coisas diferentes e vale não confundir, porque a resposta muda conforme a origem da cobrança.

Não. A DM11 não é QSA e não emite certificado. Nós preparamos a sua agência: desenhamos e reduzimos o escopo, implantamos os controles, escrevemos as políticas, treinamos a equipe e organizamos a evidência. A autoavaliação e a atestação são assinadas pela própria agência, que é como o mecanismo funciona. Quando o caso exige avaliação formal por um QSA, trabalhamos junto com um parceiro credenciado, e a avaliação é conduzida por ele.

Na maioria dos casos, não. Para a maior parte dos comerciantes, incluindo praticamente todas as agências de viagem, o caminho é a autoavaliação assinada pelo próprio comerciante. A avaliação formal por QSA costuma ser exigida em volumes muito altos de transação, ou quando o adquirente pede especificamente, o que pode acontecer após um incidente. Quem define isso é o seu adquirente junto com a bandeira, não a IATA e não nós.

Depende de como o cartão entra e se ele fica armazenado, não do seu faturamento. Vale um alerta: é comum ler que agência de viagens se enquadra no SAQ C-VT, e na maioria dos casos brasileiros não se enquadra. Esse tipo exige terminal virtual do adquirente numa máquina isolada e não admite venda pela internet. Quem digita cartão no campo de forma de pagamento do sistema de reservas está em outro cenário, normalmente mais extenso. Declarar o tipo errado cria exposição maior do que não declarar, porque a atestação passa a afirmar algo que a operação não sustenta.

Depende do seu ambiente, e não do seu porte. O escaneamento externo por uma empresa aprovada é exigido quando há componentes publicados na internet dentro do escopo, como um site de reservas próprio ou um acesso remoto exposto. Uma agência que opera só por telefone e sistema de reservas, sem ativo público no escopo, pode legitimamente não ter esse requisito. A IATA não define isso: quem define é o padrão, conforme o seu ambiente, e o seu adquirente.

O código de verificação, nunca. O BSP Manual for Agents é explícito ao dizer que a agência não deve armazenar nem anotar esse código, e o padrão proíbe reter dado de autenticação depois da autorização, sem exceção e sem que criptografia resolva. Já o número do cartão pode ser retido se houver necessidade de negócio, com proteção adequada e prazo de descarte definido. Na prática, a maioria das agências descobre que não precisa guardar, e essa é a decisão que mais reduz risco e esforço de uma vez.

Enviar o número do cartão sem proteção por tecnologias de mensagem de usuário final contraria o padrão, e isso inclui e-mail, SMS e aplicativos de mensagem. Sabemos que é o hábito mais enraizado do setor, e a saída não é proibir sem alternativa: é oferecer um canal que o cliente aceite com a mesma facilidade, normalmente um link de pagamento. Trocar o canal costuma ser a primeira medida do projeto, porque interrompe a entrada de dado novo enquanto o resto ainda está sendo tratado.

Não. Um cartão virtual continua sendo um número de cartão: se a sua agência o recebe, digita e transmite, ele permanece no escopo. O ganho real do cartão virtual é outro e não é pequeno, porque limite e uso único reduzem o dano em caso de fraude ou vazamento. Mas isso é redução de risco, não isenção de escopo, e vale desconfiar de quem apresenta as duas coisas como sinônimo.

A versão 4.0.1. A 3.2.1 foi aposentada em março de 2024 e a 4.0 em dezembro de 2024. Vale registrar uma data que pega muita gente: a maior parte dos requisitos novos da versão 4 era boa prática até 31 de março de 2025 e passou a ser obrigatória naquela data, entre eles a autenticação em duas etapas para todo acesso ao ambiente de cartão e o treinamento que cobre phishing. Quem preparou documentação antes disso e não revisou provavelmente está declarando contra uma versão que não existe mais.

Depende de quanto o cartão está espalhado hoje e de quanto dá para reduzir de escopo logo no começo. Uma agência que só precisa trocar o canal de recebimento e organizar evidência caminha rápido. Outra que armazena cartão em vários sistemas e grava ligação tem um trabalho anterior a fazer. Preferimos não publicar um prazo padrão porque ele seria chute: depois do diagnóstico conseguimos estimar o seu caso com data.

Não. A adequação acontece junto com a operação, e a primeira medida em geral melhora a venda em vez de atrapalhar, porque link de pagamento costuma ser mais rápido para o cliente do que ditar cartão ao telefone. O que exige planejamento é o tempo da equipe: o consultor precisa aprender o procedimento novo, e a evidência não se produz sozinha.

Tem, e resolver junto economiza esforço. Dado de cartão é dado pessoal, então o mesmo vazamento que aciona penalidade contratual das bandeiras também dispara as obrigações da LGPD, incluindo a comunicação à autoridade e aos titulares. Boa parte do que o PCI DSS pede, como saber onde o dado está, limitar acesso e definir descarte, é exatamente o que a LGPD cobra. Tratamos as duas exigências no mesmo projeto quando a agência quer.