Cómo conectar Hotelgest con Redsys para cobros seguros

En lugar de comprobar cada cobro y actualizar la reserva a mano, prepara un flujo que vincule el pago con su reserva y valide la respuesta de la pasarela. Para conectar Hotelgest con Redsys en 2026, confirma primero el conector disponible para tu cuenta, configura el TPV correspondiente y verifica la confirmación del pago antes de activar cobros reales.

TL;DR

• Para conectar Hotelgest con Redsys, confirma primero la compatibilidad del conector con tu TPV virtual.
• Redsys debe confirmar el resultado del pago; regresar al motor de reservas no demuestra que esté autorizado.
• Separa pruebas y producción: cada entorno necesita su configuración y sus credenciales correspondientes.
• No actives cobros hasta comprobar autorizaciones, rechazos y pagos interrumpidos sobre reservas identificables.

Por qué importa la confirmación del pago

Una reserva creada, una operación autorizada y un abono bancario son hechos distintos. Si recepción los trata como equivalentes, pierde la trazabilidad del dinero pendiente y del dinero cobrado.

[Hotelgest](/) es un PMS para hoteles y apartamentos en España que necesitan centralizar reservas y check-in. La conexión de pagos debe conservar esa trazabilidad: cada operación necesita una reserva identificable, un resultado verificable y un tratamiento claro cuando algo falla.

El criterio de puesta en marcha en 2026 es concreto: no marques una reserva como pagada únicamente porque el huésped vuelva a tu web. La página de retorno informa al usuario; la confirmación válida de la operación determina el resultado del cobro.

Antes de empezar

• Accesos y responsables. Prepara una cuenta con permisos de configuración del PMS, acceso autorizado al TPV virtual y un interlocutor de la entidad bancaria. Confirma con el soporte de Hotelgest el procedimiento admitido para tu cuenta antes de introducir credenciales o contratar desarrollos.
• Datos del comercio y política de cobro. Reúne el código de comercio, el terminal, la moneda y la clave de firma del entorno correspondiente. Define también cuándo solicitas el pago y cómo identificas la reserva. Comparte secretos únicamente mediante el canal seguro acordado para la configuración.
• El bloqueo menos evidente. El retorno del navegador y la notificación del resultado no son lo mismo. Confirma quién configura la recepción y validación de esa notificación; una dirección protegida por acceso privado o una configuración incorrecta rompe la actualización aunque el huésped vea una pantalla de éxito.

No sustituyas esta preparación por una transacción real improvisada. Primero delimita quién gestiona el TPV, quién configura el conector y quién revisa las incidencias; después ejecuta las pruebas.

Configuración del comercio y del entorno

Identifica el TPV que utilizará el alojamiento

1. Confirma el alcance del conector. Solicita el procedimiento de activación aplicable a tu cuenta y verifica qué flujo admite: pago asociado a una reserva, motor de reservas u otra modalidad expresamente confirmada. No des por incluidos enlaces de pago, devoluciones o cargos posteriores.
2. Reúne los identificadores. Contrasta el código de comercio y el terminal con los datos facilitados por tu banco. En la integración técnica de Redsys, los parámetros correspondientes incluyen Ds_Merchant_MerchantCode y Ds_Merchant_Terminal; no los confundas con el identificador interno del alojamiento.
3. Separa los entornos. Utiliza los datos de pruebas para probar y los de producción para operar. Verifica que dirección de conexión, clave de firma y terminal pertenecen al mismo entorno antes de guardar la configuración por el procedimiento autorizado.

Resultado esperado: tienes un comercio y un terminal identificados, un entorno definido y un responsable de cada parte de la conexión. Todavía no has habilitado cobros para huéspedes.

En una operación multipropiedad, documenta además qué establecimiento corresponde a cada configuración. Si varios alojamientos comparten titularidad, no deduzcas por ello que deben compartir terminal: acuerda la estructura con la entidad bancaria y el responsable contable.

Para la puesta en marcha de 2026, deja constancia de la fecha de revisión y de la persona que aprobó los datos. Conserva los identificadores operativos, pero no pegues la clave de firma en hojas compartidas, correos generales ni capturas de pantalla.

Configuración de la reserva y la solicitud de pago

Define qué se cobra y cómo se identifica

1. Elige el momento del cobro. Decide si el huésped paga durante la reserva o mediante un proceso posterior admitido por la integración. Explica la condición antes de solicitar el pago y alinéala con las condiciones de la reserva.
2. Vincula la operación con la reserva. Comprueba que el identificador enviado permite localizar tanto la reserva como el intento de pago. El parámetro Ds_Merchant_Order identifica el pedido en Redsys; su generación debe respetar las reglas de la pasarela y evitar colisiones entre operaciones.
3. Verifica importe y moneda. Revisa la correspondencia entre el saldo exigible, la cantidad enviada y la moneda configurada. En una integración técnica, Ds_Merchant_Amount y Ds_Merchant_Currency forman parte de esa comprobación; deja su formato al conector validado, no a una transcripción manual improvisada.

Resultado esperado: puedes explicar qué concepto se solicita, qué reserva lo origina y cómo localizar cada intento sin recurrir al nombre del huésped como única referencia.

Para diseñar el recorrido desde la selección de estancia hasta el pago, consulta la guía sobre aceptar pagos con tarjeta en el motor de reservas. Mantén una distinción operativa: crear una reserva no acredita que el pago haya terminado.

Si el cliente abandona el proceso y vuelve a intentarlo, conserva la relación entre ambos intentos y la reserva. Una reserva puede tener varios intentos, pero cada cobro autorizado debe quedar identificado por separado. Así evitas interpretar un reintento como un nuevo saldo pendiente.

Configuración de la respuesta y la conciliación

Valida el resultado antes de actualizar el saldo

1. Confirma la recepción del resultado. Verifica con el responsable técnico el mecanismo de notificación utilizado por el conector. En la integración por redirección de Redsys, Ds_Merchant_MerchantURL identifica el destino de la notificación; no debe confundirse con las direcciones de retorno del navegador.
2. Exige validación de la respuesta. Comprueba que el conector valida la firma y contrasta pedido, importe, moneda y resultado antes de aplicar cambios. No implementes una actualización de saldo basada únicamente en parámetros visibles en la dirección del navegador.
3. Controla las repeticiones. Exige que recibir de nuevo la misma notificación no vuelva a contabilizar el cobro. Comprueba también que un resultado tardío no borre una operación posterior ni convierta un rechazo en una autorización.

Resultado esperado: una respuesta válida actualiza una sola vez la operación correspondiente, mientras que una respuesta incorrecta queda sin aplicar y disponible para revisión.

En la conciliación de 2026, separa 2 registros: la operación de la pasarela y el movimiento asociado a la reserva. Ambos deben coincidir en referencia, importe, moneda y resultado; el extracto bancario sirve después para revisar el abono efectivo.

El flujo de validación sigue este orden. La confirmación tiene que llegar a la reserva correcta antes de que recepción dé el saldo por satisfecho.

La actualización del saldo viene después de validar la respuesta del pago.

Registro mínimo para resolver incidencias

Conserva la referencia de reserva, la referencia de operación, la fecha, el resultado y el importe necesario para conciliar. Limita el acceso a quienes deban resolver la incidencia y evita incluir datos completos de tarjeta en notas, mensajes o registros técnicos.

La clave de firma no es un dato de atención al cliente. Si necesitas escalar una incidencia, comparte referencias y resultados por el canal autorizado, no credenciales ni capturas que las expongan.

Pruebas y activación del cobro

Comprueba el recorrido completo

1. Prepara una reserva de prueba. Crea 1 reserva de prueba reconocible y sigue el proceso como huésped. Utiliza exclusivamente los medios de prueba indicados por la entidad o por la documentación técnica aplicable al entorno.
2. Ejecuta los escenarios básicos. Completa al menos 3 pruebas funcionales: pago autorizado, pago rechazado y abandono antes de terminar. Añade la recepción repetida de una misma notificación como comprobación técnica independiente.
3. Contrasta ambos extremos. Compara lo registrado en el TPV con el estado de la reserva después de cada escenario. Verifica también qué mensaje recibe el huésped y qué información tiene recepción para actuar sin repetir el cargo.
4. Autoriza el paso a producción. Cambia al conjunto de configuración de producción mediante el procedimiento confirmado. Acuerda con el banco y el soporte la validación final, revisa el primer cobro autorizado y documenta cómo suspender nuevas solicitudes si aparece una discrepancia.

Resultado esperado: puedes distinguir autorización, rechazo y abandono sin ambigüedad, y ningún escenario genera un saldo pagado sin respaldo de la pasarela.

La prueba de aceptación de 2026 debe incluir el regreso incompleto del navegador. Cierra la página después de finalizar el pago en el entorno de pruebas y comprueba el resultado mediante la notificación válida, no mediante lo que quedó visible en pantalla.

No actives el flujo si la pasarela y la reserva discrepan. Resolver esa diferencia antes de abrir el cobro evita que recepción tenga que decidir a ciegas entre reclamar un pago o darlo por recibido.

Variante: solicitar el saldo después de una modificación

El cobro inicial y el cobro tras un cambio de estancia necesitan reglas distintas. Aplica esta variante únicamente cuando el conector y tu operativa admitan solicitar un nuevo pago asociado a una reserva existente.

Antes de emitir la nueva solicitud, recalcula el saldo y conserva los cobros anteriores. Identifica el cambio que origina la diferencia y comunica al huésped el concepto correspondiente.

Una modificación de reserva no autoriza por sí sola un cargo en tarjeta. No conviertas un cambio de fechas en un cobro desatendido sin un mecanismo admitido y la autorización que corresponda. Si el nuevo saldo requiere intervención del huésped, dirige el proceso hacia esa confirmación.

Problemas habituales y cómo corregirlos

• El huésped ve éxito, pero la reserva sigue pendiente. Localiza primero la operación en el TPV. Revisa después la recepción de la notificación, su validación y la referencia de reserva; no solicites otro pago hasta aclarar el primero.
• La firma no se valida. Comprueba que clave, entorno y configuración corresponden entre sí. Escala la revisión de firma al responsable técnico y evita modificar manualmente el contenido firmado durante el diagnóstico.
• La operación se rechaza. Consulta el código y su significado en la documentación vigente de la entidad. No atribuyas automáticamente el rechazo a falta de fondos ni conviertas todos los errores en instrucciones de reintento.
• El cobro aparece duplicado en la reserva. Distingue entre dos operaciones bancarias y una notificación procesada dos veces. Corrige el registro o tramita la operación que corresponda según el caso; no ordenes una devolución sin identificar el movimiento real.
• El pago pertenece a otro alojamiento. Revisa la asociación entre establecimiento, comercio y terminal. Detén nuevas solicitudes del flujo afectado hasta corregir el mapeo y conciliar las operaciones existentes.

Amplía el flujo sin perder trazabilidad

Cuando el cobro inicial funciona, extiende el mismo control a anticipos, saldos pendientes y devoluciones expresamente admitidas. Define para cada proceso quién lo inicia, qué autorización necesita y qué registro demuestra su resultado.

Revisa también los permisos. Quien consulta una reserva no necesita necesariamente modificar credenciales o tramitar devoluciones; asigna funciones según la responsabilidad y conserva un procedimiento de escalado.

En tu revisión operativa de 2026, incluye un caso real conciliado de principio a fin: reserva, solicitud, respuesta, saldo y abono bancario. Automatiza solo lo que puedas reconstruir después con referencias verificables.

Un último detalle

Un pago rechazado bien registrado es una prueba de integración tan necesaria como un pago autorizado. Si recepción identifica qué ocurrió, qué saldo queda y qué acción corresponde, el flujo está preparado para gestionar incidencias, no solo para mostrar una pantalla de éxito.

Guías relacionadas

• Automatizar el cobro de depósitos en reservas de grupo
• Automatizar reembolsos desde el motor de reservas
• Reducir contracargos con un motor de reservas seguro