Medios de Pago

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.»