Una reserva de viaje no termina cuando el cliente pulsa «Reservar». Hasta que el pago queda autorizado, registrado y asociado a la reserva correcta, el proceso sigue abierto. Esta guía pagos para Tourmaster está pensada para agencias, operadores turísticos y desarrolladores WordPress que necesitan cobrar con una pasarela bancaria, sin convertir la gestión diaria de reservas en una revisión manual constante.
Tourmaster permite vender tours, actividades, alojamientos y otros servicios turísticos desde WordPress. Pero la experiencia de reserva depende de un punto especialmente sensible: que el cliente reciba una confirmación fiable y que el administrador pueda distinguir entre una solicitud pendiente, un pago fallido y una reserva realmente cobrada. La integración de RedSys, Bizum o Ceca debe configurarse teniendo en cuenta ese flujo completo, no solo el formulario de pago.
Qué debe resolver una pasarela de pago en Tourmaster
El objetivo no es simplemente mostrar un botón de pago. Una integración correcta debe enviar al banco el importe exacto, recibir la respuesta de la operación y actualizar el estado de la reserva en Tourmaster. Si alguno de estos pasos falla, pueden aparecer reservas confirmadas sin cobro, pagos recibidos sin localizador claro o clientes que repiten el intento porque no han visto una confirmación válida.
En un negocio turístico, estos errores tienen un coste operativo alto. Una plaza bloqueada por una reserva pendiente puede impedir una venta posterior. A la inversa, liberar una plaza cuando el banco sí ha cobrado genera incidencias difíciles de gestionar. Por eso conviene tratar la pasarela como parte del sistema de reservas, no como un elemento aislado del checkout.
También hay que definir qué se vende y cómo se cobra. Un tour de precio fijo admite un flujo sencillo, mientras que una actividad con extras, fechas variables, suplementos por persona o depósitos parciales requiere revisar con más detalle cómo Tourmaster calcula el total antes de enviarlo a la entidad bancaria.
Antes de configurar pagos en Tourmaster
Antes de instalar o activar una extensión, revise la operativa de venta. Esta fase evita muchos problemas que después se atribuyen, erróneamente, al banco o al plugin.
Primero, confirme la moneda de la web y la moneda contratada en el terminal virtual. RedSys y Ceca esperan recibir importes coherentes con la configuración del comercio. Si la web trabaja en euros, los precios, impuestos, descuentos y gastos adicionales deben llegar a la pasarela como un total final correctamente calculado. Un redondeo inesperado o una conversión de moneda aplicada en un punto distinto del proceso puede hacer que el importe mostrado al cliente no coincida con el enviado al banco.
Después, defina los estados de reserva que utilizará el equipo. Lo recomendable es mantener una reserva como pendiente mientras el cliente aún no ha completado el pago y pasarla a confirmada únicamente tras una respuesta válida de la pasarela. No conviene asumir que una redirección del navegador es una confirmación definitiva: el visitante puede cerrar la pestaña, perder conexión o volver atrás justo después de autorizar el pago.
Por último, solicite a su banco los datos completos del terminal. Según la entidad y la pasarela, normalmente necesitará un identificador de comercio, número de terminal, clave o secreto de firma, entorno de pruebas y entorno de producción. Guarde estos datos fuera de capturas, correos reenviados o documentos públicos. Una clave de firma es un dato operativo sensible.
Configuración de RedSys, Bizum o Ceca paso a paso
La implementación exacta depende de la extensión elegida, pero el orden de trabajo debería ser siempre el mismo.
1. Instale una pasarela compatible con Tourmaster
Verifique que la solución indique de forma expresa su compatibilidad con la versión de Tourmaster que utiliza. Una pasarela creada para WooCommerce, por ejemplo, no resolverá por sí sola el pago de una reserva gestionada directamente por Tourmaster. La compatibilidad debe cubrir la creación de la orden, la redirección al banco, la notificación de respuesta y la actualización del estado de la reserva.
Codection desarrolla integraciones específicas para Tourmaster orientadas a conectar este flujo con pasarelas como RedSys, Bizum y Ceca. En proyectos con requisitos particulares, como pagos parciales, campos adicionales o lógica propia de confirmación, también puede ser necesario adaptar el desarrollo al proceso real del negocio.
2. Active el entorno de pruebas
Configure primero las credenciales de pruebas facilitadas por el banco. No publique la pasarela en producción hasta completar transacciones de test correctamente. El modo de pruebas permite comprobar tanto la operación aprobada como los escenarios de cancelación y error, sin afectar a clientes reales.
Introduzca los datos respetando el formato que exige cada entidad. Un terminal, una clave o un código de comercio mal copiados suelen producir errores de firma o rechazos inmediatos. Si el plugin ofrece un campo para seleccionar el entorno, asegúrese de que las credenciales y la URL de operación pertenecen al mismo entorno. Mezclar datos de pruebas con un endpoint de producción es una causa frecuente de fallos.
3. Configure la URL de notificación
La notificación del servidor es una pieza crítica. Es el aviso que la pasarela envía a su sitio para comunicar el resultado de la transacción, incluso cuando el cliente no regresa a la página de agradecimiento.
Compruebe que la URL indicada por el plugin sea accesible desde Internet, use HTTPS válido y no esté bloqueada por reglas de seguridad, mantenimiento, autenticación o plugins de caché. Si utiliza un firewall, una CDN o una capa de seguridad administrada, revise sus registros durante las pruebas. La entidad bancaria debe poder llegar a esa ruta sin depender de la sesión del navegador del cliente.
4. Ajuste métodos, idiomas y mensajes
RedSys puede incluir tarjeta y, según el contrato bancario, Bizum u otros métodos habilitados en el terminal. Bizum no se activa solo por instalar una extensión: debe estar contratado y disponible en la configuración del banco. Ceca sigue una lógica similar, con parámetros propios de su plataforma.
Muestre un nombre claro en el checkout, como «Tarjeta o Bizum», solo si ambos métodos están realmente activos. El texto de confirmación también debe informar de forma precisa: la reserva queda confirmada cuando se valida el pago, y el cliente recibirá el detalle por correo. Evite prometer disponibilidad definitiva si su negocio requiere una revisión manual previa.
Pruebas que conviene hacer antes de publicar
Una prueba válida no consiste únicamente en llegar a la pantalla del banco. Debe revisar el ciclo completo desde la reserva hasta el estado final en el panel de WordPress.
Realice, como mínimo, una operación aprobada, una cancelada por el cliente y una rechazada. En cada caso, compruebe el importe, la referencia de reserva, el correo enviado y el estado registrado en Tourmaster. Si vende opciones como adultos, niños, extras o traslados, pruebe combinaciones distintas. Los errores suelen aparecer en los importes compuestos, no en la reserva más simple.
También merece la pena probar qué ocurre si el cliente paga y cierra el navegador sin volver a la web. Si la notificación está bien configurada, la reserva debería actualizarse igualmente. Este escenario es especialmente útil para detectar configuraciones que dependen de la página de retorno en lugar de la respuesta del servidor.
Cuando pase a producción, repita una compra real de importe reducido. Las credenciales, las claves y el comportamiento del terminal pueden ser diferentes entre ambos entornos. Documente el resultado y conserve las referencias de operación para futuras comprobaciones.
Errores frecuentes y cómo identificarlos
Si el banco muestra un error de firma, revise la clave secreta, el algoritmo requerido por la entidad y los datos del terminal. No modifique valores de forma aleatoria: compare la configuración con la documentación de su banco y con los registros disponibles en WordPress.
Si el pago se aprueba pero la reserva permanece pendiente, el problema suele estar en la notificación. Revise que la URL sea pública, que el certificado SSL sea válido y que ningún sistema de seguridad bloquee la petición. Los logs del servidor y del plugin ayudan a saber si la notificación llegó, si la firma se validó y si Tourmaster pudo actualizar la reserva.
Si el importe enviado no coincide con lo que ve el cliente, compruebe el cálculo de impuestos, descuentos, divisa y suplementos. En reservas turísticas, un ajuste aplicado solo en la interfaz puede no estar incluido en el total que procesa la pasarela. Antes de tocar parámetros bancarios, reproduzca el pedido con los mismos participantes, fecha y servicios adicionales.
Seguridad y operación diaria
Mantenga WordPress, Tourmaster, la extensión de pago y PHP actualizados dentro de versiones compatibles. Las actualizaciones no sustituyen las pruebas, pero reducen problemas de seguridad y compatibilidad. Antes de actualizar un sitio que factura reservas, haga copia de seguridad y valide el pago en un entorno de pruebas o en una ventana controlada.
Limite el acceso al panel de administración, utilice HTTPS en todo el sitio y active registros de errores sin exponer información bancaria a usuarios no autorizados. El personal que gestiona reservas debe saber qué estado implica un cobro confirmado y qué hacer ante un pago pendiente. Una regla interna sencilla evita confirmar plazas basándose solo en un correo del cliente o en una captura de pantalla.
La mejor configuración es la que sigue funcionando cuando el cliente cancela, pierde conexión o paga desde el móvil fuera de horario. Si cada reserva queda asociada a una respuesta verificable de la pasarela, el equipo puede dedicar menos tiempo a comprobar cobros y más tiempo a atender el viaje que acaba de vender.