Solo cobramos a los huéspedes cuando hacen el check-in

Nuestros huéspedes no pagarán al reservar.

Pagarán cuando lleguen. Y llegar hasta ahí me costó más de lo que esperaba.

Estamos trabajando en un motor de reservas para una asociación de casas rurales. El huésped elige las fechas, añade la estancia al carrito y paga con la pasarela del banco. Sencillo.

Hasta que te preguntas cuándo tiene que moverse el dinero de verdad.

El programador del plugin de pago que usamos me dio dos opciones. Verificar la tarjeta y al titular, que es lo que suelen usar hoteles y hostales. O bloquear el importe y confirmarlo más tarde, algo más habitual en negocios que venden productos frescos.

Esa misma noche le respondí con el proceso tal como yo lo entendía. El huésped añade la reserva al carrito, paga a través del banco e introduce su tarjeta. El pedido queda «en proceso». Y el día del check-in, el propietario lo marca como «completado», y solo entonces se cobra.

Y le hice la pregunta de la que no estaba seguro: ¿qué importe ve el huésped cuando introduce la tarjeta? ¿El total o cero?

La pantalla que no controlas

A la mañana siguiente me contestó. Lo suyo es la pasarela de pago, no el sistema de reservas: cómo encajan las dos cosas es cosa nuestra. Cuando el pedido se marca como «completado», la confirmación va al banco. Le pedí que me lo confirmara: ¿es ese el momento del cobro? Exacto, me dijo.

En cuanto a la pantalla, depende de cada banco. Si el nuestro no lo deja claro, deberíamos avisar a los huéspedes de que están autorizando el importe, no pagándolo todavía.

Eso es lo que me gusta: la pantalla del banco forma parte de tu producto, aunque no la puedas tocar. Como el camarero de un restaurante que no es tuyo: si es borde, el cliente le echa la culpa igualmente al restaurante.

Por las mismas fechas revisamos el resto: sincronizar la disponibilidad y los extras que dependen de la ocupación. El programador externo que se encarga de esas partes dijo algo muy sincero que se me quedó grabado: sin entender a fondo el negocio, es difícil cubrir todos los casos.

Tenía razón. Y entender el negocio no le tocaba a él. Nos tocaba a nosotros.

No es un simple ajuste

Lo confieso: llegué a esto pensando que los pagos eran un detalle técnico. Eliges una pasarela, la conectas y listo.

Pero no lo son. Cuándo cobras es una decisión de negocio. Determina cómo se siente el huésped al reservar, cuántas cancelaciones acaban en devoluciones y cuánto papeleo tiene el propietario cada semana.

Habría sido fácil dejar que la opción por defecto de un plugin decidiera por nosotros. Las opciones por defecto son muy cómodas. Y precisamente por eso son peligrosas.

Cuándo le cobras a un cliente es una decisión de producto, no un ajuste de pagos.

Así que el orden es este: decide cuándo se mueve el dinero, escribe el proceso en pasos sencillos y solo entonces busca la opción de la pasarela que haga exactamente eso. Un programador externo puede construir las piezas. Pero saber qué casos importan (cancelaciones, extras, huéspedes que no se presentan) tiene que quedarse en manos de quien conoce el negocio.

Hacemos webs para pequeños alojamientos. Sabemos lo que les cuesta una cancelación y lo que se lleva una comisión.

Ese conocimiento es lo único que un freelance no puede presupuestar en horas. Y también es la razón por la que un estudio pequeño como el nuestro puede construir productos. Empezamos con 300 €. Lo que tenemos y otros no es el tiempo que hemos pasado cerca del problema del cliente. Y eso no te lo transfiere ningún inversor.

Un motor de reservas es, sobre todo, código. Lo que hace que valga la pena usarlo es entender el negocio.

Los huéspedes no pagarán al reservar.

Pagarán cuando lleguen, porque así es como funciona de verdad el negocio en el que reservan.

P. D.: La línea más importante de todo ese proceso no era código. Era una pregunta: «¿El total o cero?».