Skip to main content
A API de Charges devolve erros de três formas:
  • Erro na requisição: a resposta tem status 4xx ou 5xx e o objeto error. Os erros de validação dos dados enviados recusam a requisição antes de criar a cobrança. Um erro de servidor (5xx) ou um tempo limite excedido pode acontecer depois que a cobrança foi criada: antes de tentar de novo, liste as cobranças filtrando pelo orderId do pedido.
  • Cobrança recusada: o pagamento foi processado e recusado. A cobrança existe e tem status: failed. Esse é o caso que também chega por webhook.
  • Reprovação do antifraude: o antifraude reprovou a cobrança, antes ou depois da autorização. O status final depende de quando o antifraude roda e das opções do provedor antifraude. Veja Reprovação do antifraude.

Cobrança recusada

Quando o emissor ou o provedor recusa o pagamento, a cobrança fica com status: failed. A resposta de POST /v1/charges, a consulta em GET /v1/charges/{id} e o evento transaction.failed trazem os mesmos campos:
  • error.declinedCode é o código padronizado pela Malga. Os valores estão na tabela de declinedCode.
  • providerError.networkDeniedReason e providerError.networkDeniedMessage trazem o código e a mensagem originais do provedor. Use para investigar um caso, não para regras.
O significado de cada campo está em Erros recebidos por webhook. Uma cobrança failed pode vir sem o objeto error: ele só aparece quando existe um declinedCode. Isso acontece, por exemplo, quando a cobrança falha antes de chegar a um provedor. Use o status para saber se a cobrança foi recusada e trate a ausência de código como recusa genérica.

Reprovação do antifraude

Quando o antifraude reprova uma cobrança, o resultado não aparece em error. A análise fica em uma tentativa com requestType: anti_fraud, no campo transactionRequests[].fraudAnalysis.status, que vale reproved. Essa tentativa tem requestStatus: success, porque a análise foi concluída, e não traz providerError. O status final da cobrança depende de quando o antifraude roda e das opções do provedor antifraude: Os arranjos de capture e runBeforeCharge estão em Antifraude síncrono.
Para detectar a reprovação, leia fraudAnalysis.status, qualquer que seja o status da cobrança. Não dependa do evento transaction.failed nem de error.declinedCode.

Formato do erro na requisição

No erro da requisição o código vem em declined_code (com sublinhado). Na cobrança recusada e no webhook, o código vem em declinedCode. A exceção é o 401 de token expirado, que também usa declinedCode. type e declined_code são texto aberto: trate um valor que você não conhece como erro genérico.

Erros na requisição

Os erros estão agrupados por assunto. Escolha uma aba:

Exemplos de resposta