Cómo leer una respuesta de error
API v1El rechazo del emisor#
Cuando el emisor rechaza una transacción, la respuesta trae dos campos:
El código de rechazo del emisor.
El texto del rechazo.
Un HTTP 200 no significa éxito#
No hay un estándar definido de cuándo el API responde HTTP 4xx y cuándo responde HTTP 200 con el error en el cuerpo. Conviven las dos formas, y hay cinco envolturas distintas de error según el endpoint.
Consecuencia práctica: tu manejo de errores tiene que mirar el cuerpo siempre, no solo el código de estado, y tolerar más de una forma de cuerpo.
Formas del cuerpo de error#
Error de processModification (type 300 o 400):
{"type":"400","message":"Order number: TYP974_172 does not exist"}Cinco envolturas distintas, según el endpoint:
| Envoltura | Endpoints |
|---|---|
{"error": "Unauthorized"} | login, loginSdk |
{"type", "message"} | processPayment, processModification |
{"type", "result"} | processRecurrentPayment, processTokenize |
{"code", "description", "error"} | servidor a servidor |
{"code", "description"} | rechazo del emisor |
Cómo escribir el manejo de errores#
- Tratá
codeydescriptioncomo datos para registrar y mostrar, no como una enumeración sobre la que ramificar. - No hagas
if (status === 200) éxito. Verificá el cuerpo. - Guardá la respuesta cruda de cada rechazo: es lo que te permite reconstruir el patrón de rechazos de tu comercio.
- Para decidir el estado real de una transacción después de un fallo, usá reintentos seguros.
Última verificación: 2026-10-22