Límites y mínimos

Una dispersión tiene que caber entre el mínimo y el tope de su instrumento. Fuera de ese rango se rechaza antes de mover dinero.

	Valor	Quién lo pone
Mínimo por operación	~925,00 Bs (1 token)	El riel
Tope por operación, pago móvil	100.000,00 Bs (10000000)	El banco receptor
Tope por operación, transferencia	500.000,00 Bs (50000000)	El riel bancario
Tope diario	2.000.000,00 Bs (200000000)	El riel bancario

Los topes son del ecosistema bancario venezolano, no una decisión comercial nuestra: pago móvil está más limitado que transferencia porque así lo fijan los bancos receptores. Si tu operación necesita más, se gestiona con el riel.

El mínimo está en tokens, no en bolívares

El piso del riel está fijado en 1 token. Se convierte con la tasa vigente en cada envío, así que su equivalente en Bs se mueve todos los días.

~925 Bs es de hoy, no una constante

A la tasa medida de 924,5231 Bs/USDT, 1 token son ~925,00 Bs.

Si tu producto dispersa importes pequeños, no los dejes al borde: un movimiento de tasa los pasa al otro lado y la dispersión se rechaza con reason: "amount_below_rail_minimum". Deja margen o redondea hacia arriba.

Se comprueba antes de llamar al riel, así que un importe demasiado pequeño no gasta un intento: la dispersión responde 201 con status: "failed", reason: "amount_below_rail_minimum" y el asiento revertido. No se te cobra nada.

El tope de pago móvil

100.000,00 Bs por operación, el más bajo de los dos instrumentos. Superarlo devuelve 422 limit_exceeded, con el detalle en meta:

422 Unprocessable Entity

{ "error": {
    "type": "invalid_request_error", "code": "limit_exceeded",
    "message": "Supera el límite por operación de pago móvil",
    "request_id": "req_8a0312ba896772bc441134cd",
    "meta": { "limit": "per_tx_max", "max": "10000000", "scope": "platform" } } }

Los cuatro límites

meta.limit	Qué mide
per_tx_max	Importe máximo de una operación
daily_max	Importe acumulado del día
monthly_max	Importe acumulado del mes
daily_count_max	Número de operaciones del día

Los límites tienen instrumento: un mismo importe puede caber por transferencia y no por pago móvil. También hay límites por beneficiario.

Precedencia

beneficiary  >  customer  >  tenant  >  platform

Y dentro de cada nivel, el instrumento concreto antes que *. El más específico gana entero: los topes no se intersecan, se sustituyen. meta.scope dice qué regla rechazó el pago.

Consultar tu consumo

curl -s "$BASE/v1/limits/usage?asset=BS" -H "x-api-key: $KEY"

200 OK

{
  "asset": "BS",
  "usage": { "day_amount": "45371900", "day_count": "38",
             "month_amount": "912440000" },
  "limit": { "scope": "tenant", "method": "*",
             "per_tx_max": "10000000", "daily_max": "500000000",
             "monthly_max": null, "daily_count_max": null }
}

Campo	Qué es
usage.day_amount · usage.month_amount	Importe dispersado hoy y este mes, en unidades menores
usage.day_count	Operaciones de hoy
limit	La regla que se te aplica. null si no hay ninguna configurada

Acepta customerId para ver el consumo de un usuario tuyo concreto.

El consumo no distingue instrumento; la comprobación sí

GET /limits/usage da el acumulado del activo, sin separar pago móvil de transferencia. La comprobación que hace la dispersión sí filtra por instrumento. Con topes distintos por instrumento, usa esta cifra como orientación, no como cálculo exacto.

Lo dispersado que quedó en failed o reversed no cuenta para el consumo.

Y el techo del riel

Por encima está el del propio riel (reason: "amount_above_rail_limit") y su liquidez del momento (reason: "rail_insufficient_balance"). Ésos no se suben por cliente: hay que partir el pago o esperar.

Dónde se rechaza	Cómo lo ves
En nuestros límites	422 limit_exceeded con error.meta
En el riel	201 con status: "failed" y reason

Ver errores para la diferencia entre las dos taxonomías.