IOSOR Guías
El envío del usuario final sigue deduciendo del mismo libro mayor prepago
El envío embebido sigue debitando la billetera prepaga del ISV. No invente un segundo libro mayor que el producto no financie: las retenciones, los reintentos y la idempotencia deben ser honestos.
La mensajería integrada se siente gratuita para el usuario final: toca Enviar dentro de la interfaz de usuario de SaaS y ve un ícono verde de verificación. Sin embargo, bajo la superficie, cada envío exitoso sigue debitando un único libro mayor prepagado propiedad del ISV. No existe una segunda billetera que aparezca mágicamente solo porque el producto integró una API. Si el ISV no financia las retenciones de saldo, el envío debe fallar con un error honesto del producto y nunca con un estado de entrega falso.
Un solo libro mayor, incluso cuando la UI muestre créditos de producto
Los paquetes de mensajes vendidos a los usuarios o inquilinos pertenecen a la capa comercial del ISV. Deben mapearse directamente con retenciones y débitos prepagados en la billetera única de IOSOR que el ISV financia. Un saldo de inquilino que nunca se reconcilia con las filas del libro mayor se convierte en una bomba de deuda para el equipo de soporte.
Las retenciones y la idempotencia siguen aplicando en rutas embebidas
El envío desde el servidor debe utilizar claves de idempotencia para SMS transaccionales y códigos OTP. Un doble clic fortuito en la UI del SaaS no debe generar dos débitos por una sola acción del usuario. Los reintentos posteriores a un tiempo de espera deben continuar usando la misma clave de idempotencia hasta recibir un informe DLR terminal o una falla mapeada correctamente.
Mapear errores de producto con la verdad del libro mayor
| Señal en UI de SaaS | Verdad del libro mayor | Siguiente paso permitido |
|---|---|---|
| Enviado / Entregado | Débito + ruta DLR existente | Mostrar ID de recibo |
| En cola | Retención abierta o envío aceptado | Consultar estado |
| Fallido / Pausado | Retención rechazada o bloqueo activo | Reintentar solo con nueva intención |
| Éxito falso | Sin débito / sin retención | Prohibido estrictamente |
Los traspasos de canal permanecen en la misma billetera
Si el producto añade posteriormente correo electrónico o voz junto con los mensajes SMS, el gasto seguirá acumulándose en el mismo libro mayor prepagado a menos que se realice un traspaso formal con la aprobación explícita de finanzas. La integración embebida no crea un canal secundario gratuito.
Rutas de operaciones relacionadas
- Segundo canal en la cartera: traspaso de gastos
- idempotencia, reintentos y dinero
- Aplicación segura de límites de tasa en cuentas multi-inquilino
Comience con IOSOR
Abra la consola de IOSOR y vincule el sistema de crédito de su inquilino directamente al libro mayor de la billetera prepaga principal. Asegúrese de que todas las solicitudes de integración del lado del servidor pasen una clave de idempotencia determinista antes de aplicar una retención en la billetera maestra. Configure su punto de acceso de webhooks para procesar los informes de entrega entrantes de modo que las retenciones abiertas se resuelvan claramente en débitos o liberaciones definitivas en el libro mayor.
Conclusión IOSOR
Una interfaz de SaaS integrada puede mostrar créditos de mensajes personalizados a los usuarios finales, pero cada envío real se vincula a la única billetera prepaga financiada por el proveedor independiente de software. Los reintentos, las expansiones de canales y las señales de estado del usuario deben conciliarse directamente con las retenciones de la billetera en lugar de abstracciones de interfaz sin respaldo.
Exija claves de idempotencia estrictas en el servidor y vincule cada estado de interfaz del inquilino a respuestas reales de entrega en el libro mayor. No invente billeteras secundarias sin respaldo ni permita que los reintentos de la interfaz del inquilino se ejecuten sin retenciones concretas en el libro mayor.
¿Fue útil esta guía?
Guías relacionadas
- Inserción de la API frente a un portal de socios de marca blanca
Los productos SaaS que integran mensajería permanecen en la interfaz del ISV. Los portales de socios de marca blanca se mantienen bajo Partner; no mezcle marcas, claves y propiedad operativa.
- Cuando el límite de un inquilino incrustado debe detener el envío
Los límites de participación justa dentro de un producto ISV deben detener de forma estricta el envío de ese inquilino, sin devolver un API 200 falso.