Cómo eliminamos los cobros dobles a nivel arquitectónico

Un huésped de un hotel pulsa «modificar reserva» en la tableta de la habitación a las 11:47pm. La comprobación 3DS tarda 40 segundos. Se pierde la señal del teléfono. Vuelve a pulsar. En la mayoría de los sistemas de hostelería, se le cobra dos veces y llama a recepción por la mañana. En el nuestro, se le cobra una sola vez. Físicamente. No «por lo general». No «con supervisión». Arquitectónicamente.

Este artículo trata sobre el motor de modificación Self-Service que mDOS ha lanzado a producción este mes, y por qué el trabajo de ingeniería de pagos subyacente es más importante comercialmente de lo que sugiere su utilidad operativa.

El problema que la mayoría del SaaS para hostelería no ha resuelto

La modificación autoservicio (permitir que un huésped cambie su propia reserva, pedido o estancia sin llamar a recepción) suena a funcionalidad. Lo es. Pero el sustrato de ingeniería sobre el que se asienta es implacable de una forma que la mayoría de los equipos de producto no perciben hasta que lo lanzan y empiezan a recibir contracargos.

El escenario básico: un huésped necesita modificar algo que cuesta dinero. Tal vez desee subir de categoría de habitación. Tal vez quiera añadir un tratamiento de spa a una estancia que ya está en curso. Tal vez vaya a reembolsar parcialmente un depósito porque su grupo ha pasado de 12 a 10 personas. O tal vez esté cambiando las fechas de una reserva con tarifa flexible y deba asumir la diferencia de tarifa.

En todos estos casos, el flujo operativo es el siguiente: identificar la modificación, calcular el diferencial financiero (puede ser un cargo, un reembolso o ambos en escenarios complejos de modificación parcial), enrutar el pago, actualizar el registro de la reserva y activar cualquier flujo posterior (ajustes de fidelización, correos electrónicos de confirmación, notificaciones de operaciones).

En la mayoría de las plataformas de hostelería, este flujo se construye de forma secuencial, donde cada paso llama a un sistema diferente: primero se actualiza el sistema de reservas, luego se llama al procesador de pagos, después se informa al sistema de fidelización y finalmente el sistema de correo electrónico envía la confirmación. Cada paso tiene su propio modo de fallo. Cada paso es una oportunidad para completarse solo a medias.

El modo de fallo específico que cuesta dinero real a los operadores: la conexión del huésped se interrumpe entre la llamada de pago y la confirmación del sistema de reservas. Desde la perspectiva del huésped, la solicitud ha fallado. La tableta muestra un error. Vuelve a intentarlo. El reintento se completa. El pago original también se procesó, porque estaba en curso cuando se perdió la conexión. Se cobra al huésped dos veces. Recepción se entera a la mañana siguiente. El huésped disputa el cargo. El operador asume la pérdida, las comisiones por disputa, el tiempo de atención al cliente y el daño a su reputación.

No se trata de un supuesto hipotético. Es la incidencia de atención al cliente sobre pagos más común en el SaaS para hostelería. La mayoría de los operadores simplemente se han acostumbrado a convivir con ello.

Lo que mDOS hizo de forma diferente

El motor Self-Service trata cada modificación como una transacción con una clave de idempotencia determinista. La clave se deriva de la intención del huésped: la reserva que se modifica, el cambio específico que se realiza y el diferencial financiero aplicado. Si la misma clave llega dos veces en un espacio corto de tiempo, el sistema la reconoce como un reintento y devuelve la respuesta original en lugar de procesar la modificación de nuevo.

Esto parece sencillo. No lo es. Las partes complejas son:

Derivación de clave resistente a información parcial. El primer intento del huésped puede tener un estado de formulario parcial. Su reintento puede presentar un estado ligeramente diferente si volvió a escribir algo. La clave debe ser lo suficientemente específica como para identificar la intención de manera unívoca, lo suficientemente genérica como para coincidir con el reintento y totalmente infalsificable para que un usuario malintencionado no pueda replicar un pago correcto.

Cargos off-session con tarjeta guardada. La primera vez que un huésped paga durante una estancia, la tarjeta se guarda de forma segura mediante el almacenamiento de métodos de pago de Stripe. Las modificaciones posteriores durante la misma estancia utilizan la tarjeta guardada para realizar cargos fuera de sesión (off-session): sin reintroducir la tarjeta, sin fricción y sin tasa de abandono de modificaciones. Sin embargo, los cargos fuera de sesión pueden activar verificaciones 3DS que requieren que el huésped confirme a través de la app de su banco, lo que significa que el sistema debe derivar de forma fluida a un flujo en sesión (on-session) si el banco lo exige.

Contabilidad en peniques enteros. El dinero se almacena y liquida en peniques enteros (o la unidad base equivalente para monedas distintas de GBP). Los saldos, cargos y reembolsos nunca pasan por coma flotante. Cuando un total único debe distribuirse entre varias partes (como asignar un descuento a nivel de cesta entre líneas, o dividir un depósito), la parte proporcional se calcula y redondea a peniques enteros en el momento de la asignación. Mantener el libro mayor en peniques enteros elimina toda una categoría de errores de redondeo que el SaaS de hostelería suele lanzar a producción (y corregir en silencio mediante procesos de conciliación).

Flujos combinados de reembolso parcial y venta incremental. Un escenario habitual: un huésped reduce el tamaño de su grupo de 8 a 6 personas, lo que supone el reembolso parcial de dos depósitos, pero también mejora su opción de menú, lo que supone un cargo adicional. El sistema debe calcular el neto correctamente, aplicar el reembolso y el cargo en un orden determinista y mostrar el diferencial final al huésped con el desglose correcto. mDOS gestiona esto como una única transacción compuesta; los sistemas heredados lo gestionan como dos transacciones secuenciales esperando que nada falle entre ellas.

Por qué esto es importante a nivel comercial

El motor Self-Service requirió aproximadamente seis semanas de trabajo de ingeniería para alcanzar la calidad de producción. Se trata de una inversión enorme para lo que parece una funcionalidad sencilla.

La justificación comercial tras esa inversión fue muy concreta: los adquirentes y operadores del sector de la hostelería corporativa realizan lo que se denomina la diligencia debida de los sistemas de pago durante la evaluación de compra. El CTO preguntará: «¿Qué ocurre cuando se interrumpe la conexión de un huésped durante una comprobación 3DS?». Si la respuesta es «tenemos supervisión», «ocurre raras veces» o «ejecutamos un proceso de conciliación cada noche», la plataforma no supera la evaluación de diligencia debida.

Si la respuesta es «la arquitectura lo impide: aquí está la lógica de derivación de claves de idempotencia y las pruebas de Playwright que lo demuestran», la plataforma supera la prueba.

mDOS la supera. Esa simple frase es lo que da acceso a un segmento de clientes corporativos que jamás habrían considerado la plataforma hace seis meses.

Qué significa para los operadores

Para un operador multilocal que gestiona 200 establecimientos, el motor de autoservicio elimina aproximadamente entre un 3 y un 7 % de las incidencias de atención al cliente relacionadas con los pagos. La cifra exacta varía según el tipo de local y el perfil del cliente, pero el patrón es constante: todos los operadores analizados en comparación con la infraestructura heredada reportan cobros duplicados como un problema recurrente.

Eliminar ese 3-7 % genera un efecto multiplicador. Se reducen las horas de atención al cliente, disminuyen las tasas de contracargo y disminuye la carga de conciliación contable vinculada a reembolsos. La confianza de los clientes mejora de forma cuantificable, especialmente entre los huéspedes de mayor gasto, quienes suelen utilizar más las funciones de modificación en autoservicio. El ROI operativo del motor de autoservicio en un grupo a gran escala es lo suficientemente significativo como para constituir una partida presupuestaria propia.

Para una entidad adquiriente que evalúe mDOS como propiedad intelectual, el motor de autoservicio indica algo distinto: demuestra que el equipo de ingeniería optó por resolver problemas complejos correctamente en lugar de realizar lanzamientos rápidos acumulando deuda técnica. Esto es exactamente lo que busca la debida diligencia técnica de los compradores: no la cantidad de funciones, sino pruebas de madurez arquitectónica en las partes menos vistosas del sistema.

El patrón arquitectónico en un párrafo

Cada modificación se origina como una intención del cliente. Dicha intención se procesa mediante un algoritmo hash para generar una clave de idempotencia determinista. La clave se contrasta con una tabla de solicitudes recientes. Si la clave coincide con una solicitud correcta reciente, el sistema devuelve la respuesta original. Si la clave no coincide, el sistema inicia una transacción que procesa el ajuste financiero (cobro, reembolso o compuesto), la actualización de la reserva y la distribución de activadores (trigger fan-out) como una única operación atómica. Si falla algún paso, se revierte la transacción completa. Si el cliente reintenta la misma intención dentro de la ventana de idempotencia, recibe la respuesta correcta original, incluso si su conexión cayó en el peor momento posible.

Este patrón está ampliamente documentado en la literatura de ingeniería de pagos. Stripe lo recomienda directamente. Sin embargo, está prácticamente ausente en las soluciones SaaS para hostelería, ya que implementarlo correctamente requiere una disciplina transaccional entre sistemas que las arquitecturas fragmentadas sencillamente no pueden ofrecer.

mDOS puede ofrecerlo porque cada paso del flujo de modificación reside en la misma base de datos Postgres. El cálculo del ajuste financiero, la actualización de la reserva, el ajuste de fidelización y la distribución de activadores forman parte de la misma transacción. La atomicidad no es una función; es una propiedad inherente a la arquitectura unificada.

Qué preguntar a su plataforma actual

Si gestiona una operación hostelera multilocal, estas tres preguntas le permitirán evaluar si su infraestructura está preparada para este tipo de desafíos.

¿Cómo gestiona su plataforma actual a un cliente que pulsa «modificar» dos veces durante una verificación 3DS con conectividad intermitente? Si la respuesta sincera implica supervisión, conciliación manual o la intervención de atención al cliente, está asumiendo un coste operativo que la propia arquitectura debería eliminar.

¿Qué porcentaje de sus incidencias mensuales de atención al cliente se debe a cobros duplicados, reembolsos no procesados o discrepancias de facturación tras una modificación? La mayoría de los operadores no han medido esto porque lo han asumido como un problema inevitable.

¿Qué hace su plataforma cuando un cobro fuera de sesión almacenado activa una comprobación 3DS imprevista? Si la respuesta es «el cobro falla y tenemos que pedir al cliente que vuelva a pasar por el proceso de pago habitual», tiene un problema significativo de tasa de conversión en cada flujo de modificación.

Estas preguntas no giran en torno a funciones secundarias. Tratan sobre si la ingeniería de pagos de su plataforma posee la madurez suficiente para dar soporte a nivel corporativo.

---

El motor de autoservicio se lanzó a producción en mayo de 2026. Documentación técnica disponible bajo acuerdo de confidencialidad mutuo para evaluaciones en curso.