Payments Direct retorna respostas de erro padronizadas em todas as operações da sua API, o que facilita registrar, monitorar e diagnosticar problemas de integração.
Os endpoints de token OAuth são a exceção. Eles seguem o formato de erro do OAuth 2.0, descrito em Erros de autenticação.
Com exceção dos endpoints de token OAuth, toda resposta de erro tem a mesma estrutura: um status de nível superior e um array errors contendo um ou mais objetos de erro.
| Campo | Tipo | Descrição |
|---|---|---|
status | integer | O código de status HTTP da resposta. |
errors | array | Um ou mais objetos de erro que descrevem o que deu errado. Uma única requisição pode falhar por mais de um motivo. |
Cada objeto do array errors contém os seguintes campos:
| Campo | Tipo | Descrição |
|---|---|---|
code | string | Um identificador único do erro (por exemplo, USR_067). |
type | string | A categoria do erro. Um de: AUTH_ERROR, USER_ERROR, NOT_FOUND, CONFIGURATION_ERROR, SYSTEM_ERROR. |
title | string | Um resumo curto e legível do erro. |
description | string | Uma explicação concisa do erro. Pode incluir instruções de recuperação. |
timestamp | string (ISO 8601) | O momento em que o erro ocorreu. |
O status aparece uma única vez, no nível superior da resposta. Ele não é um campo dos objetos de erro individuais. Sempre percorra errors como um array, mesmo quando ele contiver uma única entrada.
{
"status": 402,
"errors": [
{
"code": "USR_067",
"type": "USER_ERROR",
"title": "Insufficient balance",
"description": "Payment failed due to insufficient balance. Add funds to your account and try again.",
"timestamp": "2025-08-21T10:15:30Z"
}
]
}Ao construir a sua integração:
- Sempre registre e monitore os campos
codeestatusem todas as respostas de erro. - Verifique primeiro o código do erro ao decidir como tratá-lo. Não dependa apenas do código de status HTTP.
- Trate o campo
descriptioncomo orientação para pessoas, não como lógica programática. O texto dele pode mudar entre versões.
Alguns erros são transitórios e permitem nova tentativa; outros indicam uma condição que precisa ser resolvida antes do reenvio.
| Tipo de erro | Status HTTP | Tentar novamente? | Ação recomendada |
|---|---|---|---|
USER_ERROR | 400, 404, 415 | Não | Corrija a requisição e reenvie. |
USER_ERROR | 402 | Não (até ser resolvido) | Resolva a condição subjacente (saldo, limites ou dados de identidade) antes de tentar novamente. |
NOT_FOUND | 404 | Não | Verifique o ID do recurso e reenvie. |
AUTH_ERROR | 401 | Após renovar o token | Gere um novo token de acesso e tente novamente. |
AUTH_ERROR | 403 | Não | Verifique se o seu token tem os escopos necessários para esta ação. Em operações de pagamento, um 403 também pode significar que o pagamento existe, mas pertence a outro tenant. |
SYSTEM_ERROR | 500 | Sim, com backoff | Tente novamente com espera exponencial. Entre em contato com o suporte técnico da Ripple se o problema persistir. |
SYSTEM_ERROR | 503 | Sim, após o horário informado | Há uma janela de manutenção em vigor. A descrição do erro informa quando o serviço deve voltar. Tente novamente após esse horário, e não imediatamente. |
CONFIGURATION_ERROR | 500 | Não | Entre em contato com o suporte técnico da Ripple. |
Para a lista completa de códigos de erro, consulte a referência Erros da API.
Para orientações sobre estratégia de nova tentativa, backoff exponencial e monitoramento, consulte Tratamento de erros e estratégia de nova tentativa.