Medios de Pago

Común

En esta pestaña configuramos los emails que se envían al cliente durante el proceso de pago. Estos se pueden redactar en varios idiomas.

Los modelos de email son: 

  • Email Tokenizar tarjeta
  • Email Cobro Reserva
  • Email Verificación 3DS

Email Tokenizar tarjeta

Con esta plantilla enviamos al cliente un enlace para que tokenice su tarjeta.

Email Cobro Reserva

El hotel podrá enviarle un link de pago de una reserva con el importe deseado, y la factura únicamente será generada en el momento en el que el huésped realice el pago, y por lo tanto se da por cobrada también. Hay una opción aparte y es que, en lugar de generar facturas NR, estos pagos se guarden como anticipos.

Para configurar esta nueva característica lo primero que deberemos hacer será, lógicamente, tener activa una de las pasarelas de pago.
A continuación, en el apartado B.8.Medios de pago -> Común, en la parte inferior tenemos la plantilla Email cobro reserva, donde deberemos configurar el asunto y cuerpo de los emails que enviaremos para el pago de las reservas. Es de especial importancia el parámetro #@2@#, que indica el importe a pagar.
Justo encima de las plantillas de los emails tenemos dos parámetros:

  • Añadir anticipo: Si lo tenemos marcado se generará un anticipo al recibir el pago. En caso contrario se generará una factura NR y se dará por pagada.
  • Email incidencias: dirección de email a la cual se enviará un correo electrónico si el pago se ha hecho correctamente con la tarjeta pero ha habido algún problema al meter el pago en el PMS (ya sea anticipo o factura NR+cobro)

Para realizar el envío del email, desde el apartado 1.4. Modificación de reservas tendremos que pinchar en el botón de NR (no importa que queramos que nos genere un anticipo posteriormente). Nos aparecerá un popup donde, si marcamos «enviar por email» enviará el link de pago a la dirección indicada. Si no lo marcamos, seguirá el procedimiento habitual para generar una factura NR de manera manual.

Email Verificación 3DS

Para el proxi PCI. Conexión con Siteminder.

TPV con integración en Smart Seven Stars

Caixabank (Addon Payments)

TPV

La primera sección de la configuración debemos introducir los parámetros que nos facilite la entidad bancaria.

– «Endpoint«: https://hpp.addonpayments.com/pay
– «Merchant URL POST: http://[nuestro servidor]/hotel/rest/caixabank
Forma de Pago: Crear una forma de pago en el punto A.D. Fichero de formas de pago y que tenga marcado el bullet de «TPV Virtual».
Link de pago: Tikar para activarlo.
Email avisos: mail donde se reciben los avisos.

Más información: 
http://manuales.shms.es/sspsd2/
http://manuales.shms.es/pago-directo-del-cliente/

Si se va a hacer tokenización de tarjetas, es necesario definir una plantilla de mail en la pestaña «Común» como en la siguiente imagen.

Configurar las plantillas de mail para el link de pago en el punto B.8. Setup-Formatos/Interfaces, Facturas.

Por otra parte, es necesario abrir en el router el puerto 80 o el 443 re-dirigido a la IP del servidor y quitar el firewall, si es que lo hay, para que lleguen las notificaciones de cuando el cliente realiza el pago.

Caixabank debe añadir nuestra IP, desde la que trabajamos, en su whitelist.

Debemos asignar una forma de pago, email avisos y dar al check de «link de pago» para activarlo.

Funcionalidades de esta integración:

  • Link de pago
  • Tokenización de tarjetas
  • Transacciones recurrentes y funcionalidades amplias
  • Datáfono integrado en PMS

Datáfono Lane/7000

El framework tiene que estar instalado en el equipo al que se va a conectar el TPV. Para instalarlo, es necesario ejecutar el archivo «runner3.bat» desde CMD con permisos de administrador. Última versión del framework en el siguiente enlace.

El puerto 5000 debe estar abierto y configurado en el firewall en Windows.

La IP es la del equipo donde está conectado el datáfono.

FAQs Addon Payments

Si una factura fue cobrada usando el datáfono, al anular la factura se realizará la devolución de la operación. Para hacer una devolución total siempre es necesaria la referencia de la operación original, que la guardamos internamente. No es posible hacer directamente una devolución, sin operación de cobro original. Para hacer una devolución total, se anula la factura, sin marcar el OK de «Después de generar la factura de abono, ¿desea modificar la anterior?«, porque si marcáis el OK, se generará un cobro negativo y otro positivo y ya no lo enviamos al datáfono.

Para devoluciones parciales en datáfonos Caixabank, desde modificación de cobros, si pulsamos en borrar el cobro original, debería salir un popup preguntando por el importe que queréis devolver. Con esta operación, la factura original quedará con saldo pendiente de cobro. Será necesario saldar este importe modificando esta factura. Deben tenerse en cuenta las implicaciones que estas operaciones tendrán en la contabilidad. 

Ver este manual.

Si se genera el cobro en el PMS, entonces es que el datáfono nos informa de que el cobro se hizo correctamente. En caso contrario, nos devuelve un error que se le mostraría al usuario en la caja de notificaciones de la parte superior derecha de la pantalla.

Esto se puede ver en el PMS, en el listado de cobros. Para consultarlo directamente en el datáfono no existe ninguna operación que nosotros podamos ejecutar.

Al anular una factura, cuando pregunta «Después de generar la factura de abono, ¿desea modificar la anterior?«, al pulsar en OK se genera una nueva factura ya con el cobro (que no pasó al datáfono). Es un caso límite que tiene fácil solución actualmente y es borrar o modificar ese cobro posteriormente.

Si solo se va a modificar la factura no es necesario pasar por el datáfono. Si se modifica la factura directamente sin hacer anulación no hay problema.

Al anular la factura se generaría otra negativa y se haría la devolución del total del importe de la factura. Si no está el cliente presente ¿cómo podemos volver a cobrar el nuevo importe?

En este caso, si no está el cliente no se puede hacer la anulación de la factura directamente. Previamente, se debe cambiar la forma de pago del cobro original, hacer la anulación de la factura, y luego volver a cambiar la forma de pago del cobro.

Paylands (PaynoPain)

Configuración del Proxy PCI de Paylands y uso con Siteminder

Para emplear el servicio de Proxy PCI ofrecido por Paylands debemos acudir a la pestaña de configuración del mismo en la opción 9.C. Configuración Proxy PCI. 

En esta página podremos realizar todas las acciones relativas a la gestión de canales del proxy.  

Comenzaremos por rellenar los campos Request URL y Bearer Token, que nos deberían ser facilitados el primero en la documentación de paylands (https://pci-proxy-api.paynopain.com/sandbox para entorno de pruebas, https://pci-proxy-api.paynopain.com/prod para producción) y el segundo directamente por ellos mismos a la hora de dar de alta el servicio. 

Una vez contemos con estos valores, podemos obtener los canales disponibles, pero si es la primera configuración no contaremos con ninguno. Para crearlos desde el popup de Añadir deberemos completar correctamente los siguientes campos: 

  • Endpoint: La dirección hacia o desde el que se transmite el cuerpo de la petición. Debe ser una dirección http válida. 
  • Dirección: Indica si el cuerpo de la carga útil que debe procesarse se envía al canal o se obtiene del canal. 
  • Content Type: Formato del cuerpo de la carga útil del que hay que extraer los datos para el proceso de tokenización o destokenización. 
  • Encoding: Codificación del cuerpo de la petición.  

El resto de campos pertenecen al Field Mapping, que define como el canal consume el contenido XML/JSON que recibe. Se deben rellenar con un XPATH/JSON correcto, de lo contrario ese dato no será recibido. Estos son los datos válidos para un XML de una reserva de Siteminder:  

  • Pan: //*[local-name()=’PaymentCard’]/@CardNumber 
  • Card Holder: //*[local-name()=’CardHolderName’] 
  • Expiry: //*[local-name()=’PaymentCard’]/@ExpireDate 
  • Reference: //*[local-name()=’UniqueID’]/@ID 
  • CardCVV: //*[local-name()=’PaymentCard’]/@CVV 

Flujo de Siteminder 

Una vez creado correctamente el canal, accedemos al cliente de Siteminder (9.A. Master Connection OTA’s -> Siteminder) y completamos el campo Endpoint con la URL generada en el canal en el parámetro de sólo lectura invoke URL. Si esta URL es correcta, al generar el polling de reservas, los datos del XML aportados por Siteminder pasarán por el filtro del canal creado, recibiendo nosotros la tarjeta tokenizada correctamente mapeada. Sin embargo esta tarjeta no es suficiente para crear el cargo al cliente mediante una transacción MIT si es necesaria la verificación 3DS. En este caso, enviaremos un mail a la dirección proporcionada en el mismo XML que verifique esta autenticación. En caso de no recibir respuesta no se podrá cobrar la reserva, por lo que recae en el hotel contactar con el cliente. 

Esta es la documentación del Proxy: Introducción | Paylands Documentation

Iniciaremos con un channel, Siteminder, para luego incorporar otros como la conexión directa con Booking.com

Además de poder descargar las reservas con tarjeta y tokenizarla también se puede incorporar el panshow (enseñar la tarjeta en un iframe de forma segura y PCI), para cuando el hotel quiere usar el TPV físico para cobrar digitando los números de la tarjeta.

Pero lo propio es que se use el token para enviar la transacción y no usar el Panshow.

Los tipos de transacción que se suelen hacer desde el PMS son:

  • Generar un link de pago con el token para solicitar al huésped:
    • Autenticar y autorizar la tarjeta con valor X
    • «Validar la tarjeta» Autenticar y autorizar con valor 0
  • En caso de tarjetas que no sean de la UE se puede enviar una autorización directa al token
  • En caso de que el adquirente le permita hacer transacciones MOTO se podría siempre enviar este tipo de transacción directa al token evitando la autenticación.
  • Para cobros de No Show se deben enviar transacciones de autorización MIT, con el flag «noshow» o «incremental» dependiendo del caso. SOLO se puede enviar MIT a tarjetas que previamente hayan sido autenticadas.

El proceso interno es el siguiente:

  1. La tarjeta se procesa en la web donde se realice la reserva.
  2. A través del Proxy PCI recibimos la nueva reserva con la tarjeta ya tokenizada sin la verificación 3DS.
  3. El PMS envía un email al huésped para la verificación 3DS del token.
  4. Si el huésped quiere, verifica la tarjeta y el PMS recibe el token completo contra el que se podrían hacer cobros.
  5. Posteriormente en cualquier otro momento se realiza el cobro al huésped.

El proceso desde el lado del huésped sería el siguiente:

  1. El huésped realiza la reserva en una plataforma estilo Booking.com, web del hotel, etc.
  2. Para confirmar la reserva esta plataforma le pide los datos de la reserva.
  3. Confirmamos la reserva y le llega un mail de confirmación de la misma.
  4. Unos minutos después, recibe por parte del PMS un email de verificación 3DS de la tarjeta.
  5. (Opcional) Podría recibir también un correo de confirmación de la reserva por parte del hotel.

El paso clave es el momento en que se envía el mail al usuario para que autentique la tarjeta (proceso 3DS). Sin este paso, luego no se le va a poder cobrar una no-show, o gastos de minibar, etc. Esto es así porque por la PSD2, un requisito de obligatorio cumplimiento es que cuando se lanza un cobro sin la presencia del usuario (como una no-show por ejemplo). Esa tarjeta debe haber sido autenticada por 3DS previamente. Es por este motivo que debido a los requisitos de la PSD2, es necesario este paso.

Para prevenir esta fricción con el usuario, en el email se puede incluir cualquier texto que se necesite para que el usuario entienda por qué es necesario ese paso. Por ejemplo, imaginemos que cuando nos llega una reserva, se le envía un mail al usuario con el enlace del 3DS y, además de una plantilla con la info de la reserva y demás, un texto que diga algo así:

«Para garantizar la seguridad en la reserva y prevenir fraude, necesitamos confirmar que usted es el propietario de la tarjeta (123456******6789) indicada en la reserva XXX. Pulse el siguiente enlace para validarla.»

FAQs Paylands

Sobre la duda de verificar las tarjetas, efectivamente no es necesario verificarlas todas. Sin embargo, no hay una forma fácil de saber si una tarjeta está afectada por la psd2 porque esto es algo que nosotros no podemos saber sin iniciar un pago contra el adquirente. Y es en ese momento cuando nos devuelve en la respuesta si hay psd2 o no. Pero claro, lo que necesitáis es evitar este paso. Esto lo estamos comentando internamente para ver si habría alguna forma de hacerlo.

Sobre el segundo punto, el proxy no modifica los campos que recibe, más allá de reemplazar el pan de la tarjeta. Pero no hay un campo que indique si realmente ha podido reemplazarlo. La comprobación de si contiene guiones no es tan descabellada, ya que si por lo que sea no puede tokenizar la tarjeta (por ejemplo porque sea una tarjeta incorrecta), en el campo donde iría el uuid, recibiréis el mensaje de error.

Cecabank

Estos son los pasos a seguir para comenzar la activación de la plataforma de Cecabank una vez el comercio esté dado de alta en su plataforma. Para este paso previo, es necesario ponerse directamente en contacto con ellos y solicitar esta alta. 

Una vez logueados dentro de https://comercios.ceca.es/pruebas (Comenzaremos en el TPV  de pruebas para realizar las primeras comprobaciones) accederemos a la pestaña de configuración. En este apartado tendremos disponibles los datos principales necesarios para las configuraciones dentro del PMS, siendo estos el TerminalID, MerchantID, AcquirerBIN y clave de encriptación. 

Los parámetros que debemos establecer en esta configuración son los relacionados con la comunicación online. Debemos activar esta misma en el selector de Comunicación on-line OK, establecer en el campo URL online OK la dirección del hotel que recibirá las respuestas de Cecabank (terminada en /hotel/rest/cecabank), y por últmo activar el parámetro de Respuesta requerida OK. 

Esta parte es requerida para emplear la tokenización de Cecabank, y para eso mismo es necesario solicitar su activación mediante el contacto con el soporte proporcionado en el mismo TPV virtual. Así mismo se activará nuestro comercio como seguro. 

A la hora de que el cliente realice un pago mediante el link recibido por email, necesitará aportar un Token de verificación. Para hacerle llegar este mismo de manera correcta, compondremos el email que recibirá en la opción B.8. Setup – Formatos/Interfaces => Facturas, definiendo claramente la variable #@3@# separada del propio link de pago. 

Para continuar con la implementación de Cecabank en el PMS después de la activación de su plataforma de TPV virtual, debemos completar dos configuraciones, una para Hotel y otra para CWM (B.8. y B.9. respectivamente), con los parámetros que nos aportan. 

Comenzando con hotel, estos son los campos a rellenar en la opción B.8. Setup – Formatos/Interfaces => Medios de pago => Cecabank: 

  • MerchantID, AcquirerBIN y TerminalID: Los 3 parámetros que identifican al comercio que obtenemos en la configuración del TPV. 
  • Clave de encriptación: La clave para generar las firmas SHA2 que verifican las transacciones, muy importante mantenerla privada. 
  • Endpoint: La dirección a la que se envían las peticiones de pagos, siendo distinta para pruebas y para transacciones reales. 
  • Endpoint Token: La dirección para las peticiones relacionadas con una tarjeta tokenizada (generar el token y realizar los cargos con el mismo). 
  • URL OK y URL NOK: Las urls a las que se redireccionará una vez terminen las transacciones, la URLOK será devuelta en las correctas y la URLNOK en las incorrectas. 
  • Email avisos: Como su propio nombre indica será el email al que lleguen los avisos de los fallos relacionados con esta implementación. 
  • Forma de pago: Tendrá que ser creada previamente una forma de pago para el TPV virtual de Cecabank. 

La siguiente configuración será para CWM en la opción B.9. Setup – CWM => Formas de pago CWM => Parámetros de TPV Virtual, y serían básicamente los mismos campos a rellenar que en la opción B.8.

Class One
Chatbot Image Hola! ¿En qué puedo ayudarle?

Powered by artificial intelligence, the bot can make mistakes. Consider checking important information.