Skip to main content
Todos los errores comparten el mismo formato:
  • error: código estable en snake_case — úsalo en tu lógica.
  • message: explicación legible — puede cambiar, no lo parsees.
Mensajes de error saneados. El message de un error nunca expone nombres de proveedores, detalles de infraestructura, URLs, bodies crudos del proveedor (JSON/HTML) ni configuración interna — ni en respuestas de la API, ni en webhooks, ni en los campos de estado persistidos. Los rechazos de negocio del procesador conservan su motivo accionable (por ejemplo, por qué se rechazó un documento o una cuenta); las fallas de infraestructura se reemplazan por el mensaje genérico fijo "the payment provider could not process the request" — reintenta esas operaciones con la misma idempotency_key.

Códigos por categoría

Autenticación y permisos

OTP / 2FA

Detalle y flujo completo en seguridad y 2FA.

Login social (OAuth)

Detalle y flujo completo en login social.

Panel de administración de organización

Estos códigos provienen de superficies de administración de organización (el panel CBPay Admin), no de la API a nivel cuenta documentada arriba — nunca aparecen en los endpoints /v1/* de cuenta.

Validación (400)

Dinero y estado (402 / 404 / 409 / 422)

Cumplimiento (403 / 503)

Qscore

Errores de los endpoints del buró de crédito (guía).

Firewall transaccional

Errores de la revisión de operaciones retenidas por el firewall transaccional (guía). La retención en sí no es un error: el create responde 202 Accepted con status: in_review y review_id.

Eventos en tiempo real (SSE)

Códigos de GET /v1/events y su historial.

Firma de mensajes y vinculación de wallets

Códigos de la firma de mensajes con wallets (EIP-191 en EVM, TIP-191 en TRON): firma server-side con wallets segregadas (POST /v1/segregated-wallets/{id}/signatures, que emite un comprobante de firma verificable públicamente) y vinculación de wallets externas por desafío (POST /v1/wallet-links/challenges → firmas el desafío con tu wallet → POST /v1/wallet-links/verify).

Servicio (5xx)

Cómo manejarlos

  • 4xx de validación: corrige el request. No reintentes igual.
  • 402: fondea la cuenta y reintenta (clave de idempotencia nueva solo si la operación nunca se creó).
  • 5xx / timeouts: reintenta con la misma clave de idempotencia; la operación nunca se duplicará.
Última modificación el 22 de agosto de 2026