Cartões de teste
Números de cartão, nomes de titular, validade, código de segurança e dados fictícios de comprador para testar aprovação, desafio 3DS, recusa e pré-autorização no sandbox.
Escolha o número e o nome do titular conforme o resultado que você quer testar. Nos cartões com desafio, o mesmo número aprova com AUTHORISED e recusa com REFUSED. O nome do comprador é outro campo e não substitui o nome do titular.
Somente sandbox
Use estes dados com uma chave de API de sandbox (kpa_test_sk_...). Não use cartões reais para homologar a integração nem envie estes números para produção.
Validade e código de segurança
Os cartões desta página usam os mesmos dados:
| Dado | Valor |
|---|---|
| Validade no formulário | 12/30 |
| Mês na API | expMonth: 12 |
| Ano na API | expYear: 2030 |
| Código de segurança | 123 |
Na cobrança com dados de cartão, o código chama-se cvc. Na tokenização, chama-se cvv. Com o SDK de campos, digite os dados nos campos seguros e use o token retornado pelo SDK.
Aprovação e desafio 3DS
| Número do cartão | Bandeira | Nome no cartão (holderName) | Resultado esperado |
|---|---|---|---|
5555555555554444 | Mastercard | MARIA SOUZA | Aprovação sem desafio, conforme a configuração da conta. |
5200000000001096 | Mastercard | AUTHORISED | Desafio 3DS; aprovação após concluir a autenticação. |
4000000000001091 | Visa | AUTHORISED | Desafio 3DS; aprovação após concluir a autenticação. |
5200000000001096 | Mastercard | REFUSED | A autenticação pode concluir, mas a autorização da cobrança é recusada. |
Para exercitar o desafio, use paymentMethodOptions.creditCard.threeDSecure: "required" e uma sessão 3DS válida, com a coleta do dispositivo concluída. Só trocar o número não garante que a cobrança entre no fluxo 3DS.
Quando a criação retornar RequiresAction, abra a URL de nextAction.url em um iframe, como no guia Exiba o desafio 3DS. O código de uso único de teste aparece na própria tela do desafio; no cenário do laboratório, aparece como OTP: 1234. Use o código mostrado na tela.
Autenticação e pagamento têm resultados distintos
Uma aprovação sem desafio não comprova que houve autenticação 3DS. Da mesma forma, concluir o desafio não garante aprovação financeira: o cenário com REFUSED testa essa diferença. Confirme o resultado pelo status do PaymentIntent.
Pré-autorização e captura
Use o Mastercard 5555555555554444, titular MARIA SOUZA, validade 12/30 e código 123. Na cobrança, envie captureMethod: "Manual", crédito e uma parcela, sem sessão 3DS nem a opção de autenticação obrigatória, em uma conta habilitada para pré-autorização.
O resultado esperado da autorização é RequiresCapture, com valor disponível para captura e valor capturado zero. Depois da captura integral, o PaymentIntent passa a Succeeded. Para liberar a reserva sem cobrar, siga o cancelamento descrito em Pré-autorize e capture depois.
Use um valor baixo dentro dos limites da sua conta. Na API, amount: 100 representa R$ 1,00; amount: 1000, R$ 10,00. Os dados do cartão não habilitam pré-autorização ou alteram limites de valor e parcelas.
Comprador fictício
Você pode usar estes dados para preencher o comprador no sandbox:
{
"name": "Maria Souza",
"email": "maria.souza@example.com",
"document": "52998224725"
}O bloco acima corresponde a customer. Para selecionar aprovação ou recusa nos cartões com desafio, altere paymentMethods[].card.holderName, mantendo customer.name separado. Nos campos seguros do SDK, preencha o nome no campo de titular do cartão.
Se precisar de um endereço fictício de cobrança, use:
| Campo | Valor de teste |
|---|---|
country | BR |
zipCode | 01310100 |
street | Rua Teste 100 |
neighborhood | Centro |
city | Sao Paulo |
state | SP |
Esses dados servem ao formulário de cartão. Identidades específicas de outros meios de pagamento ficam em Dados de teste.
Número inválido para testar validação
Use 4444333322220001, titular MARIA SOUZA, validade 12/30 e código 123, quando quiser verificar a rejeição de um número que não passa no dígito verificador do cartão (Luhn). Ele não serve para testar aprovação, captura ou desafio 3DS.
O SDK ou a validação do seu formulário pode bloquear esse número antes de enviar uma cobrança. Isso é diferente de uma recusa financeira depois da autorização.
Se o resultado for diferente
| Sintoma | O que conferir |
|---|---|
| O cartão de desafio não abre o iframe | Verifique threeDSecure: "required", a sessão 3DS, a coleta concluída e o status retornado. |
O cenário REFUSED autentica e depois recusa | É o resultado esperado: autenticação e autorização são etapas distintas. |
| O formulário rejeita a validade | Digite 12/30; na API, envie mês 12 e ano 2030 em campos separados. |
| O cartão é válido, mas a cobrança falha | Consulte lastPaymentError; habilitação da conta, bandeira, moeda, endereço e limites também são avaliados. |
| A resposta ficou incerta após o envio | Consulte o mesmo PaymentIntent antes de tentar outra cobrança. Para repetir a mesma tentativa, preserve a chave de idempotência. |