Ambiente de testes
Cartões de teste e os valores que decidem o desfecho de Pix e boleto no sandbox.
Uma chave sk_test_ cobra contra a adquirente mock: nenhum cartão é debitado, nenhum Pix existe de verdade, e o desfecho de cada cobrança é escolhido por você — pelo número do cartão ou pelo valor da cobrança.
Fora isso, o fluxo é idêntico ao de produção: mesma tokenização, mesmos status, mesmos webhooks, mesmo recebível. É de propósito — o que você integra no sandbox é o que roda em LIVE.
Cartões de teste
A mock aprova qualquer cartão válido. Para exercitar os caminhos de erro, tokenize um destes números normalmente e cobre o tok_ resultante:
| Número | Desfecho da cobrança |
|---|---|
4111 1111 1111 1111 | aprovada (paid ou authorized, conforme o capture_method) |
4000 0000 0000 0002 | recusada pelo emissor — refused, motivo card_refused |
4000 0000 0000 0119 | falha técnica da adquirente — failed |
Use qualquer validade futura e qualquer CVV de 3 dígitos (4 para Amex). O nome do portador não influencia o desfecho.
Repare que a tokenização sempre funciona, inclusive nos dois cartões de erro: o desfecho aparece só na cobrança, como em produção. É o que permite testar o seu tratamento de recusa sem pular nenhum passo.
curl -X POST https://bunne.com.br/api/v1/payment-methods/tokenize \ -H "Authorization: Bearer sk_test_xxx" \ -H "Content-Type: application/json" \ -d '{ "card": { "number": "4000000000000002", "exp_month": 12, "exp_year": 2030, "cvv": "123", "holder_name": "Ada Lovelace" } }'# a tokenização SUCEDE e devolve um tok_ real; a recusa acontece na cobrançacurl -X POST https://bunne.com.br/api/v1/charges \ -H "Authorization: Bearer sk_test_xxx" \ -H "Idempotency-Key: teste_recusa_1" \ -H "Content-Type: application/json" \ -d '{ "amount": 10990, "currency": "BRL", "payment_method": "CREDIT_CARD", "installments": 1, "card_token": "tok_xxx" }'Atalho sem tokenizar
Se você só quer ver a resposta de erro, mande tok_refused ou tok_error no lugar do card_token. Prefira os números: o atalho pula a tokenização, que é justamente o passo que precisa estar funcionando antes de você tratar uma recusa.
Pix e boleto: o valor escolhe o desfecho
Pix e boleto são assíncronos — a cobrança nasce pending e só vira paid quando o pagamento é confirmado. No sandbox não há quem pague o QR, então quem decide é o final do valor (os dois últimos centavos). Vale para qualquer valor: R$ 10,02 e R$ 5.690,02 se comportam igual.
| Final do valor | Desfecho |
|---|---|
,01 | pago na hora — a própria resposta da criação já volta paid |
,02 | pago em segundos, como um Pix real: nasce pending com QR / linha digitável, e a confirmação chega no webhook charge.paid |
,03 | falha em segundos (charge.failed), como uma cobrança que ninguém pagou |
| qualquer outro | segue pending até expirar |
Use ,02 para validar a integração de ponta a ponta: é o único que exercita QR, webhook e recebível na mesma ordem da produção.
curl -X POST https://bunne.com.br/api/v1/charges \ -H "Authorization: Bearer sk_test_xxx" \ -H "Idempotency-Key: teste_pix_1" \ -H "Content-Type: application/json" \ -d '{ "amount": 1002, "currency": "BRL", "payment_method": "PIX" }'Já tenho uma cobrança pendente na tela
Uma cobrança de Pix ou boleto que já está pending pode ser confirmada pelo botão Simular pagamento, no detalhe da venda no dashboard. Ele existe só no ambiente de testes e roda o mesmo caminho de uma confirmação real (recebível, razão, split e webhook).
Onde estes valores NÃO valem
- Em produção. Com
sk_live_quem decide o desfecho é o pagamento de verdade — um valor terminado em,01é só um valor. - Em qualquer adquirente real. Se o seu ambiente de testes estiver apontado para a sandbox de uma adquirente de verdade, valem os cartões de teste dela. Confirme com quem opera a sua conta qual adquirente responde no ambiente TEST.