Skip to main content
A API de Purchases com múltiplos cartões 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 chamada antes de criar a Purchase. Depois de um 408 ou 503, a Purchase pode já existir: reenvie a criação com a mesma X-Idempotency-Key e o mesmo corpo para receber o estado atual.
  • Purchase recusada: a criação respondeu 202, mas um cartão foi recusado no processamento. A Purchase termina failed e o motivo, quando existe, fica em payments[].declineReason.
  • Purchase em revisão: a Purchase continua pending com o campo pendingReview, que indica uma anomalia no processamento.

Formato do erro na requisição

Erros na requisição

Quando idempotency_key_payload_mismatch e purchase_operation_in_progress se aplicam ao mesmo tempo, a resposta traz idempotency_key_payload_mismatch.

Erros sem businessCode

Erros do pagamento de Session

POST /v1/sessions/{id}/purchase paga uma Session com múltiplos cartões. Essa rota devolve dois grupos de erros:
  • Erros da própria rota: validações da Session, listadas na tabela abaixo. Os erros 422 vêm com type: bad_request e, em geral, details vazio. A exceção é um seller do split da Session que não existe mais: a resposta é um 422 com type: bad_request, details preenchido e sem businessCode.
  • Erros repassados da API de Purchases: depois das validações da Session, a rota cria a Purchase e repassa sem alteração o status e o corpo de um erro da API de Purchases. Esses erros seguem a tabela de Erros na requisição, por exemplo um 422 com type: validation_error e details preenchido.
Trate os dois grupos pelo businessCode, sem depender de type ou de details. Quando o erro não tiver businessCode, trate-o como recusa genérica pelo status HTTP, sem montar regras com o texto de message.
Um 422 com multiple_payments_limit_reached também pode chegar depois que a API de Purchases aceitou a Purchase, quando a Session não consegue reservar o pagamento ao mesmo tempo que outra cobrança. Nesse caso a Purchase pode existir e seguir em processamento. Antes de oferecer uma nova tentativa ao comprador, liste as Purchases com o filtro sessionId da Session.

Motivo da recusa por cartão

Quando um cartão é recusado, a Purchase termina failed e o cartão traz status: failed. O campo declineReason traz só o código, sem mensagem, e vem de uma destas origens: declineReason é opcional: quando a Malga não recebe um código, o campo é omitido. Trate um cartão failed sem declineReason, ou com um código que você não conhece, como recusa genérica. Use o status da Purchase e do cartão para saber o desfecho, nunca a ausência de declineReason. Quando o cartão tem chargeId, você pode consultar a cobrança em GET /v1/charges/{id} para ver a mensagem e o código original do provedor. Nas recusas da API de Charges antes do provedor e no merchant_not_owned, a cobrança não chega a ser criada e o cartão não tem chargeId: o motivo disponível é o próprio declineReason.

Purchase em revisão

Uma Purchase pending com o campo pendingReview teve uma anomalia no processamento e não avança sozinha. Interrompa o polling automático e acione o suporte da Malga com o id da Purchase.

Erros por webhook

Os eventos purchase.failed e purchase.void_failed não trazem o motivo. Ao receber um deles, consulte a Purchase em GET /v1/purchases/{id}. O passo a passo está em Erros recebidos por webhook.

Exemplos de resposta