Gatilhos

No ambiente de teste, quem decide o desfecho da cobrança são os dois últimos dígitos de amount. Você escolhe o cenário escolhendo o valor.

Isso vale apenas com chave sk_test_. Em produção o valor é só o valor.

A tabela

`amount` termina em	O que acontece
qualquer outro	Paga sozinha poucos segundos depois da criação.
`01`	Nunca paga. Expira em `pix.expires_at`.
`02`	A criação falha por tempo esgotado no processador: `503 acquirer_timeout`.
`03`	A criação é recusada pelo processador: `503 acquirer_rejected`.
`04`	Paga e entrega o mesmo evento duas vezes.
`06`	Paga e recebe uma contestação cerca de 10 segundos depois.
`07`	Paga sem entregar webhook.
`08`	Entrega `transaction.expired` e depois `transaction.paid`, fora de ordem.

Exemplos: R$ 100,00 são 10000, termina em 00, e paga sozinha. R$ 100,01 são 10001, termina em 01, e expira. R$ 55,04 são 5504, termina em 04, e entrega o evento duas vezes.

Esses gatilhos são contrato público: mudar o efeito de um deles entra no changelog.

O que cada um testa

Caminho feliz (qualquer outro). O seu checkout inteiro, do QR ao transaction.paid.

01, expiração. O contador da tela, o transaction.expired e, principalmente, o seu sistema não apagar o pedido ao receber esse evento. Pagamento tardio existe (Expiração).

02 e 03, falha na criação. Os dois voltam 503 e a cobrança fica sem QR. Teste que a sua tela de checkout mostra erro em vez de ficar em branco, e que a sua retentativa usa uma Idempotency-Key nova. Repetir com a mesma chave devolve o mesmo 503 (Idempotência).

04, evento duplicado. O mesmo evento, com o mesmo identificador, chega duas vezes. Se o seu receptor não deduplicar, você entrega o produto duas vezes ou credita o cliente em dobro. É o teste mais importante desta lista.

06, contestação. A cobrança paga volta contestada e o valor sai do seu saldo. Teste o que o seu sistema faz com transaction.chargeback numa venda já entregue.

07, pago sem webhook. Simula a entrega que nunca chegou, seja por queda do seu servidor, seja por falha de rede. A cobrança está paid e o seu banco de dados não sabe. É o cenário que prova que você precisa de uma rotina de reconciliação por consulta, e não só do webhook.

08, fora de ordem. transaction.expired chega antes de transaction.paid. Um receptor que aplica eventos cegamente na ordem de chegada marca a venda como perdida e nunca mais a recupera.

Como usar isso de verdade

Rode os oito no seu ambiente de testes automatizados, não à mão. São oito valores e oito asserções sobre o estado final do seu banco, e eles cobrem quase todo o suporte que você teria depois.

Os gatilhos não mudam nada além do desfecho: validação, erros, limites e assinatura de webhook continuam iguais aos de produção.

Próximo passo

Saques, para fechar o ciclo do dinheiro.

Referência: Cria uma cobrança PIX e Consulta uma cobrança.