Skip to main content
Este guia mostra a ordem das chamadas e o que fazer com cada resposta. Os detalhes de cada campo estão na referência de cada rota.
1

Configure o webhook

Cadastre o endpoint no dashboard com autenticação e mais de uma tentativa. Veja Configurar endpoints.
2

Crie a cobrança no seu servidor

Pedido avulso (POST /v2/orders) ou assinatura (POST /v2/subscriptions), sempre com Idempotency-Key.
3

Trate a resposta

Leia o status e o next_action. 201 não significa pago; 402 é um pagamento recusado com o recurso completo.
4

Libere o acesso no webhook

order.paid para pedidos e invoice.paid para assinaturas. Processe cada id de entrega uma vez só.
A API recebe os dados do cartão do seu servidor: não há tokenização no navegador. Trafegue só por HTTPS, nunca registre em log nem guarde número e CVC, e descarte-os depois da chamada. Para reutilizar um cartão, salve-o com POST /v2/cards.

Venda avulsa no cartão

POST /v2/orders
  • Envie capture_method: "automatic". O padrão é manual: o pedido fica em requires_capture e a autorização é cancelada em cerca de 26 h se você não chamar POST /v2/orders/{id}/capture.
  • Parcelas não mudam o valor. Se você cobra juros, some-os ao amount dos itens e do pagamento.
  • customer.ip é o IP do comprador, usado nos bloqueios de cliente.
  • Grave o id do pedido (ord_...) e o payments[].id (cha_...). São eles que chegam nos webhooks; o pedido não devolve o seu metadata.

PIX no seu checkout

POST /v2/orders
  • A resposta vem em requires_action com next_action.type: "pix_display_qr_code". Mostre next_action.pix.qr_code_url (imagem) e next_action.pix.qr_code (copia e cola).
  • pix_expiration é em segundos. next_action.pix.expires_at vem como AAAA-MM-DD HH:MM:SS, no horário de Brasília e sem fuso: converta antes de mostrar a contagem regressiva.
  • Atualize o seu banco no webhook order.paid e faça a página consultar o seu servidor. O limite de 120 requisições por minuto vale para a conta inteira, então evite consultar a API em loop.
  • Sem pagamento, chega charge.expired. Ofereça um novo PIX.

Assinatura

POST /v2/subscriptions
  • Não existe mês de calendário: “mensal” é day × 30 e “anual” é day × 365. Para fixar o dia, ajuste com next-billing-date.
  • Na assinatura, customer.document e items[].code são obrigatórios.
  • A primeira fatura vem em latest_invoice. Trate o status dela como o de um pedido; o código de verificação da fatura vai em POST /v2/invoices/{id}/confirm.
  • No PIX, cada ciclo gera uma fatura com um QR code novo, entregue no invoice.created. Envie esse QR code ao seu cliente.

Cupons e descontos

  • Não há objeto de cupom: o seu sistema valida o código, os usos e a validade.
  • Pedido: envie o preço já com desconto.
  • Assinatura: discounts: [{ "type": "percentage", "value": 50, "invoice_number": 1 }]. Sem invoice_number, vale para todas as faturas. Não combina com split.

Estorno

POST /v2/charges/{id}/refund com o cha_.... É assíncrono: o resultado chega em charge.refunded ou charge.partial_refunded.

Antes de ir para produção

Sempre capture_method: "automatic" no cartão.
Valores em centavos.
Idempotency-Key estável por operação (ex.: ord-<id>), reaproveitada no retry.
Timeout, 5xx ou 409 idempotency_key_in_use: repita com a mesma chave ou aguarde o webhook, sem marcar como falho.
No máximo 2 tentativas por minuto por comprador para os mesmos itens (retries contam). Respeite o Retry-After.
Webhook com autenticação, mais de uma tentativa, deduplicado pelo id e sem regressão de status.
Dados do cartão fora de logs e do banco.