ch_live_...cria e consulta dados de produção (livemode: true).ch_test_...cria e consulta dados de teste (livemode: false).
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: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 ambientetest. O token gerado começa com ch_test_ e já
funciona com a conta recém-criada.
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 arequires_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 emcustomer_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.
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 quandolivemode é
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 checkoutunpaid.
Webhooks em test mode
Eventos criados comch_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
O cadastro de organizações filhas roda ponta a ponta comch_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 objetopayout_accountvolta 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 comch_test_...retornam409comcode: "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 chavech_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.
