“Pedi à IA para criar meu checkout”: o porquê de seu negócio digital estar a um passo do abismo

Porque é que a segurança de pagamentos online se tornou essencial

[02:08] André Cruz começou por abordar um dos principais desafios da utilização de inteligência artificial no desenvolvimento de soluções de pagamento: a diferença entre criar um sistema funcional e construir uma infraestrutura preparada para enfrentar ameaças reais.

A inteligência artificial tinha tornado possível desenvolver interfaces, formulários e integrações com APIs de pagamento em poucos minutos.

Contudo, a capacidade de gerar código não garantia a existência de mecanismos adequados de prevenção de fraude.

Segundo André, grande parte destas soluções era construída com base no chamado happy path, ou seja, num cenário em que tudo acontecia conforme o esperado.

O comprador preenchia os seus dados, introduzia o cartão de crédito e concluía a transação sem qualquer comportamento suspeito.

O problema surgia quando o checkout deixava de receber apenas compradores legítimos e passava a ser utilizado por sistemas automatizados que procuravam explorar vulnerabilidades.

O risco de confundir simplicidade com segurança

[04:05] André destacou que a mesma inteligência artificial que facilitava o desenvolvimento de produtos digitais também podia ser utilizada para aumentar a capacidade de atuação dos atacantes.

Para um negócio online, isto significava que a segurança não podia ser avaliada apenas pela experiência de compra.

Um checkout precisava de reunir diferentes capacidades:

• Identificação de comportamentos suspeitos.

• Monitorização de transações em tempo real.

• Deteção de padrões associados a ataques automatizados.

• Proteção da reputação junto das processadoras de pagamento.

• Capacidade de bloquear tentativas fraudulentas sem prejudicar excessivamente a conversão legítima.

A principal mensagem foi que um checkout preparado para vender não era, necessariamente, um checkout preparado para resistir a ataques.

O que é card testing e como funciona este tipo de fraude

[05:03] Um dos principais riscos abordados por André Cruz foi o card testing, também conhecido como teste de cartões de crédito.

Este tipo de fraude consistia na utilização de sistemas automatizados para verificar se determinados cartões estavam ativos e podiam realizar pagamentos.

Ao contrário de outros esquemas fraudulentos, o objetivo principal do atacante nem sempre era adquirir um produto ou serviço.

O verdadeiro objetivo era validar cartões que poderiam ser posteriormente utilizados noutras operações fraudulentas.

Como acontecia um ataque de card testing?

André explicou que o processo seguia, normalmente, várias etapas.

1. Obtenção dos dados: o atacante conseguia uma lista de cartões comprometidos, muitas vezes proveniente de fugas de informação ou de mercados ilegais.

2. Identificação de um checkout vulnerável: procurava produtos ou serviços com valores reduzidos e mecanismos de proteção insuficientes.

3. Automatização das tentativas: utilizava scripts para submeter um elevado número de transações em pouco tempo.

4. Análise das respostas: identificava quais os cartões que tinham permitido concluir pagamentos.

5. Utilização posterior: os cartões validados podiam ser utilizados em compras fraudulentas de valor superior, noutras plataformas.

[08:20] André explicou que os produtos digitais de baixo valor eram particularmente interessantes para estes ataques.

Uma transação de valor reduzido podia passar despercebida ao verdadeiro titular do cartão durante mais tempo, aumentando a janela de oportunidade do fraudador.

Porque é que o negócio atacado também sofria consequências?

Mesmo quando o fraudador não pretendia usufruir do produto, o comerciante acabava por suportar os efeitos da atividade suspeita.

Entre os principais riscos estavam:

• Aumento súbito do número de tentativas de pagamento.

• Deterioração das taxas de aprovação.

• Maior exposição a pagamentos não autorizados.

• Aumento de reclamações e chargebacks.

• Necessidade de interromper vendas para investigar o ataque.

• Risco de restrições impostas pelos prestadores de serviços de pagamento.

O card testing representava, assim, uma ameaça à estabilidade financeira e operacional do negócio, mesmo quando a empresa não era o alvo final da fraude.

Porque é que pequenos e grandes negócios são alvos de ataques

[10:34] André Cruz desmistificou duas ideias frequentes entre empreendedores digitais.

A primeira era que um pequeno negócio não tinha dimensão suficiente para atrair atacantes.

A segunda era que uma grande empresa, por dispor de uma equipa técnica e de processos mais estruturados, estava automaticamente protegida.

Na prática, ambos os perfis apresentavam vulnerabilidades diferentes.

Pequenos negócios: a fragilidade dos mecanismos de defesa

[11:33] Segundo André, os negócios mais pequenos podiam tornar-se alvos atrativos devido à menor maturidade dos seus processos tecnológicos.

Era frequente encontrarem-se operações que utilizavam checkouts desenvolvidos internamente, plugins pouco robustos ou soluções criadas sem um sistema adequado de análise de risco.

Nestes cenários, o atacante podia explorar a ausência de mecanismos de deteção e realizar um número elevado de tentativas antes de ser bloqueado.

Existia, contudo, uma particularidade: um aumento anormal de transações num negócio com poucas vendas diárias podia tornar-se rapidamente evidente.

O risco aumentava quando o ataque acontecia durante a madrugada, ao fim de semana ou em períodos sem monitorização ativa.

Grandes negócios: a fraude escondida no volume de vendas

[15:16] Nas operações de maior dimensão, o desafio era diferente.

Uma empresa que processava milhares de encomendas diariamente podia apresentar mecanismos de proteção mais desenvolvidos.

No entanto, o elevado volume transacional também oferecia oportunidades de camuflagem.

André descreveu situações em que tentativas fraudulentas eram distribuídas entre transações legítimas, procurando evitar alertas imediatos.

Como exemplo, referiu um grande lançamento realizado por um cliente da Guru, durante o qual foram identificadas tentativas de aproveitamento do elevado tráfego comercial.

Qual era a principal diferença?

[17:41] A conclusão apresentada por André foi que a dimensão de uma empresa não eliminava a sua exposição à fraude.

O que mudava era a forma como os atacantes procuravam explorar as características da operação.

Como os ataques de BIN colocam os pagamentos em risco

[18:09] Outro conceito explicado por André Cruz foi o BIN (Bank Identification Number), associado à identificação do emissor de um cartão.

No episódio, André explicou a utilização dos primeiros seis dígitos do cartão para reconhecer características como o emissor e a bandeira. Tecnicamente, os identificadores de emissão também podiam utilizar oito dígitos, dependendo do formato adotado.

Esta informação era relevante porque determinadas tentativas de fraude envolviam conjuntos de cartões pertencentes à mesma faixa de identificação.

Qual era o papel do BIN nos ataques?

André explicou que os atacantes podiam utilizar informações sobre faixas de cartões para organizar tentativas automatizadas de validação.

Também abordou a existência de verificações matemáticas da estrutura dos números de cartão, como o algoritmo de Luhn.

Contudo, um número matematicamente válido não significava que o cartão existisse, estivesse ativo ou pudesse autorizar pagamentos.

Este ponto reforçava a necessidade de sistemas de segurança capazes de analisar comportamentos e contextos transacionais, em vez de dependerem exclusivamente da estrutura dos dados submetidos.

Porque era importante não armazenar dados sensíveis dos cartões?

[06:28] André partilhou um exemplo ocorrido durante a migração tecnológica de uma universidade.

Nesse processo, a equipa identificou dezenas de milhares de registos com dados completos de cartões de crédito armazenados diretamente numa base de dados.

A situação representava um risco significativo de exposição de informação financeira.

Para corrigir o problema, foi necessário realizar previamente a tokenização dos cartões junto da processadora de pagamento.

A tokenização permitiu substituir os dados sensíveis por identificadores que podiam ser utilizados nas operações autorizadas sem exigir que a plataforma mantivesse os números completos.

Esta experiência demonstrou a importância de:

• Reduzir a exposição de dados financeiros sensíveis.

• Recorrer à tokenização através de prestadores adequados.

• Aplicar os requisitos de segurança PCI DSS correspondentes.

• Evitar o armazenamento desnecessário de números completos de cartão.

• Definir responsabilidades claras entre comerciantes, plataformas e processadoras.

Para operações SaaS e negócios digitais, esta abordagem contribuía para reduzir riscos e simplificar a gestão da infraestrutura de pagamentos.

O impacto das fraudes nas assinaturas e nos chargebacks

[21:00] Os negócios baseados em subscrições apresentavam um risco adicional quando um pagamento fraudulento não era identificado no momento inicial.

André Cruz explicou que uma assinatura de baixo valor podia continuar a gerar cobranças periódicas até que o verdadeiro titular do cartão identificasse a utilização não autorizada.

Isso significava que uma única subscrição fraudulenta podia originar várias transações contestadas.

Como a fraude recorrente podia multiplicar os prejuízos

Numa operação SaaS, o problema não se limitava ao valor da primeira mensalidade.

Quando uma subscrição não autorizada permanecia ativa durante vários ciclos de faturação, o titular do cartão podia contestar diferentes cobranças.

As consequências incluíam:

• Reversão de várias transações associadas à mesma subscrição.

• Custos operacionais e eventuais taxas de contestação.

• Aumento dos indicadores de fraude e chargeback.

• Potenciais reservas ou retenções de saldo.

• Restrições à capacidade de processar novos pagamentos.

[22:52] André destacou que as bandeiras de cartões e os participantes do ecossistema de pagamentos acompanhavam estes indicadores com atenção.

Uma concentração de transações contestadas podia levantar alertas sobre a qualidade dos mecanismos de prevenção de fraude utilizados pelo comerciante.

Para um SaaS, a segurança das cobranças recorrentes era, por isso, um elemento essencial da previsibilidade da receita.

Não bastava adquirir novos subscritores. Era igualmente necessário assegurar que os pagamentos provinham de clientes legítimos e que o processo de cobrança não comprometia a continuidade financeira da operação.

Um caso real: 119 tentativas de compra em poucos minutos

[24:20] Para demonstrar como funcionavam estes ataques na prática, André Cruz apresentou um episódio recentemente intercetado pela Digital Manager Guru.

Um cliente que comercializava um produto de baixo valor sofreu 119 tentativas de compra em poucos minutos.

Segundo os dados partilhados, as transações apresentavam características invulgares.

<text-placeholder />

Porque é que as tentativas pareciam legítimas?

[25:20] André explicou que os atacantes não se limitavam a repetir os mesmos dados em todas as tentativas.

Os sistemas utilizados conseguiam alterar nomes, documentos, números de telefone, endereços e informações dos cartões.

Também recorriam a diferentes origens de ligação e procuravam simular características de navegadores comuns.

Isoladamente, alguns destes elementos podiam parecer normais.

No entanto, quando analisados em conjunto, revelavam padrões incompatíveis com o comportamento habitual de compradores reais.

A velocidade de preenchimento, a repetição de determinadas características e a ausência de interações orgânicas com o checkout contribuíram para identificar a atividade automatizada.

O que este caso demonstrou?

[27:15] André explicou que a deteção não dependia de um único sinal evidente.

Era o cruzamento de múltiplas informações que permitia reconhecer um ataque, mesmo quando os dados apresentados procuravam simular compradores legítimos.

A principal aprendizagem foi que um sistema antifraude precisava de interpretar o comportamento da transação e não apenas verificar se os campos do formulário estavam corretamente preenchidos.

Porque é que o CAPTCHA não era suficiente para impedir fraudes

[28:41] Uma das soluções frequentemente associadas à proteção de formulários online era o CAPTCHA.

A sua função consistia em ajudar a distinguir interações humanas de determinadas atividades automatizadas.

Contudo, André Cruz explicou por que motivo este mecanismo, utilizado isoladamente, não era suficiente para proteger um checkout moderno.

Ataques que contornavam a interface do checkout

Alguns ataques podiam ser direcionados diretamente aos endpoints de uma API, sem reproduzirem a navegação normal de um comprador.

Nestes casos, um desafio visual apresentado no navegador não constituía, por si só, uma defesa adequada.

A proteção exigia validações e controlos também do lado do servidor.

Sistemas automatizados mais sofisticados

André destacou que os atacantes tinham acesso a mecanismos capazes de ultrapassar determinados desafios de verificação.

Consequentemente, a simples presença de um CAPTCHA não assegurava a prevenção de tentativas de card testing.

O impacto na conversão

[30:09] Outro problema identificado foi o atrito provocado aos compradores legítimos.

Um utilizador que tentava concluir uma compra através de uma ligação móvel podia abandonar o checkout quando confrontado com desafios adicionais de validação.

Para empresas dependentes de volume de vendas e taxas de conversão, essa fricção representava um custo comercial.

A pergunta que realmente importava

[31:36] André defendeu uma mudança de abordagem.

Em vez de depender apenas da identificação de um utilizador como humano ou automatizado, a plataforma precisava de avaliar se determinada transação, tendo em conta o seu contexto e perfil de risco, apresentava indícios de fraude.

Essa análise exigia a combinação de diferentes camadas de proteção, critérios de risco e sinais comportamentais.

O objetivo era aumentar a capacidade de deteção sem introduzir obstáculos desnecessários no percurso de compra.

Como a fraude prejudicava a reputação junto das processadoras

[32:30] Um dos pontos mais relevantes do episódio foi a relação entre segurança do checkout, reputação do comerciante e aprovação de pagamentos.

André Cruz explicou que as processadoras acompanhavam diferentes indicadores associados às operações comerciais.

Quando um checkout encaminhava repetidamente tentativas fraudulentas, podia provocar alterações significativas nas taxas de aprovação e nos padrões transacionais.

O efeito dos falsos positivos

[33:00] Segundo André, um histórico de transações suspeitas podia contribuir para uma avaliação de risco menos favorável.

Dependendo das regras dos prestadores de serviços de pagamento, isso podia resultar em maior escrutínio e em recusas de operações legítimas.

Esta situação era particularmente prejudicial porque afetava compradores que utilizavam cartões válidos e pretendiam concluir compras reais.

Ou seja, o negócio corria o risco de perder vendas não devido à falta de procura, mas por dificuldades associadas ao seu processamento de pagamentos.

A importância de atuar antes da processadora

[33:57] André salientou que o checkout precisava de funcionar como uma primeira linha de defesa.

Um sistema antifraude preventivo podia identificar e bloquear determinadas tentativas suspeitas antes de estas serem enviadas à processadora de pagamento.

Esta abordagem contribuía para limitar a exposição da operação a padrões de atividade maliciosa.

Proteger a qualidade das transações submetidas era também uma forma de proteger a capacidade futura de vender.

Como a inteligência coletiva reforçava a prevenção de fraude

[34:26] André Cruz apresentou a inteligência coletiva como uma das principais vantagens das plataformas de pagamento que operavam com um volume elevado e diversificado de transações.

A lógica era simples: quanto maior a variedade de comportamentos observados, maior podia ser a capacidade de identificar padrões que dificilmente seriam reconhecidos por uma operação isolada.

O valor dos dados em escala

[35:25] No episódio, André partilhou alguns indicadores aproximados da infraestrutura da Digital Manager Guru.

A plataforma realizava mais de 1,4 milhões de avaliações de risco por mês, abrangendo milhares de clientes e diferentes perfis de compradores.

Esta diversidade permitia observar comportamentos em diferentes segmentos, produtos, valores de transação e modelos de negócio.

André explicou ainda que a plataforma cruzava informação com tecnologia externa especializada em prevenção de fraude, incluindo o Google Cloud Fraud Defense.

Desta forma, a capacidade de análise não ficava limitada ao histórico de um único comerciante.

A vantagem da aprendizagem entre operações

[37:48] Um dos exemplos apresentados mostrou que uma rede utilizada num ataque contra determinado cliente já tinha sido identificada anteriormente em tentativas dirigidas a outras operações.

Este conhecimento partilhado ajudava a reconhecer comportamentos suspeitos com maior rapidez.

Enquanto um checkout isolado dependia sobretudo dos seus próprios registos, uma plataforma com múltiplos comerciantes conseguia analisar padrões de forma mais abrangente.

Porque é que a prevenção precisava de evoluir continuamente?

Os atacantes podiam alterar os seus métodos, as suas infraestruturas e os seus padrões de comportamento.

Por isso, uma defesa eficaz não podia depender exclusivamente de regras estáticas.

André explicou que a capacidade de observar ataques diferentes em operações distintas contribuía para melhorar os mecanismos de deteção.

A inteligência coletiva permitia transformar o conhecimento obtido num ataque em proteção adicional para outras operações.

Como a Digital Manager Guru protegia as operações dos clientes

[36:23] Ao detalhar a infraestrutura da Digital Manager Guru, André Cruz explicou que os mecanismos de análise de risco e prevenção de fraude faziam parte da solução disponibilizada aos clientes.

De acordo com o CEO, não era necessário contratar separadamente uma funcionalidade específica de antifraude para beneficiar dessa proteção.

A plataforma assumia os custos associados à sua infraestrutura de monitorização e avaliação de risco.

Proteção sem cobrança pelas tentativas bloqueadas

[36:52] André apresentou também uma decisão relacionada com a cobrança de créditos de transação.

Depois de acompanhar um cliente que tinha sofrido mais de 2.300 tentativas de compra em poucas horas, reconsiderou a possibilidade de cobrar pelas operações bloqueadas pelo sistema antifraude.

A solução adotada passou por não imputar esses créditos aos clientes quando as tentativas eram barradas pelo mecanismo de prevenção de fraude da Guru.

Segundo André, o objetivo era evitar que um comerciante fosse financeiramente penalizado pelo elevado número de tentativas maliciosas dirigidas ao seu checkout.

A resposta coletiva aos novos padrões de ataque

[39:14] André explicou que, após a identificação de novas tentativas de fraude, a equipa analisava os sinais observados e desenvolvia mecanismos de resposta que podiam ser disponibilizados transversalmente aos clientes.

Descreveu situações em que ataques identificados durante a madrugada de domingo para segunda-feira deram origem a atualizações de defesa logo na segunda-feira ou na terça-feira.

Este modelo permitia distribuir os benefícios do conhecimento adquirido por toda a infraestrutura.

A importância da continuidade das vendas

[40:09] Outro aspeto destacado foi a possibilidade de manter a operação comercial ativa enquanto as tentativas fraudulentas eram bloqueadas.

Um checkout isolado, perante um ataque persistente, podia obrigar a equipa técnica a interromper vendas e concentrar recursos na resolução do problema.

Segundo André, o cliente que tinha recebido mais de 2.300 tentativas não precisou de desativar a oferta por incapacidade da proteção da Guru: a plataforma continuava a bloquear a atividade suspeita.

Para negócios que dependiam de vendas contínuas, este tipo de capacidade representava uma vantagem operacional importante.

A proteção antifraude deixava, assim, de ser apenas um mecanismo de segurança e passava a integrar a própria estratégia de continuidade de negócio.

O que os negócios digitais deviam considerar na escolha do checkout

[41:35] A reflexão apresentada por André Cruz demonstrou que o custo mensal de uma plataforma não devia ser o único critério de decisão.

Um checkout desenvolvido internamente podia parecer economicamente vantajoso numa fase inicial.

Contudo, era necessário considerar os custos de manutenção, monitorização, resposta a incidentes e eventuais interrupções da atividade comercial.

Critérios essenciais para avaliar uma solução de pagamentos

Para fundadores de SaaS, produtores digitais e gestores de operações online, os pontos abordados no episódio permitiam identificar sete áreas de avaliação.

1. Prevenção de fraude em tempo real

A solução precisava de reconhecer comportamentos suspeitos e atuar antes de os pagamentos chegarem às processadoras, sempre que possível.

2. Capacidade de resposta a ataques automatizados

Era importante avaliar a existência de proteção contra card testing, padrões repetitivos de submissão e outras tentativas de exploração do checkout.

3. Segurança dos dados financeiros

A arquitetura devia minimizar a exposição de dados sensíveis e recorrer a mecanismos adequados de tokenização e processamento seguro.

4. Proteção da experiência de compra

Os controlos antifraude precisavam de equilibrar segurança e conversão, evitando bloquear desnecessariamente clientes legítimos.

5. Monitorização e atualização contínuas

Uma infraestrutura de pagamentos exigia acompanhamento permanente e capacidade de adaptação a novos padrões de fraude.

6. Segurança dos pagamentos recorrentes

Os negócios de subscrição deviam ter especial atenção à identificação de cobranças fraudulentas que pudessem originar múltiplos chargebacks.

7. Continuidade operacional

O fornecedor devia apresentar mecanismos que ajudassem a manter as vendas ativas, mesmo perante tentativas persistentes de ataque.

O verdadeiro custo de um checkout vulnerável

[42:03] André destacou que uma poupança aparentemente pequena na infraestrutura podia transformar-se num custo muito superior quando surgia um incidente.

Esse custo não incluía apenas os pagamentos fraudulentos.

Podia envolver vendas perdidas, recursos técnicos desviados das prioridades do negócio, dificuldades com processadoras e interrupções na faturação.

Para empresas SaaS, em particular, a indisponibilidade de um sistema de pagamentos também podia afetar a aquisição de clientes e a renovação de subscrições.

Por isso, a escolha de uma plataforma de pagamentos precisava de considerar o risco operacional e não apenas as funcionalidades ou o preço.

Conclusão: proteger os pagamentos era proteger o negócio

[42:32] No encerramento do episódio, André Cruz reforçou uma ideia fundamental: empreender no mercado digital exigia mais do que campanhas de aquisição, estratégias de conversão e ofertas comerciais competitivas.

A sustentabilidade de um negócio também dependia da capacidade de proteger a sua infraestrutura financeira.

A inteligência artificial tinha facilitado o desenvolvimento tecnológico, mas também tinha reduzido determinadas barreiras à automatização de ataques.

Neste contexto, a segurança de pagamentos online deixou de poder ser encarada como uma preocupação exclusivamente técnica.

Tornou-se uma responsabilidade estratégica para fundadores, gestores e decisores que dependiam de transações digitais.

Os casos apresentados demonstraram que os ataques de card testing podiam afetar empresas de diferentes dimensões, comprometer indicadores de pagamentos e originar prejuízos que ultrapassavam o valor das transações fraudulentas.

A principal aprendizagem foi que um negócio digital precisava de garantir não apenas que conseguia vender, mas também que conseguia continuar a vender com segurança.

Ao combinar mecanismos de prevenção, monitorização contínua e inteligência coletiva, a infraestrutura de pagamentos podia tornar-se um elemento de proteção da receita, da reputação e da continuidade operacional.

Para empresas que pretendiam crescer de forma sustentável, essa capacidade não representava apenas uma vantagem tecnológica. Representava uma componente essencial da gestão do risco.