Cartão cadastrado com sucesso, mas toda cobrança falha: investigação completa de uma compra de créditos da Claude API (causa raiz: 3DS)

Este é o primeiro artigo da série “Casos reais”. Cada caso vem de um chamado real de usuário: reconstruímos os sintomas, o caminho da investigação, a causa raiz e a solução, com todas as informações identificáveis anonimizadas. Este artigo trata do tipo mais confuso de falha de pagamento — o cartão é cadastrado sem problema, mas nenhuma cobrança passa, e nenhum dos dois lados mostra um erro útil.

1. O caso

O usuário emitiu um cartão virtual para recarregar os créditos da conta no Anthropic Console (Claude API). O processo foi assim:

• Adicionou o cartão no Anthropic Console — o cadastro foi concluído com sucesso, e a plataforma mostrou o cartão como salvo
• Iniciou a compra de créditos da API — o pagamento falhou, e falhava do mesmo jeito a cada nova tentativa
• O erro do lado da plataforma era vago: dizia apenas que o pagamento não foi concluído, sem informar o motivo concreto
• O usuário abriu um chamado: “O cartão cadastra, mas a cobrança não passa”

Do ponto de vista do usuário, isso parece não ter solução: o cartão está bom (o cadastro passou), o dinheiro é suficiente e a plataforma não diz o motivo. Trocar de cartão? Emitir outro provavelmente dá no mesmo — porque o problema não está “neste cartão específico”.

2. A pista principal: nenhum registro de falha do lado do cartão

Depois de receber o chamado, primeiro consultamos a lista de transações do cartão. Normalmente, uma “cobrança que falhou” deixa do lado do cartão uma autorização recusada, com o motivo da recusa (saldo insuficiente, controle de risco, categoria de lojista restrita…) — e você resolve conforme o motivo indicado. Mas a lista de transações deste cartão estava assim:

Essa é a impressão digital de diagnóstico mais valiosa deste caso: uma cobrança recusada comum sempre deixa um registro de falha do lado do cartão; zero registros significa que o pagamento foi interrompido antes de chegar ao emissor. Entre o cartão e o lojista existe uma barreira que não conseguimos ver do lado do cartão.

3. Todo o processo de investigação

1. Verificar o status do cartão: status “Ativo”, saldo suficiente, sem bloqueio — o problema não está no cartão em si.
2. Consultar todos os registros de autorização: como acima, só existe o registro bem-sucedido da verificação de US$0 do cadastro, nenhuma autorização recusada — fica descartada a hipótese de “recusa pelo controle de risco”; o problema está antes da etapa de autorização.
3. Identificar o processador de pagamentos: a página de compra de créditos da API no Anthropic Console é processada pela Stripe (dá para ver na própria página de pagamento). Em algumas transações, a Stripe exige verificação 3DS (3-D Secure, a verificação adicional dos pagamentos online com cartão) — principalmente quando o modelo de risco dela considera necessária uma confirmação extra.
4. Verificar a compatibilidade da faixa de BIN com 3DS: consultamos o emissor sobre a configuração de 3DS deste cartão — a resposta foi: esta faixa de BIN não suporta 3DS. Nesse ponto, toda a cadeia se encaixou.

4. Causa raiz: a verificação no cadastro e a cobrança real não passam pela mesma barreira de segurança

A cadeia completa da falha:

• No momento de cadastrar o cartão: a plataforma faz apenas uma autorização de verificação de US$0 (ou de valor muito baixo), e essa verificação normalmente não aciona o 3DS → passa sem problemas, cartão salvo com sucesso
• No momento da cobrança real: o controle de risco da Stripe exige que esta transação conclua a verificação 3DS → a faixa de BIN não suporta 3DS → a etapa de verificação não pode ser concluída → o pagamento falha antes mesmo de a autorização ser iniciada
• Como a falha acontece na etapa do desafio 3DS, o emissor nunca vê a transação (por isso, zero registros do lado do cartão), e o lojista só consegue mostrar um genérico “pagamento não concluído”

Em uma frase: cartão cadastrado com sucesso ≠ cobrança aprovada. A verificação no cadastro só prova que o cartão é real e está ativo; a cobrança real ainda precisa passar pela barreira extra do controle de risco + 3DS, e se essa barreira aparece — e se dá para passar por ela — depende da política do processador de pagamentos do lojista e da capacidade da faixa de BIN, e não do sucesso do cadastro.

5. Em quais casos você cai na mesma armadilha

Qualquer combinação de um lojista que exige (ou tem alta probabilidade de acionar) 3DS e uma faixa de BIN sem suporte a 3DS reproduz exatamente esses sintomas. Pela nossa experiência, os casos de uso que mais acionam o 3DS são:

• Lojistas que recebem via Stripe e têm pontuação de risco mais rígida (a compra de créditos da API no Anthropic Console deste caso é um exemplo)
• Transações de valor alto ou a primeira transação (o controle de risco tende a exigir uma segunda verificação)
• Lojistas da Europa (sob a regulação SCA de autenticação forte, o 3DS quase sempre está ativado)

Por outro lado, o mesmo cartão funciona perfeitamente em lojistas que não exigem 3DS (a maioria das cobranças de assinatura) — é por isso que o usuário tem a sensação de que o cartão “funciona às vezes sim, às vezes não”; na verdade, o que muda é a política do lojista.

6. Mesmos sintomas? Uma autoverificação em três passos

1. Veja se há registros de falha do lado do cartão: entre no painel e abra a aba “Transações” desse cartão. Se houver registros de recusa → resolva conforme o motivo informado (veja Cartão virtual recusado? Os 10 motivos mais comuns e como resolver (dados reais de 2026)); zero registros → muito provavelmente foi barrado pelo 3DS ou por um controle de risco anterior à autorização, e siga para o próximo passo.
2. Confirme se a verificação no cadastro já passou alguma vez: se a verificação de US$0 passou no cadastro, mas as cobranças reais nunca aparecem na lista de transações, é o mesmo quadro deste caso — dá para praticamente cravar uma falha do tipo 3DS antes da autorização.
3. Veja o processador de pagamentos do lojista: se a página de pagamento mostra Stripe e o caso é mais rígido (recargas, valores altos, primeira cobrança), a chance de o 3DS ser acionado é alta. Nesse caso, trocar de cartão não resolve — o que você precisa é de uma faixa de BIN compatível com 3DS.

7. Conclusões

• “O cartão cadastra” só prova que ele é real — não que a cobrança vai passar. Para avaliar se um cartão serve para uma plataforma, veja se a cobrança real é aprovada, e não se o cadastro deu certo
• Zero registros de falha do lado do cartão é a impressão digital que separa “recusada” de “falha de 3DS antes da autorização” — comece a autoverificação por aí
• A maioria das nossas faixas de BIN à venda não é compatível com 3DS e, por isso, não serve para casos que exigem 3DS (como a compra de créditos da API no Anthropic Console deste caso). No momento, apenas algumas faixas de BIN são compatíveis com 3DS (marcadas como “Aceita verificação 3DS” na página “Emitir um novo cartão”), e se uma delas serve para determinada plataforma depende dos casos de uso indicados para aquela faixa; novas faixas são anunciadas no histórico de atualizações — preferimos deixar a limitação clara desde já a fazer você tentar e errar várias vezes
• Se a falha de pagamento não tiver explicação clara, abra um chamado informando o nome da plataforma e o horário aproximado — pelos registros do lado do cartão, conseguimos localizar rapidamente em que etapa a cadeia quebrou

Para uma triagem geral de falhas de pagamento, veja o “Guia de solução de problemas de pagamento”; para um caso típico de recusa em cobrança de assinatura, veja Pagamento do ChatGPT Plus recusado: verifique primeiro a faixa de BIN, depois a conta.

8. Perguntas frequentes

O cadastro do cartão deu certo, então o cartão está bom — por que as cobranças ainda falham?

A verificação no cadastro (autorização de US$0) e a cobrança real passam por cadeias de validação diferentes. Na cobrança real, o controle de risco do lojista pode exigir a verificação 3DS, o que normalmente não acontece na verificação do cadastro. Quando a faixa de BIN não suporta 3DS, o resultado é “o cartão cadastra, mas toda cobrança falha”.

Como saber se a falha foi causada pelo 3DS?

A impressão digital mais confiável é a lista de transações do lado do cartão: uma recusa comum deixa um registro de autorização recusada; uma falha de 3DS antes da autorização não deixa registro nenhum, porque a transação nunca chegou ao emissor.

Trocar para outro cartão resolve?

Não importa quantos cartões você emita na mesma faixa de BIN: o resultado é o mesmo — o suporte a 3DS é uma capacidade da faixa de BIN, não de cada cartão. Só há duas saídas: trocar para uma faixa de BIN que suporte 3DS ou usar, nesse lojista, uma forma de pagamento que não exija 3DS.

O dinheiro da recarga do cartão é perdido por causa disso?

Não. A falha de 3DS antes da autorização acontece antes de qualquer cobrança, então nenhum valor é debitado; o saldo do cartão permanece intacto, o valor recarregado continua creditado no cartão e pode ser usado em outras plataformas que não exigem 3DS.

Baseado em um chamado real de julho de 2026, com informações identificáveis anonimizadas. Autoria: Equipe de Pesquisa de Pagamentos da RDVCC · Revisão do original: Steven Cai

Tradução assistida por IA; o texto original foi revisado por Steven Cai.