> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chargefy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Checklist de go-live

> Valide conta, credenciais, pagamentos, webhooks, retries e operação antes de começar a cobrar em produção.

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.

<Note>
  Enquanto o cadastro é analisado, você pode preparar catálogo, credenciais,
  código e o receiver de webhooks. No fluxo atual, criar ou confirmar recursos
  de pagamento também no sandbox exige uma organização `active`.
</Note>

## 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](/payments/fulfill-orders).

## 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](/test-payments-in-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](/api-reference/idempotency) e [Erros](/api-reference/errors) 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

<Check>
  Faça uma cobrança real de baixo valor somente depois que todos os itens
  aplicáveis estiverem concluídos. Confirme a resposta, o webhook, a entrega
  idempotente e a transaction antes de abrir tráfego de produção.
</Check>

<CardGroup cols={2}>
  <Card title="Autenticação e segurança" icon="shield-check" href="/api-reference/authentication">
    Revise credenciais, browser, webhooks e logs.
  </Card>

  <Card title="Conciliação" icon="scale-balanced" href="/payments/reconcile-payments">
    Feche cobrança, taxas e liquidação de ponta a ponta.
  </Card>
</CardGroup>