Una reserva confirmada sin un cobro asociado deja margen para cancelaciones, trabajo administrativo y errores de disponibilidad. Por eso, saber cómo instalar pasarela en WPBookingCalendar no consiste solo en activar un plugin: implica conectar el calendario, el banco y el flujo de reserva para que cada estado tenga sentido operativo.
En proyectos de alojamientos, alquileres, actividades o servicios con cita previa, la pasarela debe responder a una pregunta sencilla: ¿cuándo queda bloqueada una fecha y bajo qué condición se confirma el pago? La respuesta depende de la configuración de WPBookingCalendar, del banco y del tipo de integración que se utilice.
El primer requisito es disponer de una instalación funcional de WordPress y WPBookingCalendar, con el proceso de reserva ya revisado. Antes de añadir un método de pago, haga una reserva de prueba sin cobrar y compruebe qué datos solicita el formulario, qué correo recibe el cliente y cómo cambia la disponibilidad en el calendario.
También necesita una cuenta de comercio electrónico contratada con su banco si va a operar con RedSys o Ceca. El banco debe facilitar las credenciales necesarias para el entorno de pruebas y, después, las de producción. Según la entidad y el tipo de integración, estas pueden incluir un número de comercio, terminal, clave secreta o firma, además de las direcciones de retorno que el banco debe reconocer.
No use las credenciales de producción mientras aún está validando el flujo. Un pago real realizado durante una prueba puede generar una reserva que parezca correcta en WordPress, pero deje registros incompletos si el retorno o la notificación no están configurados.
Por último, confirme que su sitio utiliza HTTPS y que WordPress puede recibir solicitudes externas. Una pasarela bancaria necesita que el banco vuelva al sitio para informar del resultado de la operación. Si el servidor bloquea esas peticiones, la reserva puede quedarse pendiente aunque el cliente vea el pago aprobado en su banco.
WPBookingCalendar no debe confundirse con otros plugins de reservas de WordPress con nombres similares. Antes de comprar o instalar una extensión, revise la compatibilidad exacta con el plugin, su versión y el sistema de pagos que desea usar. Una pasarela pensada para WooCommerce, por ejemplo, no añade por sí sola un cobro directo al flujo de WPBookingCalendar.
La opción adecuada depende de cómo facture el negocio. Si cobra el total al reservar, la integración debe confirmar el pago antes de cerrar la reserva. Si solicita una señal, debe poder enviar el importe parcial correcto. Y si el cliente paga al llegar, quizá solo necesite registrar la reserva sin redirigir a una pasarela.
Para comercios españoles, RedSys y Ceca suelen ser la elección natural cuando se trabaja directamente con el banco. Bizum puede estar disponible dentro de la operativa contratada, pero su activación y el comportamiento de la pantalla de pago dependen de la entidad bancaria y del producto que tenga habilitado el comercio. No conviene asumir que un método estará activo solo por tener una cuenta de RedSys.
Codection desarrolla extensiones específicas para entornos de reservas y pasarelas bancarias, una alternativa útil cuando el proyecto necesita una compatibilidad directa en lugar de adaptar soluciones genéricas.
El proceso exacto cambia entre versiones y extensiones, pero la secuencia técnica es muy parecida. El objetivo es instalar el addon, introducir los datos bancarios, vincularlo al flujo de reservas y probar cada respuesta posible.
Descargue el archivo ZIP de la extensión desde la fuente correspondiente. En el escritorio de WordPress, vaya a Plugins, seleccione Añadir nuevo y use la opción para subir un plugin. Elija el archivo ZIP, instálelo y actívelo.
Después, compruebe que el addon aparece en el apartado de pagos, reservas o ajustes de WPBookingCalendar. Si no aparece, revise primero los requisitos de versión. Desactivar y volver a activar el plugin principal puede ayudar tras una actualización, pero no sustituye una incompatibilidad real entre versiones.
Evite editar archivos del plugin para añadir credenciales o modificar rutas de retorno. Esos cambios se perderán al actualizar y pueden comprometer claves bancarias. Una integración bien implementada debe ofrecer campos de configuración dentro de WordPress o usar constantes definidas de forma controlada.
Active el modo de prueba si la pasarela lo ofrece e introduzca las credenciales facilitadas por el banco para ese entorno. No mezcle datos de prueba con valores de producción: un terminal de pruebas con una clave de producción no genera una configuración válida.
En esta pantalla normalmente deberá definir la moneda, el idioma, el importe que se enviará a cobrar y el estado inicial de la reserva. Revise especialmente si el addon trabaja con importes con impuestos incluidos, descuentos, extras o depósitos. Un desajuste de un céntimo puede provocar rechazos en algunas configuraciones bancarias cuando la firma no coincide con el importe enviado.
La URL de notificación es crítica. La URL de retorno lleva al cliente de vuelta a la web tras pagar. La notificación, en cambio, es la comunicación entre el banco y su sitio. La reserva debe actualizarse al recibir la notificación validada, no solo porque el navegador del usuario aterrice en una página de gracias.
Antes de cobrar, decida qué significa cada estado para su negocio. Una estructura habitual es crear la reserva como pendiente, enviarla a pago y confirmarla solo al recibir una respuesta autorizada y verificada. Si el pago falla o se cancela, la reserva puede mantenerse pendiente durante un periodo limitado o liberarse automáticamente, según la política de disponibilidad.
Aquí hay un equilibrio que conviene definir con cuidado. Bloquear la fecha desde el primer paso evita sobreventas mientras el cliente paga, pero puede retener inventario si abandona la operación. Liberarla demasiado rápido puede provocar que dos personas intenten reservar el mismo periodo. Configure tiempos de expiración razonables y comuníquelos en el proceso de reserva.
Compruebe también qué ocurre con los correos. El cliente no debería recibir el mismo mensaje para una reserva pendiente que para una pagada. El administrador, por su parte, necesita identificar rápidamente si debe intervenir o si el banco ya confirmó el cobro.
Algunas entidades permiten configurar las direcciones de notificación desde su panel; otras solicitan que se comuniquen durante el alta. Copie la URL que indique el addon y respete el protocolo HTTPS, el dominio y la ruta exacta.
No redirija la URL de notificación a una página pública ni la proteja con una contraseña adicional. Tampoco aplique reglas que transformen parámetros o eliminen solicitudes POST. Los plugins de seguridad, firewalls de alojamiento y reglas de caché pueden interferir con la respuesta del banco si no se han revisado.
Una sola operación autorizada no valida la instalación. Pruebe el proceso desde el calendario hasta el correo final y revise el registro de la reserva en el panel de administración. El importe, las fechas, el identificador de operación y el estado deben coincidir.
Conviene simular al menos cuatro escenarios distintos:
El cuarto caso revela por qué la notificación servidor a servidor es necesaria. Aunque el usuario no vuelva a su sitio, la reserva debe quedar confirmada si el banco autorizó el cargo y envió una notificación válida.
El error más común es una firma inválida. Suele deberse a una clave secreta incorrecta, un terminal equivocado, una codificación distinta a la esperada o una modificación del importe entre el momento de firmar la operación y el de enviarla. Copie los valores con cuidado y no añada espacios al principio o al final.
También son frecuentes los problemas de caché. Si una página de pago, retorno o confirmación se sirve desde una caché agresiva, el cliente puede ver información antigua o el sistema puede procesar mal la sesión de reserva. Excluya las páginas críticas del caché y pruebe el flujo en una ventana privada.
Otro punto delicado es la actualización. Actualizar WordPress, WPBookingCalendar o la pasarela sin probar puede alterar plantillas, hooks o requisitos de PHP. Mantenga copias de seguridad y valide el pago en un entorno de pruebas tras actualizaciones relevantes. En sitios con alto volumen de reservas, esta práctica evita descubrir una incompatibilidad con clientes reales.
Si el pago se aprueba en el banco pero la reserva no cambia de estado, no trate el problema como un simple fallo del calendario. Hay que revisar la notificación, los logs de WordPress, las respuestas del servidor y la validación de firma. Si el calendario bloquea fechas duplicadas, calcula depósitos complejos o se conecta con un sistema externo, el diagnóstico debe considerar todo el flujo.
Una revisión profesional también tiene sentido cuando necesita adaptar importes, crear reglas por temporada, cobrar extras o integrar un proceso de confirmación propio. En estos casos, forzar cambios sobre una extensión estándar puede salir más caro que desarrollar una adaptación mantenible.
El mejor momento para comprobar una pasarela no es cuando llega la primera reserva pagada. Es antes de publicar el calendario, con pruebas reales de cada respuesta posible y una política clara sobre cuándo una fecha pasa de disponible a confirmada.
Nota: Hay una valoración incrustada en esta entrada, por favor, visita esta entrada para valorarla.
Hoy vengo a hablaros de un plugin libre que tenemos publicado en el repositorio y…
Encuentra el mejor plugin de pagos para formularios WordPress según tu formulario, pasarela y tipo…
Aprende a implementar pagos recurrentes en formularios WordPress: suscripciones, tokenización, avisos y control operativo de…
Aprende a instalar Bizum en Gravity Forms, configurar la pasarela bancaria y comprobar pagos, notificaciones…
¿Ceca o RedSys para ecommerce? Compara integración, operativa, costos y compatibilidad con WooCommerce para elegir…
La instalación profesional de pasarelas WordPress asegura cobros fiables con RedSys, Ceca o Bizum, configuración…