Límites y reglas de operación

Aquí está lo que necesitas para diseñar tu integración y no aparece en la OpenAPI: cuánto puedes cobrar de una sola vez, cuánto viven las cosas, cómo funcionan las comisiones y qué pasos todavía requieren escribirle a SPIDI.

Son reglas de la plataforma y del entorno, no del contrato. Por eso pueden cambiar sin que cambie una sola línea del API — y por eso viven en su propia página.

Estas reglas no están en el contrato

Nada de esta página está todavía reflejado en la OpenAPI. Cuando lo esté, esta página lo dirá y podrás validarlo contra el contrato.

Límites de monto

• Cada transacción tiene un tope de monto — sin confirmar. Es una restricción de la normativa del Banco Central de Venezuela, no una decisión de SPIDI: no se sube pidiéndolo, y se mueve cuando el BCV lo mueve.
• Si tu ticket promedio se acerca a esa cifra, tenlo en cuenta desde el diseño. Un pago por encima del tope no se parte solo.
• En un split no hay límite de receptores. El tope de arriba aplica a la transacción completa, no a cuántas partes la reparten.

Límites de tiempo

• La sesión de pago dura lo que tú digas, con duration_minutes: desde 5 minutos hasta 20 minutos. Ese máximo es el techo y no hay forma de pedir más; si no envías el campo, caduca pronto. Pasado ese rato el enlace deja de servir y hay que crear una sesión nueva. → Botón web
• Si necesitas que un pago espere más que eso, no uses una sesión suelta: usa una Solicitud con su fecha de vencimiento, y colócala en una Parada si quieres que el cliente tenga una dirección fija. → Paradas
• Monto mínimo de una sesión: 14 VES. Por debajo, la creación devuelve 400. No lo fija SPIDI: lo fija la regulación de tarifas del BCV, y se mueve.
• El token del login vence pronto, y la rotación frecuente es intencional. No hace falta volver a autenticarse: el login te da también un refreshToken con el que pides una pareja nueva. → Autenticación y entornos
• La URL de una sesión también deja de funcionar cuando el pago se completa, no solo cuando expira. Es normal: un enlace pagado ya cumplió su función.

Límites de operación

Los de arriba condicionan un pago. Estos condicionan cómo llamas a la API, y aparecen cuando automatizas de verdad:

• 100 req/min por comercio. Es el techo de peticiones. Si lo pasas, la respuesta deja de ser tu error: es el límite. Repartir el trabajo en el tiempo sale más barato que reintentar contra una puerta cerrada.
• Hasta 100 items en una operación en lote sobre las sesiones de una Parada. Por encima, parte la lista tú.
• Hasta 200 stop_ids en una consulta masiva de Paradas.
• Una Idempotency-Key vive 24 horas. Dentro de esa ventana, repetir la misma llamada con la misma clave devuelve el resultado de la primera en vez de ejecutarla otra vez. Fuera de ella, la clave ya no protege nada.

Usa siempre Idempotency-Key en las operaciones en lote

Es donde más caro sale reintentar a ciegas: sin ella, un reintento por un corte de red puede duplicar lo que ya se aplicó.

Tres de estas operaciones no responden hoy en el entorno de pruebas, y eso no cambia los límites de arriba — cambia lo que puedes ensayar antes de salir. Está fechado en Estado de la plataforma.

Comisiones

Cómo funcionan hoy:

• Se descuentan en la liquidación. Tú recibes el monto neto, no pagas por adelantado.
• La comisión que se aplica es la del banco procesador (Sofitasa). La plataforma no añade un cargo propio encima: no hay costo de implementación, ni licencias, ni mantenimiento mensual.
• Ves el desglose en tu SPIDI Center y en el correo de notificación: ingreso bruto, comisión descontada, monto acreditado, referencia bancaria y banco destino.
• Para tu contabilidad: las comisiones bancarias no se facturan de la forma tradicional, pero son deducibles como gasto bancario. Los soportes que emite el banco se descargan desde el sistema.

El porcentaje no se documenta aquí, y con razón

La comisión la fija el banco, no la plataforma. Puede variar en el tiempo y de un acuerdo comercial a otro, así que un número escrito en una página de documentación quedaría desactualizado o sería directamente falso para tu caso.

Los ejemplos de este portal usan 1 % como cifra ilustrativa, solo para que las cuentas del ejemplo cuadren y puedas comprobar que tu código lee bien cada campo. No la uses para proyectar lo que vas a recibir.

Para saber cuál te aplica a ti: consúltalo con el equipo comercial. Lo que sí es estable —y lo que tu integración necesita— es la forma del desglose: → Comisiones y liquidación.

Lo que todavía se pide por soporte

Dos cosas meten a una persona en medio de tu flujo. Convienen saberlas antes de planificar:

• El paso a producción. No es autoservicio y no lo será: hay una reunión de certificación de por medio. → Pasar a producción
• Incidencias con pagos en cripto. Si algo falla del lado de Crixto o Binance, se escala por soporte: te pediremos el crypto_order_id y la captura del pago para gestionarlo. Es el identificador que devuelve el proveedor y que encuentras en crypto_details del estado de la sesión. → Métodos de pago

El acuerdo de recepción de un split sí es autoservicio

Si leíste en otro sitio que hay que pedirlo por mensaje, ya no es así: se obtiene por API. → Split

De dónde puedes recibir

Puedes recibir pagos desde cualquier banco de Venezuela. No hay que dar de alta bancos ni pedir habilitaciones por banco de origen.

---

¿Buscabas qué está declarado en el contrato pero todavía no funciona? Eso vive aparte, y con fecha: → Estado de la plataforma