IOSOR Guías

Reserva prepago antes del primer débito

Siga el recorrido verificable desde la reserva de saldo y el disponible hasta el primer débito, incluida la liberación por fallo, caducidad o ejecución parcial.

El primer movimiento de dinero debe entenderse antes de que circule una unidad facturable.

IOSOR aplica una ruta JIT de marca blanca: cotizar, crear la reserva prepago, ejecutar la acción, asignar el resultado y liquidar el importe real.

Qué representa una reserva prepago

La reserva separa fondos para un intent pendiente sin fingir que el servicio terminó.

Evento Movimiento de cartera Significado para el cliente
Reserva creada Baja el disponible y sube lo reservado El importe queda protegido para este intent
Intent completado La reserva se convierte en débito Ocurrió el resultado facturable
Fallo o caducidad El importe vuelve a disponible No se cobró un resultado incompleto

Las transiciones deben ser atómicas.

Reserva frente a saldo disponible

Una única cifra de “saldo” oculta el riesgo de concurrencia. Muestre por separado total, reservado y disponible.

Cada servicio calcula un límite distinto.

Observe también cantidad, antigüedad y vencimiento de las reservas.

El primer débito debe corresponder al resultado

La liquidación se apoya en un hecho observable, no en un clic ni en la entrada a una cola.

La línea del libro conserva el mismo intent ID del evento de producto, servicio, importe, moneda, hora y estado final. Por eso idempotencia, reintentos y dinero pertenecen al diseño de cartera desde el inicio.

La conciliación debe funcionar en ambas direcciones: desde el estado de producto hasta el débito y desde el débito hasta su evidencia.

Fallos anteriores al débito

Un fallo previo a completion termina en liberación o en una ruta explícita de devolución; nunca en dinero desaparecido. Un intent JIT agotado sin evidencia puede liberar la reserva. Para números, consulte fallo de pedido DID reembolso y cambio.

  • Rechazo de validación antes de empezar: no se crea débito
  • Duplicado con la misma clave: se devuelve el intent existente
  • Ejecución fallida con fondos retenidos: se libera toda la reserva
  • Lote parcial: se cobran unidades completas y vuelve la parte sin usar
  • Resultado desconocido: se congelan retry e investigación para impedir otro cargo

Liberar no es lo mismo que devolver. Release restaura fondos aún no liquidados; refund revierte un movimiento ya asentado.

Lista de comprobación para el comprador

  1. ¿Finanzas distingue importes reserved, available y settled?
  2. ¿Cada hold vence y tiene un solo ID de intent empresarial?
  3. ¿Está nombrada la evidencia de completion para cada canal?
  4. ¿Release y refund son visibles sin abrir un caso de soporte?
  5. ¿Los duplicados reutilizan el resultado monetario original?
  6. ¿El saldo bajo detiene trabajo nuevo antes de que choquen reservas? Contrástelo con paradas por saldo bajo.

Revise además permisos: quién prolonga una reserva, quién autoriza una devolución y qué aprobación requiere una excepción.

Comience con IOSOR

Configura los límites de caducidad de retención prepago y los webhooks de estado de autorización en la consola de IOSOR antes de enviar solicitudes facturables de alto volumen. Verifica que tu integración rastree los saldos totales, reservados y disponibles bajo un identificador de correlación unificado. Ejecuta una intención fallida simulada para confirmar que las solicitudes no cumplidas activen automáticamente una liberación inmediata de vuelta al fondo disponible.

Conclusión IOSOR

Una retención prepago aísla fondos para intenciones pendientes para evitar condiciones de carrera y doble gasto sin tergiversar la actividad no facturada como ingresos completados.

¿Fue útil esta guía?

Guías relacionadas