Skip to main content
O sandbox é a produção com dinheiro de mentira: os mesmos endpoints, os mesmos objetos, os mesmos webhooks. O que separa os dois mundos é só a API key usada na chamada:
  • ch_live_... cria e consulta dados de produção (livemode: true).
  • ch_test_... cria e consulta dados de teste (livemode: false).
Dados de teste não movimentam dinheiro e ficam isolados dos dados de produção. Use chaves separadas para desenvolvimento, staging e produção.

Disponível desde o primeiro minuto

O sandbox funciona de ponta a ponta antes mesmo da ativação da conta. Enquanto o cadastro está em análise, você já cria produtos, payment links, checkout sessions e payment intents de teste, paga com os cartões e e-mails determinísticos desta página e recebe os webhooks correspondentes — a integração inteira pode ficar pronta em paralelo à aprovação. A ativação só é exigida para receber pagamento real. Antes dela, o ambiente live aceita criar recursos normalmente (clientes, links, sessões), e o comprador consegue navegar o checkout até o fim — mas a confirmação do pagamento é recusada com um erro estável, sem cobrar nada:
Trate esse code como “conta ainda em ativação”: ele aparece no confirm da checkout session e no confirm do payment intent, sempre com status 422, e desaparece quando a ativação é aprovada.

Criar uma chave de teste

No dashboard, abra Developers → Chaves de API, clique em Nova chave e selecione o ambiente test. O token gerado começa com ch_test_ e já funciona com a conta recém-criada.
No dashboard, o menu Minha conta alterna entre os ambientes live e sandbox a qualquer momento. Contas que ainda não ativaram começam no sandbox por padrão — mas a troca é sempre livre.

Simular cartões

Em checkouts hospedados, no Chargefy.js, na página de pagamento de fatura e nos formulários de atualização de cartão, use estes números em test mode. Use qualquer CVC de três dígitos e uma validade futura. Cartão desconhecido em test mode aprova por padrão.

Sucesso e status

Na charge aprovada, payment_error é null. Nos casos processing e pending, ainda não há desfecho — não trate a ausência de erro como aprovação; aguarde o webhook.

Cartões salvos e reutilização

Os cartões abaixo aprovam a primeira cobrança e podem ser salvos normalmente. O resultado especial aparece somente quando o mesmo cartão é cobrado de novo como cartão salvo — por exemplo, em uma oferta posterior de um funil. Use esses números para validar uma compra aprovada seguida de contingência ou processamento assíncrono no reúso. Em live mode, eles são tratados como números comuns e não escolhem o resultado do pagamento.

Falhas simuladas via cartão

Uma recusa encerra a tentativa, não o intent: o Payment Intent volta a requires_payment_method com o motivo em last_payment_error, e o mesmo intent aceita uma nova confirmação — use estes cartões para testar o fluxo de recusa seguida de retentativa. O sandbox também oferece cartões para erros que, em produção, podem nascer em outras etapas — como captura, tokenização ou reembolso. Nesses casos, o cartão serve para testar o contrato público, a mensagem e a saída segura da interface; ele não pretende reproduzir a etapa operacional que originou o erro real. O código Chargefy estável fica em payment_error.code, com a orientação em payment_error.advice_code; payment_error.network_decline_code só aparece quando o cenário de teste fornece evidência bruta confiável de rede.

Simular PIX e boleto

Em test mode, o e-mail do cliente determina o resultado de PIX e boleto. Use o mesmo valor em customer_email no Checkout ou no customer associado ao payment_intent. O local-part precisa ser exatamente um dos valores acima; o domínio pode ser qualquer domínio válido. Em live mode esses endereços são tratados como e-mails comuns e não alteram o pagamento.
Boleto continua exigindo CPF/CNPJ e endereço válidos. Use esses campos para testar validação cadastral; use o e-mail para escolher o resultado financeiro.
Nos cenários delayed, a confirmação retorna o código PIX ou o boleto com o payment_intent em pending. A transição posterior passa pelo mesmo processamento financeiro e emite os mesmos webhooks de um pagamento real.

Controles no checkout hospedado

O checkout hospedado exibe uma barra amarela no topo quando livemode é false. Depois que um PIX ou boleto entra em pending, a própria barra mostra dois controles:
  • Simular pagamento entrega o evento de sucesso e leva o checkout a payment_status: "paid".
  • Simular expiração entrega o evento de expiração do código — o intent volta a requires_payment_method — e mantém o checkout unpaid.
Esses controles são uma conveniência visual para testes manuais. Para testes automatizados e integrações via API, use os e-mails determinísticos da tabela acima. Os dois caminhos usam o mesmo processamento e produzem os mesmos webhooks.

Webhooks em test mode

Eventos criados com ch_test_... carregam livemode: false e são entregues apenas para endpoints de webhook criados no ambiente de teste — endpoints e secrets são separados por ambiente. Crie pelo menos um endpoint em test antes de validar a integração: os pagamentos simulados desta página emitem exatamente os mesmos eventos dos pagamentos reais.

Ativação de organizações no sandbox

Este recurso só está disponível para Chargefy for Platforms.
O cadastro de organizações filhas roda ponta a ponta com ch_test_..., com desfecho determinístico escolhido pelo CPF/CNPJ da organização: aprovado, reprovado com correção, reprovado sem autoatendimento ou em análise. A tabela está em Ativação por API e vale para os dois caminhos de cadastro, o hospedado e o por API.

Contas para saques no sandbox

Há dois caminhos, com comportamentos diferentes:
  • Dentro da ativação (hospedada ou por API): a conta para saques é exigida e simulada normalmente com ch_test_.... O objeto payout_account volta preenchido na organização — ele prova o contrato e o fluxo, mas nenhuma conta bancária real é validada e nenhum repasse acontece.
  • Recurso independente (/v1/payout-accounts): criar, listar e desconectar contas fora da ativação ainda não é simulado. Requisições com ch_test_... retornam 409 com code: "sandbox_unsupported"; use esse recurso apenas em produção.

Ir para produção

Sandbox e produção usam o mesmo código — só a chave muda. Dados de teste não migram: recrie produto, preço e link com a chave ch_live_... quando a conta estiver ativa. O passo a passo completo, incluindo webhooks e checklist final, está em Testar no sandbox e no Checklist de go-live.