Saltar al contenido principal
Las tarjetas CBPay gastan Just-In-Time del saldo central de la cuenta: no hay que prefondearlas ni moverles saldo. Cada tarjeta elige desde qué saldo gasta (spending_asset: USDT, USDC, BTC o GOLD). USDT/USDC van 1:1 con el USD; BTC y GOLD se convierten al precio del momento de cada evento. Cada compra se autoriza en tiempo real contra el saldo disponible de ese asset y los límites propios de la tarjeta, y el débito queda de inmediato en el historial de movimientos.

Cuántas tarjetas puedes tener

Cada tarjeta gasta del saldo central de la cuenta en el asset que tenga configurado (spending_asset, USDT por defecto). El control fino es por límites de gasto de cada tarjeta (por transacción, diario, mensual), que siempre se miden en USD y puedes cambiar en cualquier momento.

Elegir el saldo de gasto (USDT, USDC, BTC o GOLD)

Define spending_asset al crear la tarjeta o cámbialo después con PATCH. Solo afecta compras futuras: las autorizaciones en vuelo conservan el asset con el que se debitaron (y su anulación devuelve ese mismo asset).
USDT y USDC valen 1 USD, así que la conversión es exacta 1:1 y sin comisión de cambio: una compra de 25.00 USD debita 25.000000 del asset elegido. BTC y GOLD se convierten con el precio efectivo del momento de cada evento (el mismo precio de settlement que ves en GET /v1/rates, bloque settlement):
  • Autorización: se reserva el equivalente de la compra en tu asset más un pequeño colchón (no es un cobro: cubre la variación del precio hasta la liquidación y se devuelve al capturar). Si el precio de ejecución no está disponible en ese momento, la compra se declina (pricing_unavailable) — nunca se convierte con un precio no confiable.
  • Liquidación (captura): el monto final se re-convierte al precio del momento de la captura; el sobrante del colchón vuelve a tu saldo (o se debita la diferencia si el precio se movió más que el colchón).
  • Anulación de una autorización: se devuelve el monto EXACTO reservado, sin conversión.
  • Devoluciones y ajustes posteriores a la captura: se re-convierten al precio del momento del evento. Entre la compra y la devolución el precio puede variar — recibes el equivalente en tu asset al precio de ese momento, no la cantidad original.
  • Las compras BTC/GOLD comparten los límites de assets volátiles de tu cuenta (por operación y volumen 24 h, visibles en GET /v1/settlement).
Si el saldo del asset elegido no alcanza, la compra se rechaza con insufficient_funds — no hay fallback automático a otro saldo.
Con BTC/GOLD tu saldo queda expuesto a la variación del precio entre los eventos de una compra (autorización, captura, devolución). Cada conversión usa el precio efectivo del momento — CBPay nunca re-cotiza montos hacia atrás ni te descuenta “por si acaso”: el colchón de la autorización se devuelve siempre al liquidar.

Costos (configurados por tu operador, pueden ser 0)

Los montos exactos se consultan en GET /v1/rates (campo fees). Todo cargo de emisión se reembolsa automáticamente si la emisión falla.

Crear una tarjeta

El flujo depende de si tu cuenta es persona o empresa — elige tu pestaña. La regla común: el titular (cardholder) se verifica UNA sola vez por cuenta, en la primera emisión; las siguientes tarjetas lo reutilizan sin pedir datos. La idempotency_key es obligatoria siempre (un retry con la misma clave devuelve la tarjeta original y nunca cobra dos veces).
Una cuenta persona emite tarjetas para sí misma (máximo 1 virtual + 1 física).Tu primera tarjeta crea y verifica tu titular en el emisor. Como tu cuenta ya aprobó su verificación de identidad, tus datos y documentos se completan solos desde tu verificación — solo agregas los campos propios del emisor (occupation, salary_usd); cualquier campo que envíes explícito gana sobre el autofill:
occupation es un código del catálogo (ver abajo) y salary_usd va en dólares enteros. Si tu verificación se hizo por wizard sin algún dato o documento que el emisor exige, agrégalo explícito al cardholder (first_name, email, address, id_front_url…, mismo formato de siempre).Tu segunda tarjeta (por ejemplo la física) ya no pide ningún dato — tu titular quedó verificado:
Si intentas una tercera del mismo tipo: 409 card_limit_reached (cancela la existente primero).
Respuesta (misma forma en todos los casos):
Puedes fijar el saldo de gasto desde el inicio agregando "spending_asset": "USDC" al body de creación (USDT si no lo mandas).
Los documentos se validan de verdad por el emisor: las URLs deben apuntar a documentos legítimos y accesibles. Si faltan o son insuficientes, la emisión falla (422 core_rejected o 409 cardholder_kyc_pending), el fee se reembolsa automáticamente y puedes reintentar corrigiendo los datos.
¿Persona o empresa? Las diferencias entre ambos tipos de cuenta en TODOS los productos están resumidas en personas y empresas.
Al designar una persona, occupation debe ser un código del catálogo oficial (no texto libre); para una empresa, kind_of_business también. Consulta y busca los códigos en:
Cada item trae { "code": "...", "label": "..." }. Usa el code en occupation / kind_of_business. Si mandas un valor fuera de catálogo, la API responde 400 invalid_occupation o 400 invalid_kind_of_business antes de llegar al emisor. El salary_usd va en dólares (entero).

Tarjetas físicas: activación

Una tarjeta física nace en pending_activation y viaja inactiva por seguridad. Cuando el titular la tiene en mano:

Ver PAN y CVV (datos sensibles)

Solo la cuenta dueña puede revelarlos (nunca el org admin). La respuesta es de una sola pasada: muéstrala al titular y descártala.
Nunca almacenes ni loguees el PAN/CVV. CBPay tampoco lo persiste: la respuesta viene directo del emisor (estándar PCI).

Límites y congelar/descongelar

Actualizar límites
"0" elimina un límite. Para congelar (rechaza toda compra al instante):
Congelar

Transacciones y su ciclo de vida

spend_asset / spend_amount indican desde qué saldo se debitó realmente la compra y cuánto en ese asset (amount_usd / amount_usdt siguen siendo el valor USD de referencia). En BTC/GOLD, spend_amount de una transacción autorizada incluye el colchón de reserva; al liquidar queda el monto final. Si la liquidación llega por un monto distinto al autorizado (propinas, conversión del comercio), el ajuste se aplica automáticamente: positivo debita la diferencia, negativo la devuelve.

Cancelar una tarjeta

Irreversible. Cobra card_cancellation si está configurado.

Webhooks

Suscríbete igual que al resto de eventos (ver Webhooks).

Preguntas frecuentes

No. Las tarjetas no tienen saldo propio: cada compra se autoriza en tiempo real contra el saldo de la cuenta (en el asset de gasto de la tarjeta). Si hay saldo y la compra respeta los límites, se aprueba.
Todas gastan de los saldos centrales de la cuenta. Cada autorización debita de forma atómica: nunca se aprueba más que el saldo disponible del asset, sin importar cuántas tarjetas operen en paralelo.
Las compras se procesan en USD y se debitan del saldo que la tarjeta tenga configurado (spending_asset). USDT/USDC van 1:1 con el dólar, sin comisión de conversión; BTC y GOLD se convierten con el precio efectivo del momento de cada evento (el mismo del bloque settlement de GET /v1/rates).
Sí: spending_asset es por tarjeta. Una empresa puede tener, por ejemplo, tarjetas corporativas gastando USDT, las de empleados gastando USDC y una personal gastando BTC. El cambio con PATCH aplica solo a compras futuras.
La liquidación de una compra llega 1-2 días después de la autorización, y el precio de BTC/oro puede moverse entre medio. Por eso la autorización reserva el equivalente de la compra más un pequeño porcentaje. No es un cobro: al liquidar, la compra se re-convierte al precio de ese momento y todo lo reservado de más vuelve a tu saldo automáticamente.
La compra se declina (pricing_unavailable) — CBPay nunca convierte tu saldo con un precio no confiable. Es una condición transitoria (feed de precios degradado): reintenta en unos minutos o cambia la tarjeta a USDT/USDC. Los eventos que no se pueden rechazar (la liquidación de una compra ya aprobada, una devolución) nunca se bloquean: se procesan con el último precio conocido más un margen prudencial, auditado en el movimiento.
Las devoluciones se convierten al precio del momento de la devolución, no al de la compra: recibes el equivalente en tu asset del monto USD devuelto. Si BTC subió desde la compra, recibes menos BTC (mismo valor USD); si bajó, más. Tu saldo BTC/GOLD siempre está expuesto al precio — es la naturaleza de gastar desde un asset volátil.
La tarjeta se congela automáticamente (evento card_status_changed con reason: monthly_fee_unpaid). No se genera deuda; al regularizar el saldo, pide descongelarla con PATCH { "frozen": false }.
Las cuentas empresa pueden emitir para cualquier persona designada. Esa persona debe tener su verificación KYC aprobada — pasas su verification_id en el cardholder y sus datos y documentos se completan solos. La tarjeta gasta siempre del saldo de la cuenta empresa que la emitió.
Última modificación el 10 de julio de 2026