Checklist de go-live

Ir para produção não é apenas trocar ch_test_ por ch_live_. Test mode e live mode são ambientes isolados: credenciais, recursos e endpoints precisam estar no ambiente correto, e sua operação precisa saber reconhecer sucesso, falha e pagamento pendente. Use este checklist como gate antes da primeira cobrança real.

​

1. Conta e liquidação

• A organização está com activation_status: "active".
• A conta para saques de liquidação está cadastrada como principal.
• A rotina de conciliação confere os repasses no extrato bancário; o status da conta não garante o crédito.
• Em uma plataforma, cada organização conectada concluiu a própria ativação.
• Sua equipe entende que a liquidação é automática e aparece nas transactions; não existe saque manual.

​

2. Recursos e credenciais de produção

• Uma chave ch_live_... foi criada com apenas os escopos necessários.
• A chave vive em secret manager ou variável protegida, nunca no frontend ou repositório.
• Produtos, preços, descontos, links e endpoints necessários foram recriados em live mode.
• IDs de test mode não estão em configurações de produção.
• Sua aplicação confere livemode: true nos recursos e eventos reais.
• Há um procedimento documentado de rotação e revogação de chave.

​

3. Experiência de pagamento

• O checkout mostra produto, valor, moeda, parcelamento e próxima ação com clareza.
• A página de sucesso não libera produto por conta própria; ela apenas informa o comprador.
• Pix e boleto têm uma tela de estado pendente e um caminho para consultar ou retomar o pagamento.
• Falhas de cartão exibem uma ação útil sem revelar detalhes internos.
• O fluxo é responsivo, acessível e funciona nos browsers que sua audiência usa.
• Se o checkout é customizado, Chargefy.js é carregado somente da URL oficial e a CSP permite script-src e connect-src para https://api.chargefy.io.

​

4. Webhooks e fulfillment

• Existe um endpoint HTTPS criado em live mode com os tipos de evento necessários.
• O secret de live mode está configurado separadamente do secret de teste.
• A assinatura é validada sobre o corpo bruto antes de qualquer processamento.
• O ID evt_... é persistido com unicidade para impedir processamento duplicado.
• O endpoint persiste ou enfileira o evento e responde 2xx rapidamente.
• A lógica não depende da ordem de eventos diferentes.
• A entrega do produto ou acesso usa estado financeiro confirmado, não redirect do frontend.
• Em plataformas, o campo top-level organization é usado para rotear o evento ao seller correto.

Veja o desenho recomendado em Entregar pedidos com segurança.

​

5. Cenários testados

• Cartão aprovado.
• Cartão recusado e nova tentativa com outro método.
• Autorização com captura manual, se usada.
• PIX criado como pendente e liquidado depois pelo e-mail de teste ou pelo controle do checkout sandbox.
• Boleto criado como pendente e depois liquidado, falhado ou expirado.
• Webhook duplicado.
• Webhook entregue fora da ordem esperada.
• Endpoint de webhook temporariamente indisponível e reentrega posterior.
• Timeout ou resposta perdida ao criar uma cobrança, repetindo a mesma Idempotency-Key.
• Reembolso total e parcial, quando aplicável ao seu produto.
• Renovação, falha de invoice e cancelamento, se há assinaturas.

Use Testar pagamentos no sandbox para cartões e cenários de PIX/boleto por e-mail. A ativação de organizações conectadas e as contas para saques não são simuladas no sandbox; valide esses fluxos reais de forma controlada antes de escalar a operação.

​

6. Retry e idempotência

• Toda mutação sensível recebe uma Idempotency-Key estável por operação lógica.
• Retries de 429 e 5xx usam backoff e reutilizam a mesma chave e o mesmo body.
• A aplicação não repete automaticamente erros de validação, autenticação ou recusa de cartão.
• Existe timeout de cliente e os jobs de retry têm limite e observabilidade.

Consulte Idempotência e Erros para o comportamento exato.

​

7. Operação e suporte

• Alertas cobrem falhas persistentes de webhook, aumento de 5xx e filas de processamento da sua aplicação paradas.
• O time sabe consultar Request Logs pelo ID da requisição e pelos objetos relacionados.
• Há uma rotina de conciliação entre payment intent, charge e transaction.
• Suporte consegue localizar uma venda pelo ID do pedido salvo em metadata.
• Existe um processo para reembolso, disputa, credencial comprometida e indisponibilidade.
• Métricas separam test mode de live mode e organizações conectadas entre si.

​

Gate final