Skip to main content
Este guia descreve o contrato público de boleto em POST /v1/payments. Use-o para montar o request e ler a resposta. O paymentMethod é boleto. O objeto boleto no body só envia o vencimento. Nome, documento e endereço ficam em customer. Referência do endpoint: Criar pagamento. O PDF fica em Consultar PDF do boleto.

Campos obrigatórios

Envie paymentMethod: "boleto". O customer é obrigatório. NOTA: Sem customer.address completo a API retorna 400. A falha ocorre na validação do body.

Vencimento

Sem boleto ou sem expirationDate, o vencimento é 30 dias. Se enviar boleto.expirationDate:
  • Use ISO 8601 com offset (Z, ±HH:MM ou ±HHMM).
  • A data deve estar no futuro.
  • A data deve estar no máximo 30 dias à frente.
Data passada, formato inválido ou além de 30 dias: a API retorna 400.

Resposta

A criação retorna status: "waiting_payment" e paymentMethod: "boleto". O PDF do boleto não vem na criação. Ele é gerado em background. Consulte GET /v1/payments/{id}/boleto até status ser ready. POST /v1/payments, GET /v1/payments/{id} e o webhook da transação retornam só boleto.digitableLine. Esses endpoints não retornam url nem barcode. O pagador pode quitar pela linha digitável ou pelo QR Pix. O paymentMethod permanece boleto.

PDF do boleto

GET /v1/payments/{id}/boleto usa a mesma autenticação de GET /v1/payments/{id}. A resposta é 200 quando o pagamento existe, é do merchant e é boleto: O endpoint aceita 30 requests por minuto por IP. Se o limite estourar, a API retorna 429 com header Retry-After. Se o pagamento não existir ou não for do merchant, a API retorna 404. Se o pagamento não for boleto, a API retorna 422. NOTA: A url é assinada. Consulte o endpoint de novo quando ela expirar. Exemplo quando o PDF está pronto:

Estorno

ATENÇÃO: Boleto não aceita estorno. PUT /v1/payments/{id}/refund não estorna cobrança de boleto.

Exemplo de request

Exemplo de resposta