Pular para o conteúdo principal
Formato do erro A API do Payments responde a uma requisição com falha com um dos três corpos possíveis. Qual corpo você recebe depende de onde o serviço captura a falha, não do endpoint que você chamou. Uma falha que o pipeline de requisição captura antes que a camada da API a veja responde com um corpo JSON simples no application/json. O pipeline autentica o chamador (PBP-0003 em 401) e autoriza a ação (PBP-0004 em 403). Ele também abre o armazenamento do tenant (PBP-0008 em 503) e executa a verificação de idempotência. Tudo o que a camada da API captura responde com um documento de problema RFC 9457 no media type application/problem+json. O limitador de taxa de todo o serviço responde 429 com o texto simples Too Many Requests e sem código de erro.
Definições de campo
  • type – Um URI que identifica o erro no catálogo de erros da Lerian. Construído como https://errors.lerian.studio/v1/<code>.
  • title – O texto do status HTTP, por exemplo Unprocessable Entity.
  • status – O código do status HTTP.
  • detail – Texto sobre esta ocorrência da condição. O texto vem do trecho de código que a gerou.
  • code – Um identificador estável para a condição. Baseie o tratamento nesse valor.
  • errors – Lista opcional de detalhes de validação por campo, cada um com uma message, uma location e o value encontrado ali.
Nos status 500, 502 e 503, o membro detail traz um texto fixo em vez de uma descrição da sua requisição, então leia code para identificar a condição. O corpo simples traz code, title, message e um objeto details opcional. Ele nunca traz type, status ou detail. Cinco códigos chegam até você como corpo simples quando a verificação de idempotência os gera: PBP-0002, PBP-0007, PBP-0008, PBP-0012 e PBP-0013. O pipeline também responde assim para uma falha que nenhum handler capturou. Então leia o media type em vez do código para diferenciar as duas formas de corpo.

Erros de plataforma


Esses códigos não são específicos de um trilho. A camada de transporte, o pipeline de requisição e os handlers os geram.

Erros do provedor


Esses códigos trazem a resposta do provedor de pagamento. O que é seguro reenviar depende da operação, então leia as descrições de erro da operação na referência da API antes de reenviar.

Erros de boleto


Esses códigos respondem no trilho de boleto: emissão, parcelas, cancelamento e obtenção do PDF.

Erros de pagamento


Esses códigos respondem no trilho de pagamento de contas: bankslip, utilities, DARF e a consulta de conta.

Erros do ledger


Esses códigos trazem o lado do ledger em um pagamento. O que é seguro reenviar depende da operação, então leia as descrições de erro da operação na referência da API antes de reenviar.

Erros de configuração de webhook


Esses códigos respondem a uma requisição que configura para onde esta API envia as notificações de eventos.

Erros de webhook de entrada do provedor


Esses quatro códigos respondem ao provedor de pagamento que envia eventos de liquidação ao endpoint de webhook. Eles informam a esse chamador qual correção a entrega precisa.