Checklist de go-live
1
Fluxo completo validado no sandbox
Criar cobrança → receber webhook
transaction.paid → liberar o pedido. Teste também os caminhos tristes: expiração (transaction.expired) e cancelamento. No sandbox dá pra simular todos.2
Assinatura de webhook verificada
Sua aplicação rejeita webhooks com assinatura inválida? Teste mandando um POST forjado no seu endpoint. Use o SDK ou os exemplos de verificação — sempre com o corpo bruto. Canais novos usam o formato v2 (anti-replay).
3
Consumo de webhook idempotente
Entregas podem se repetir (retry da plataforma). Processar o mesmo
transaction.paid duas vezes não pode liberar o pedido duas vezes — deduplique por transactionId.4
Criação com Idempotency-Key
Timeout na criação não pode virar pagamento duplicado. Envie
Idempotency-Key (o SDK já faz sozinho) e repita com a mesma chave após falhas de rede.5
HTTP 202 tratado
Em degradação rara, a criação responde
202 com id: null — o PIX é válido, entregue ao comprador e use externalId como referência. Veja Erros.6
Erros tratados pelo código, não pela mensagem
Trate por
status + type e repita erros transitórios com backoff. A página de erros diz o que fazer com cada um.7
Troque a chave
Substitua
sk_test_* por sk_live_* nas variáveis de ambiente. Só isso — mesma API, mesmos endpoints.Transações de sandbox e produção são totalmente isoladas — nada do que você criou com
sk_test_ aparece nos números reais do projeto.Próximos passos
Configurar webhooks
Confirme cada pagamento pelo evento, não pela resposta da criação.
Idempotência
Repita requisições de criação sem risco de cobrar duas vezes.