Un motor de reservas puede mostrar disponibilidad impecable y, aun así, perder ingresos en el último paso: el pago. El plugin HBook RedSys conecta las reservas creadas en HBook con la pasarela bancaria más habitual en España, para que el cliente pague con tarjeta sin salir de un proceso coherente con tu web.
Para un hotel pequeño, una casa rural, apartamentos turísticos o una agencia que gestiona alojamientos, no se trata solo de añadir otro método de cobro. La integración debe conservar el importe correcto, identificar cada reserva, gestionar el retorno del banco y reflejar el estado final en WordPress. Si una de esas piezas falla, aparecen reservas pendientes, pagos que el equipo no puede comprobar o clientes que abandonan antes de confirmar.
Qué resuelve un plugin HBook RedSys
HBook está orientado a la gestión de reservas de alojamiento: calendarios, tarifas, disponibilidad, extras, formularios y confirmaciones. RedSys, por su parte, procesa el pago mediante la entidad bancaria. El plugin actúa como la capa de conexión entre ambos sistemas.
Cuando el huésped completa el formulario de reserva y elige pagar con tarjeta, HBook prepara la información de la operación. La extensión la envía a RedSys con los datos necesarios, como el importe, el identificador del pedido y las URLs de respuesta. Tras autorizar o rechazar el pago, RedSys devuelve el resultado para que la reserva pueda pasar al estado que corresponda.
Esta lógica parece sencilla, pero evita una alternativa mucho más frágil: pedir al cliente una transferencia, revisar capturas de pantalla o confirmar manualmente cada pago. También reduce la diferencia entre lo que ve el usuario en la reserva y lo que recibe el banco en la operación.
Antes de configurar RedSys en HBook
La mayor parte de las incidencias no empieza en WordPress. Empieza con una contratación bancaria incompleta o con credenciales copiadas desde el entorno equivocado. Antes de instalar y activar el método de pago, conviene tener disponibles los datos facilitados por la entidad.
Normalmente necesitarás el código de comercio, el número de terminal, la clave secreta de firma y el entorno de trabajo. RedSys suele ofrecer un entorno de pruebas y otro de producción. Las credenciales no son intercambiables: una clave de pruebas no funcionará en producción, y viceversa.
También debes definir qué importe se cobrará desde la reserva. Algunos negocios cobran el total; otros solicitan un depósito o una señal. HBook debe tener esa política configurada con claridad antes de activar la pasarela. Si el importe visible en el formulario no coincide con el importe enviado a RedSys, el problema no es de diseño: es una fricción directa en la venta y una fuente de consultas para recepción.
Por último, comprueba que tu sitio usa HTTPS válido. Un flujo de pago con redirecciones, retorno del cliente y notificaciones del banco requiere un dominio accesible públicamente y sin bloqueos de seguridad que impidan la comunicación entre servidores.
Configuración del plugin HBook RedSys paso a paso
El orden de configuración importa. Instalar una extensión antes de revisar la política de precios o el estado de las reservas puede complicar las pruebas. Un proceso ordenado permite localizar cualquier error sin tocar ajustes al azar.
1. Revisa la reserva base en HBook
Crea una reserva de prueba dentro de HBook y verifica el cálculo de noches, ocupación, extras, impuestos y descuentos. El precio que genera HBook es el que llegará a la pasarela. Si hay una tarifa errónea antes del pago, RedSys no podrá corregirla.
Decide también qué estado debe tener una reserva recién creada y qué estado recibirá tras un cobro correcto. En alojamientos con disponibilidad limitada, dejar una reserva como confirmada antes de recibir la respuesta válida del banco puede bloquear fechas sin garantía de pago.
2. Introduce los datos del comercio
En la sección de configuración de pagos de HBook, activa RedSys e introduce los valores proporcionados por tu banco. Respeta el formato indicado para cada campo. Un terminal añadido con un cero menos, una moneda mal definida o una clave de firma copiada con espacios puede provocar errores de validación difíciles de interpretar desde el frontal.
La clave secreta merece especial atención. No debe mostrarse en mensajes, capturas, correos ni documentación pública. Es un dato de seguridad que permite firmar las operaciones. Si sospechas que ha sido expuesta, solicita al banco su renovación.
3. Configura las URLs de retorno y notificación
RedSys trabaja con respuestas que permiten comunicar el resultado del pago. El cliente necesita volver a una página comprensible de tu web después de pagar, tanto si la operación se aprueba como si se cancela. Pero el retorno del navegador no es suficiente para confirmar una reserva.
La notificación servidor a servidor es la pieza que permite actualizar el estado incluso si el cliente cierra la pestaña al terminar el pago. Esta diferencia es clave: una reserva puede haberse cobrado aunque el usuario no llegue a la página de agradecimiento. La configuración debe contemplar ese escenario.
4. Prueba operaciones reales en el entorno de pruebas
Antes de abrir el método de pago al público, realiza varios casos: una autorización correcta, una cancelación desde la pantalla bancaria y un pago rechazado. Revisa qué estado toma cada reserva y qué mensaje recibe el cliente.
No basta con comprobar que aparece la pantalla de RedSys. Hay que comprobar la vuelta a WordPress, el registro de la operación y la actualización del pedido. Si trabajas para un cliente, documenta estas pruebas y pide una validación funcional antes de pasar a producción.
5. Cambia a producción y valida de nuevo
Al cambiar las credenciales de pruebas por las reales, realiza una operación de importe reducido con una tarjeta real, siguiendo el procedimiento autorizado por el comercio. Confirma la operación en el panel bancario y en HBook. Esta revisión final detecta diferencias entre ambos entornos, especialmente en URLs, terminales y firmas.
Errores habituales y cómo prevenirlos
El error más común es asumir que una redirección correcta equivale a un pago confirmado. El cliente puede regresar a la web por distintos motivos, pero la confirmación fiable depende de la respuesta firmada de RedSys y de su validación por el plugin.
También son frecuentes los problemas con cachés agresivas o reglas de seguridad. Algunos sistemas de caché guardan páginas que deberían responder de forma dinámica; determinados firewalls bloquean las peticiones entrantes del banco. Si las reservas se quedan pendientes pese a que el cargo aparece autorizado, revisa primero los registros de WordPress, las reglas de seguridad y la URL de notificación.
Otra incidencia habitual está relacionada con el idioma y los mensajes de error. El banco puede rechazar una operación por límites de la tarjeta, autenticación del titular o una cancelación voluntaria. El texto mostrado al cliente debe ser claro: indicar que el pago no se ha completado, conservar la reserva según tu política y ofrecer una acción concreta para reintentar o contactar con el alojamiento.
No conviene ocultar todos los detalles bajo un mensaje genérico. El usuario no necesita ver códigos técnicos, pero el administrador sí debe contar con registros suficientes para identificar la reserva, el resultado devuelto y el momento en que ocurrió.
Qué valorar al elegir una integración
No todas las extensiones de RedSys para WordPress sirven para HBook. Una pasarela desarrollada para WooCommerce no resuelve automáticamente el flujo de reservas, los estados propios de HBook ni los datos que utiliza su formulario. La compatibilidad específica evita desarrollos improvisados y reduce el mantenimiento posterior.
Valora que el plugin soporte la versión de HBook que utilizas, que gestione correctamente el entorno de pruebas y producción, y que valide la firma de las notificaciones. También importa la calidad del soporte cuando intervienen tres partes: WordPress, el proveedor de reservas y la entidad bancaria.
En proyectos con requisitos poco habituales, como depósitos variables por temporada, reservas para varios alojamientos o lógica de confirmación interna, quizá necesites adaptar el flujo. En esos casos, una solución especializada como las integraciones de Codection permite partir de una base compatible y valorar un desarrollo a medida cuando la operativa lo justifica.
Una pasarela de pago también forma parte de la experiencia de reserva
El cliente no separa el calendario, el formulario y el pago en sistemas distintos. Para él, todo es una única reserva. Por eso, una configuración correcta del plugin HBook RedSys debe mantener importes transparentes, mensajes comprensibles y estados fiables para el equipo que gestiona las entradas.
Antes de publicar la pasarela, repite una reserva completa desde móvil y ordenador, con distintos escenarios de pago. Diez minutos de prueba antes de una campaña o de la temporada alta pueden evitar horas de conciliación manual cuando las reservas ya están entrando.