Cumplimiento de la normativa europea PSD2

Descripción general

La directiva 2 sobre servicios de pago es un reglamento del EEE que modifica el proceso de reserva y pago para todas las transacciones que impliquen una tarjeta de crédito emitida por un Estado del EEE.

El objetivo de esta normativa es ayudar a reducir el fraude en línea y proteger a los viajeros. Entró en vigor en septiembre de 2019 y todos los socios de EPS pueden verse afectados por ella si trabajan con los tipos de pago afectados. Si las transacciones afectadas no cumplen con la normativa para el 31 de diciembre de 2020, los bancos del EEE rechazarán la transacción ya que están obligados a cumplir con dicha normativa a partir de esa fecha, independientemente de si la sede del socio se encuentra en el EEE o no.

Esta página explica cómo se verán afectados los tipos de pago de EPS admitidos y qué acciones pueden emprender los socios al prestar servicio a sus viajeros. Si desea conocer la directiva con más detalle, revise la legislación en el sitio oficial de la Comisión Europea.

Requisitos de cumplimiento normativo

Los pasos para habilitar las transacciones conformes con la normativa en el EEE variarán dependiendo de quién sea el comerciante registrado y cómo se realizan los pagos a EPS.

El socio es el comerciante registrado

Expedia Affiliate Collect

Las reservas que utilizan EAC no se ven afectadas por la normativa PSD2; no se necesita ningún proceso de pago ni cambios en la integración de la API con EPS para cumplir con la normativa. Sin embargo, puede verse afectado por la normativa si es el comerciante registrado y carga la tarjeta de crédito, la tarjeta de débito u otra forma de pago del viajero dentro del ámbito de la normativa de la UE. Es probable que la normativa requiera que admita una versión compatible con PSD2 de autenticación de dos factores en el proceso de pago. Póngase en contacto con su procesador de pagos para obtener más información sobre sus capacidades para ayudar a los comerciantes a cumplir con PSD2 y evitar transacciones fallidas.

Tarjetas de socio

Si su empresa es el comerciante registrado y paga a EPS con una tarjeta de crédito o débito emitida por el EEE propiedad de su empresa, puede verse afectada por la normativa. La relación de tarjetas compatibles con PSD2 es:

• Tarjetas virtuales de un solo uso, emitidas en el EEE.
• Tarjetas corporativas emitidas a su empresa (no a una persona) y en el EEE.
• Cualquier tarjeta emitida fuera del EEE.

También puede verse afectado por la normativa si realiza un cargo en la tarjeta de crédito, la tarjeta de débito u otra forma de pago de los viajeros dentro del ámbito de la normativa del EEE. Es probable que la normativa requiera que admita una versión compatible con PSD2 de autenticación de dos factores en el proceso de pago. Póngase en contacto con su procesador de pagos para obtener más información sobre sus capacidades para ayudar a los comerciantes a cumplir con PSD2 y evitar transacciones fallidas.

Si no es deseable utilizar las tarjetas de socio que cumplen con la norma PSD2, su organización puede solicitar una exención directamente al banco que ha emitido su tarjeta de socio. Si se concede una exención, las transacciones con esa tarjeta no requerirán autenticación, salvo una posible verificación única en línea mediante autenticación de dos factores (2FA). Este requisito único puede variar según el banco. Tenga en cuenta que la obtención de una exención puede ser un proceso largo y que también significará que su banco puede considerarlo responsable de los pagos fraudulentos.

EPS es el comerciante registrado

Si su empresa utiliza EPS como comerciante registrado y envía tarjetas de viajeros a EPS, puede verse afectado por la normativa. Cuando los viajeros reservan en línea, sin agente minorista, las normas exigen que EPS les permita verificar si han iniciado el pago. El proceso que cumple con la PSD2 para este requisito es la autenticación de dos factores (2FA) durante el proceso de pago. Los socios que deseen utilizar EPS como comerciante registrado con cualquier tarjeta de crédito o débito emitida por el EEE tendrán que adoptar nuestra solución EPS Rapid para 2FA disponible en EPS Rapid v2.2+.

No obstante, las transacciones que se registran a través de un agente minorista o de un agente de call center están exentas del requisito de la 2FA. El cumplimiento normativo de estas transacciones solo requiere una indicación explícita de que la reserva se ha realizado con la asistencia de un agente. Utilice el campo sales_channel de la API de disponibilidad para esta indicación.

El establecimiento es el comerciante de registro (Property Collect)

Si su empresa utiliza Property Collect, puede verse afectada por esta normativa. Hay circunstancias en las que un establecimiento puede tratar de cobrar la tarjeta de un viajero sin que este se encuentre presente físicamente (por ejemplo, tasas no show o depósitos). Estos cargos no cumplen con la normativa sin que se realice una autenticación de dos factores (2FA) antes de efectuar el cargo. Los socios que deseen utilizar Property Collect para viajeros que utilicen una tarjeta de crédito o débito emitida en el EEE, deberán adoptar nuestra solución EPS Rapid para 2FA disponible en EPS Rapid v2.2+.

Descripción general de la solución de EPS Rapid

¿Cómo funciona?

Los socios que utilizan EPS como comerciante registrado o Property Collect con tarjetas de viajeros pueden adoptar la solución de API de EPS para generar reservas que cumplan con la normativa. Las API cumplen con la PSD2 al admitir la autentificación de dos factores con 3DS 2.0 en el flujo de reservas. Con 3DS 2.0, admitimos la autenticación basada en riesgo, lo que reduce los posibles problemas con los viajeros al ceder a los bancos la discreción sobre cuándo solicitar la 2FA a los viajeros y cuándo no.    

La solución para la 2FA consta de tres componentes:

• Un iframe que los socios añaden a la página de pago. Se utiliza para alojar la experiencia 2FA de un banco emisor para el viajero. En la documentación de la integración, se denomina 3DS iframe.
• Una nueva biblioteca de JavaScript viajero que se aloja en la página de pago. Se utiliza para recopilar datos del navegador, comunicarse con el iframe y mostrar la experiencia 2FA dentro del iframe. En la documentación de la integración, se denomina biblioteca 3DS Connector.
• EPS Rapid acepta la información del pagador para el banco y lleva a cabo la reserva después de la 2FA.

Al utilizar JavaScript y el EPS Rapid de forma conjunta, el flujo de reserva con 2FA ahora incluye algunos pasos adicionales antes y después de invocar a la API de reservas. En el diagrama de abajo, se muestra este flujo de reservas actualizado.

Durante cada paso del flujo de reservas revisado, la salida de un paso contiene datos que se utilizan como entrada en el siguiente paso. Los datos deben pasarse entre JavaScript (en el navegador) y EPS Rapid.

Nota: El diagrama anterior es una simplificación del flujo real de la API, con fines introductorios. Consulte el documento de integración para saber más sobre el flujo completo de la API.

Detalles del componente de integración

Browser iFrame

El iframe, insertado en la experiencia de pago, aloja una URL propiedad del banco emisor de la tarjeta del viajero. Esta URL muestra una experiencia 2FA al usuario y transfiere cualquier información proporcionada por los viajeros directamente a sus bancos. El iframe debe estar oculto inicialmente, con la posibilidad de superponerlo en la parte superior de la página cuando se requiere 2FA después de un intento de reserva.

Browser JavaScript Library (nuevo)

Esta biblioteca se agrega a la página de pago y se invoca en el momento de la reserva para admitir el proceso de 2FA. Las API de la biblioteca admiten las capacidades que se describen a continuación.

Recopilación automática de información sobre dispositivos del viajero

Antes de un intento de reserva, se debe recopilar información sobre el dispositivo del viajero para preparar una reserva para la 2FA. Más tarde, se envía al banco emisor del viajero para su revisión, de modo que el banco pueda evaluar el riesgo, decidir si se requiere 2FA para la transacción y asegurarse de que se muestra correctamente. De acuerdo con las especificaciones 3DS 2.x, se recopilan los siguientes datos del navegador del viajero: idioma, profundidad de color, alto y ancho de la pantalla, zona horaria, agente de usuario y si Java está habilitado.

Visualización de la experiencia 2FA en el iframe del navegador

Después de un intento de reserva, la biblioteca se utiliza para mostrar la superposición de iframe y cargar el contenido del banco en el mismo.  Durante el proceso 2FA, el contenido del banco puede recopilar información adicional sobre el dispositivo del viajero para permitir la evaluación de riesgo. Este proceso es necesario para completar una reserva.

EPS Rapid

EPS Rapid v2.2 y superior incluye nuevas API que funcionan en conjunto con la biblioteca de JavaScript cliente.  Las API ahora admiten las capacidades descritas a continuación.

Registro del viajero y detalles de pago

Antes de un intento de reserva, se debe recopilar información adicional sobre el viajero para preparar una reserva para la 2FA. Estos datos incluyen detalles de la cuenta del viajero con el punto de venta y el pago del viajero. Estos datos se envían posteriormente al banco emisor del viajero para su revisión, de modo que el banco pueda evaluar el riesgo y decidir si es necesaria la 2FA para la transacción. Aprenda más analizando la API Registro de pago en EPS Rapid v2.2+.

Realización de un pago y confirmación de la reserva

Después de un intento de reserva con EPS Rapid y tras llevar a cabo el proceso 2FA en el navegador, EPS Rapid debe ser invocada una vez más. En segundo plano, confirmaremos que la 2FA se llevó a cabo correctamente, de modo que se puede confirmar la reserva. Aprenda más analizando la API Realización de pago en EPS Rapid v2.2+.

Flujo de reservas

Descripción general

Si 2FA está habilitado en un perfil de socio de EPS Support, la API Comprobación del precio devuelve un enlace a la API Registro de los pagos en lugar de la API Crear reserva. A continuación, se muestra un diagrama de la secuencia de llamadas a la API que se requiere después de que un viajero inicie una reserva. La secuencia incluye tanto llamadas a la biblioteca de JavaScript como a EPS Rapid.

Cuando se prepara una reserva para la 2FA, puede que no siempre sea necesaria. La necesidad de la 2FA viene determinada por el banco emisor de la tarjeta utilizada para el pago. Esta determinación se produce durante la transacción y se indica en la respuesta de la API Crear reserva.  

A continuación, se presenta un diagrama de la secuencia de llamadas de la API que se requiere cuando se utiliza Retener y reanudar.

Nota: Los diagramas anteriores son una simplificación del flujo real de la API, con fines introductorios. Consulte el documento de integración para saber más sobre el flujo completo de la API.

Más información

Para obtener más información sobre los requisitos técnicos para la experiencia 2FA, revise «Especificaciones y funciones básicas del protocolo 3-D Secure» de EMVCo.

Guía de integración de la autenticación de dos factores y EPS Rapid

Descripción general

La compatibilidad con la autenticación de dos factores (2FA) precisa la integración con una nueva biblioteca de JavaScript, denominada 3DS Connector y EPS Rapid.  Se utilizan conjuntamente para presentar la 2FA en la página de pago y confirmar una reserva.  Esta solución es compatible con los modelos de negocio Expedia Collect y Property Collect.

La secuencia de llamadas a la API necesaria para permitir la 2FA al realizar una reserva se describe a continuación y se detalla en las siguientes secciones.

1. JavaScript Setup method
2. EPS Rapid Register Payment API
3. JavaScript Initialize Session method
4. EPS Rapid Book API
5. JavaScript Challenge method
6. EPS Rapid Complete Payment API
7. EPS Rapid Resume API (optional)

Para permitir esta secuencia, debe estar habilitada para los perfiles de los socios individuales por EPS Partner Support.

EPS Rapid

Si se habilita la autenticación de dos factores (2FA) para un perfil de socio, las respuestas de la API difieren para permitir un flujo de reserva revisado con 2FA.

API de la disponibilidad

El valor del campo sales_channel en la solicitud de la API debe ser exacto para obtener una exención de la 2FA cuando lo permita la normativa. El valor, junto con muchos otros, es revisado por el banco emisor de la tarjeta para tomar esta decisión al realizar la reserva. Solamente las herramientas de los agentes están exentas de 2FA. Para especificar esto, establezca el valor de sales_channel en agent_tool.

API de Comprobación de los precios

La respuesta de la API incluirá un enlace a la API Registro de los pagos en lugar de la API Creación de reserva.

Ejemplo de respuesta cuando se activa la 2FA:

{
  "status": "matched",
  "occupancies": {
    ...(example omitted for length)
  },
  "links": {
    "payment_session": {
      "method": "POST",
      "href": "/2.2/payment-sessions?token=QldfCGlcUAVgBDRwdWXBBL"
    }
  }
}

API de Registro de los pagos

Este es el segundo paso en el flujo de reserva de JavaScript-Rapid PSD2 y se produce después del método de configuración de JavaScript.

La solicitud incluirá los datos de pago que forman parte del flujo de reserva sin PSD2 y nuevos campos que contribuyen a una 2FA correcta. Dos de estos campos, encoded_browser_metadata y version, se devuelven desde el método de configuración de las API de JavaScript.

La respuesta incluye los valores payment_session_id y encoded_init_config. Estos se especifican como entradas en el método initSession de la biblioteca de JavaScript. El enlace de la reserva incluido en la respuesta debe utilizarse después del método initSession.

Ejemplo de solicitud:

{
  "version": "1",
  "browser_accept_header": "*/*",
  "encoded_browser_metadata": "ZW5jb2RlZF9icm93c2VyX21ldGFkYXRh",
  "preferred_challenge_window_size": "medium",
  "merchant_url": "https://server.adomainname.net",
  "customer_account_details": {
    "authentication_method": "guest",
    "authentication_timestamp": "2018-02-12T11:59:00.000Z",
    "create_date": "2018-09-15",
    "change_date": "2018-09-17",
    "password_change_date": "2018-09-17",
    "add_card_attempts": 1,
    "account_purchases": 1
  },
  "payments": [
    {
      "type": "customer_card",
      "card_type": "VI",
      "number": "4111111111111111",
      "security_code": "123",
      "expiration_month": "08",
      "expiration_year": "2025",
      "billing_contact": {
        "given_name": "John",
        "family_name": "Smith",
        "email": "smith@example.com",
        "phone": "4875550077",
          "address": {
            "line_1": "555 1st St",
            "line_2": "10th Floor",
            "line_3": "Unit 12",
            "city": "Seattle",
            "state_province_code": "WA",
            "postal_code": "98121",
            "country_code": "US"
        }
      },
      "enrollment_date": "2018-09-15"
    }
  ]
}

Ejemplo de respuesta:

{
  "payment_session_id": "76d6aaea-c1d5-11e8-a355-529269fb1459",
  "encoded_init_config": "QSBiYXNlNjQgZW5jb2RlZCBvYmplY3Qgd2hpY2ggY29udGFpbnMgY29uZmlndXJhdGlvbiBuZWVkZWQgdG8gcGVyZm9ybSBkZXZpY2UgZmluZ2VycHJpbnRpbmcgYW5kL29yIDNEUyBNZXRob2Qu",
  "links": {
    "book": {
      "method": "POST",
      "href": "/2.2/itineraries?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
    }
  }
}

API de Creación de una reserva

Este será el cuarto paso en el flujo de reservas JavaScript-Rapid PSD2 y se produce después del método initSession de JavaScript.

La solicitud no incluirá ningún campo nuevo para PSD2; toda la información necesaria está contenida en el token del enlace de la reserva devuelto por la API Registro de los pagos.

La respuesta, si tiene éxito, siempre incluye un itinerary_id. Sin embargo, esto por sí solo no indica que se confirme una reserva porque puede ser necesaria la 2FA.

Si se requiere la 2FA, la respuesta también incluirá encoded_challenge_config. Los valores encoded_challenge_config y payment_session_id (devueltos por Registro de los pagos) tendrán que pasar como parámetros del método desafío de JavaScript.

La respuesta también incluirá un nuevo enlace a complete_payment_session. Este enlace debe utilizarse después del método desafío de la biblioteca de JavaScript.

Si la 2FA no es necesaria, la reserva se confirma y la respuesta incluye enlaces a retrieve,cancel y opcionalmente resume. Ejemplo de respuesta (si se requiere 2FA):

{
  "payment_session_id": "76d6aaea-c1d5-11e8-a355-529269fb1459", "encoded_init_config": "QSBiYXNlNjQgZW5jb2RlZCBvYmplY3Qgd2hpY2ggY29udGFpbnMgY29uZmlndXJhdGlvbiBuZWVkZWQgdG8gcGVyZm9ybSBkZXZpY2UgZmluZ2VycHJpbnRpbmcgYW5kL29yIDNEUyBNZXRob2Qu",
  "links": 
"book": {
      "method": "POST",
      "href": "/2.2/itineraries?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
    }
  }

API Finalización de la sesión del pago

Este es el sexto paso del flujo de reserva de JavaScript-Rapid PSD2 y se produce después del método challenge de JavaScript. Esta API es necesaria para completar el pago e informar a EPS de que se ha completado un intento de 2FA (con éxito o no).

La solicitud no incluye ningún campo nuevo relativo a PSD2.

La respuesta, si tiene éxito, incluye un itinerary_id y enlaces a retrieve, cancel y opcionalmente resume. Una respuesta correcta de que se ha confirmado una reserva.

Ejemplo de respuesta:

{
  "itinerary_id": "8999989898988",
  "links": {
    "retrieve": {
      "method": "GET",
      "href": "/2.2/itineraries/8999989898988?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
    }
  }
}

Biblioteca de JavaScript de 3DS Connector y 3DS iframe

Cuando se usa el flujo de trabajo de reservas PSD2, la página de pago debe incluir un nuevo iframe y una biblioteca de JavaScript.  El iframe, denominado 3DS iframe, mostrará la experiencia de autenticación (utilizando 3D-Secure 2.x) al viajero. La biblioteca de JavaScript, denominada biblioteca de 3DS Connector, permite la transferencia de información a los bancos emisores y carga el contenido de los bancos en el iframe.

Incorporación del 3DS iframe y la biblioteca de JavaScript

Incorporación del 3DS iframe

El 3DS iframe debe encontrarse en un contenedor que esté inicialmente oculto, pero que pueda mostrarse cuando se requiera autenticación para procesar un pago.

El diseño del contenedor se puede personalizar para adaptarse a la página de alojamiento. La muestra siguiente incluye un ejemplo de aplicación con fines de orientación únicamente, utilizando un modal de arranque:

<div id="threeDsIframeModal" class="modal" role="dialog">
  <div class="modal-dialog" role="document">
    <div class="modal-content">
      <div class="modal-body iframe-container">
        <div class="embed-responsive embed-responsive-16by9">
          <iframe id="threeDsIframe" src="<<3DS iframe URL>>">
          </iframe>
        </div>
      </div>
    </div>
  </div>
</div>

La fuente del iframe debe ajustarse a uno de dos valores:

La URL de prueba puede admitir pruebas (este tema se analiza más adelante en este documento). Para restringir el contenido del iframe durante las pruebas, el iframe puede configurarse para el entorno de pruebas, pero debe permitir lo siguiente:

sandbox="allow-scripts allow-forms allow-same-origin"

Incorporación la biblioteca de JavaScript 3DS Connector

La biblioteca de 3DS Connector se comunica con el 3DS iframe y envía los datos al banco emisor (que proporciona el contenido del iframe). La muestra siguiente incluye un ejemplo de cómo incorporar la biblioteca a la página de pago.

  <head>
  <script src="<<3DS connector script URL>>" integrity="<<actual integrity value>>"></script>
  </head>

Los valores de origen e integridad del elemento del script pueden ajustarse a los siguientes valores:

Nota: La URL del origen y la integridad cambian a medida que estén disponibles futuras versiones para su adopción. Las versiones más recientes no deben interrumpir la integración existente. Las versiones más antiguas del script continuarán siendo accesibles.

Uso del 3DS iframe y la biblioteca de JavaScript

La biblioteca precisa el uso de promesas de JavaScript. La muestra siguiente incluye un ejemplo de aplicación con fines exclusivamente orientativos y demuestra cómo se intercambian los datos entre los métodos de Javascript y EPS Rapid.

// Initialize the library
let connector = new PayThreeDSConnector.ThreeDSConnector("threedsiframe", "https://static.pay.expedia.com"); 
RapidIntegration.priceCheck(priceCheckLink)
  .then(priceCheckResponse => {
    paymentSessionLink = priceCheckResponse.links.payment_session.href;
    // Setup an authentication session with the library
    return connector.setup({ referenceId: '1000' })
  }).then(setupResponse => {
    console.log("Setup Response: ", setupResponse);
    
    // Send information from setup to Rapid's Register Payments API
    return RapidIntegration.registerPayment(paymentSessionLink, 
           setupResponse);
  }).then(paymentSessionResponse => {
    console.log("Register Payments Response: ", paymentSessionResponse);
    paymentSessionId = paymentSessionResponse.paymentSessionId;
    bookLink = paymentSessionResponse.links.book.href;
    if (paymentSessionResponse.encoded_init_config) {
      // If the payment session response contains an encoded_init_config   
      // field, initialize an authentication session with the library
      // using information returned from Rapid's Register Payments API
      connector.initSession({
        paymentSessionId: paymentSessionId,
        encodedInitConfig: paymentSessionResponse.encodedInitConfig
      }).then(initSessionResponse => {
        console.log("Init Session Response: ", initSessionResponse);
        // Then create a booking with Rapid's Book API
        return RapidIntegration.createBooking(bookLink, 
               paymentSessionId);
      })
    } else {
      // Otherwise, create a booking with Rapid's Book API directly
      return RapidIntegration.createBooking(bookLink, paymentSessionId);
    }
  }).then(createBookingResponse => {
    console.log("Create Booking Response: ", createBookingResponse);
    itineraryId = createBookingResponse.itinerary_id;
    if (createBookingResponse.encoded_challenge_config) {
      // If the Create Booking API contains an encoded_challenge_config field,
      // display the authentication challenge window
      $('#threeDsIframeModal).modal('show');
      completePaymentSessionLink = createBookingResponse.links.complete_payment_session.href;
      // Perform the challenge using the information returned from Rapid's Register Payments API
      // and Create Booking API
      connector.challenge({
        paymentSessionId: paymentSessionId,
        encodedChallengeConfig: createBookingResponse.encodedChallengeConfig
      }).then(challengeResponse => {
        console.log("Challenge Response: ", challengeResponse);
        // Complete a booking with Rapid's Complete Payment Session API
        return RapidIntegration.completePaymentSession(completePaymentSessionLink, itineraryId);
      }).then(completePaymentSessionResponse => {
        console.log("Complete Payment Session Response: ", completePaymentSessionResponse);
        return completePaymentSessionResponse;
      }).finally(() => {
        // Close the authentication challenge window
        $('#threeDsIframeModal').modal('hide');
      });
    } else {
      return createBookingResponse;
    }
  }).then(bookingResponse => {
    ...
  });

Nota: Las referencias a la clase RapidIntegration son parte del ejemplo y no de la biblioteca de 3DS Connector. Están pensadas para mostrar un contenedor compatible con la transferencia de información a las API.

Nota: La muestra utiliza valores estáticos para los parámetros que deben determinarse en el momento de la ejecución (por ejemplo, referenceid).

Directrices de la página de pago

Las marcas de tarjetas compatibles con 2FA pueden requerir que sus logotipos y marcas se muestren de acuerdo con sus directrices.

Nota: Los logotipos y la orientación para otras marcas de tarjetas se incluirán cuando estén disponibles.

Documentación de la biblioteca de JavaScript de 3DS Connector

Clase: 3DS Connector

Constructor

new ThreeDSConnector(threeDsIFrameId, threeDsIFrameOrigin)

Parameters:

Método

Configuración

Configura la sesión de pago recopilando los datos básicos del navegador necesarios para el servicio backend de 3DS, como el tamaño de la pantalla, la profundidad del color, etc.

Firma del método:

setup(setupRequest)

Parámetros:

Devoluciones:

Promiso para SetupResponse

Inicio de sesión

Inicia la sesión para la autentificación con 3DS. Como parte del inicio, se pueden recopilar datos adicionales del navegador. Si el emisor de la tarjeta lo requiere, se podría cargar una URL de método 3DS en el iframe para permitir que el servidor de control de acceso (ACS) del emisor de la tarjeta recopile los datos del navegador directamente. El cliente no tiene que esperar a que se invoque la llamada de finalización antes de que se pueda crear el pedido.

Method signature:

initSession(initSessionRequest)

Parámetros:

Respuesta: Promiso para InitSessionResponse

Desafío

Carga la experiencia de autenticación 3DS, si es requerida por el emisor de la tarjeta.

Firma del método:

challenge(challengeRequest)

Parámetros:

Respuesta: Promiso para ChallengeResponse

Clase: SetupRequest

Estructura de la solicitud para la llamada de configuración.

Propiedades:

Clase: SetupResponse

Respuesta de la llamada de configuración.

Propiedades:

Clase: InitSessionRequest

Estructura de solicitud del método initSession.

Propiedades:

Clase: InitSessionResponse

  Estado de la llamada initSession.

Propiedades:

Posibles valores de statusCode:

Nota: Para todos los valores statusCode de initSessionresponse, continúe con la API EPS Rapid Book

Clase: ChallengeRequest

Estructura de la solicitud para el método de desafío.

Propiedades:

Posibles valores de statusCode

Nota: Para todos los valores statusCode de challengeResponse, continúe con EPS Rapid para completar la sesión de pago.

Pruebas con EPS Rapid y autenticación de dos factores

Su integración con EPS Rapid y los métodos 3DS Connector se pueden probar con valores de parámetros de entrada que corresponden a escenarios específicos compatibles con las API.

EPS Rapid

Para probar EPS Rapid, incluya un encabezado HTTP adicional llamado Test en la solicitud HTTP y utilice uno de los valores admitidos para esa API a fin de probar un escenario compatible.

Dentro del flujo de reservas PSD2, las respuestas de prueba de EPS Rapid también se pueden utilizar para probar los métodos de la biblioteca de 3DS Connector.

Registro de los pagos

Los siguientes valores del encabezado de prueba dan como resultado diferentes valores encoded_init_config en la respuesta de la API y códigos de respuesta HTTP. El valor encoded_init_config se puede transferir a la llamada initSession de la biblioteca JavaScript para activar diferentes casos de prueba dentro de la biblioteca de 3DS Connector.

Nota: Diferentes casos de prueba dentro de Library.t_config de 3DS Connector que se pueden transferir a initSession y forzar un statusCode.

Creación de una reserva

Además de los encabezados de prueba definidos en Pruebas con EPS Rapid y autenticación de dos factores para el flujo de reservas sin PSD2, se admiten valores de cabecera de prueba adicionales para el flujo de trabajo PSD2. 

Los valores del encabezado de prueba dan como resultado diferentes valores encodedChallengeConfig que se pueden transferir a la llamada challenge de la biblioteca de JavaScript para activar diferentes casos de prueba.

Finalización de la sesión del pago

Los valores del encabezado de la prueba dan como resultado diferentes casos de error que pueden ocurrir cuando se intenta completar un pago y confirmar una reserva.

Biblioteca 3DS Connector e iframe

Para probar 3DS Connector sin dependencias externas, los valores de los parámetros específicos corresponden a las respuestas de los métodos compatibles. Este comportamiento solo se admite cuando el iframe se carga con la URL del entorno de pruebas.

Inicio de sesión

Los valores compatibles de InitSessionResponse statusCode se pueden probar variando initSessionRequest encodedInitConfig.

Nota: Los valoresencoded_init_config también se pueden generar valores con los encabezados de prueba admitidos de la API Registro de los pagos.

Challenge

Los valores compatibles de challengeResponse statusCode se pueden probar variando challengeRequest encondedChallengeConfig.

Nota: Los valores encodedInitConfig también se pueden generar con los encabezados de prueba admitidos para el flujo PSD2 de la API de reservas.

Nota: Cuando se comprueba el valor del código de estado de desafío SUCCESS o FAIL basado en la entrada del usuario con el iframe, la respuesta del método de desafío esperará a la finalización de la UI de autenticación simulada en el iframe. 

Ejemplo de UI en 3DS iframe:

Ejemplo de uso

Uso de Ejemplo

La muestra siguiente incluye un ejemplo de aplicación con fines de orientación únicamente. La muestra presenta cómo utilizar los valores de los parámetros predefinidos con el fin de probar que la biblioteca para un desafío 3DS tiene éxito sin que el usuario tenga que interactuar con el iframe.

var c = new PayThreeDSConnector.ThreeDSConnector("threedsiframe", "https://static.pay.expedia.com"); // change to match the 3DS iframe ID
c.setup({referenceId: "1000"})
  .then(setupResponse => {
    console.log("Setup Output: ", setupResponse);
    return c.initSession({paymentSessionId: 1, encodedInitConfig: " W3sicHJvdmlkZXJJZCI6IDAsICJzYW5kYm94SW5pdE91dHB1dENvbmZpZyI6ICJTVUNDRVNTIn1d"}); // SUCCESS
  })
  .then(initResponse => {
    console.log("InitSession Output: ", initResponse);
    $("#threedsIframeModal").modal(); // replace with code to show the modal containing the 3DS iframe
    return c.challenge({paymentSessionId: 1, encodedChallengeConfig: " W3sicHJvdmlkZXJJZCI6IDAsICJzYW5kYm94Q2hhbGxlbmdlT3V0cHV0Q29uZmlnIjogIlNVQ0NFU1MifV0="}); // SUCCESS
  })
  .then(challengeResponse => {
    console.log("Challenge Output: ", challengeResponse);
  })
  .finally(() => {
    $("#threedsIframeModal").modal('hide'); // replace with code to hide the modal containing the 3DS iframe
  });

Autenticación de dos factores y Property Collect

Acerca de la Autenticación de dos factores para Property Collect

Cuando se reserva con Property Collect, Expedia no realiza cargos a la tarjeta; simplemente, se envía al establecimiento para su gestión. El establecimiento puede utilizar esta información para validar la tarjeta antes de la entrada. En el momento de la entrada, se espera que el viajero pague en persona.

Sin embargo, a veces los viajeros no pueden realizar la entrada y es posible que los establecimientos cobren una tarifa de no show. Estos cargos pueden verse afectados por la normativa PSD2 ya que implican una tarjeta y que el viajero no está presente.

Si las transacciones se ven afectadas, es posible que se produzcan fallos en los pagos o que los establecimientos se enfrenten a penalizaciones de las marcas de las tarjetas si el cargo no cumple con la normativa.

Para proteger nuestra relación con los establecimientos y continuar sirviendo a nuestros socios, el Grupo Expedia ofrece a los establecimientos un método opcional para cumplir con la normativa. Los establecimientos afectados ahora, gracias al Grupo Expedia, pueden proporcionar 2FA en su nombre. Esto permite que los establecimientos protejan su negocio y asegura que EPS pueda seguir ofreciendo la misma gama variada de establecimientos.

EPS Rapid 2.4+ proporciona el indicador <payment_registration_recommended=true> en el archivo de contenido del establecimiento y el contenido del establecimiento, que puede ayudar a identificar un establecimiento cuando está potencialmente involucrado en el proyecto.

Nota: Solamente los establecimientos del Espacio Económico Europeo (EEE) pueden optar a la 2FA.

Nota: El conjunto de establecimientos que pueden requerir 2FA no es estático; puede crecer a medida que otros establecimientos elijan habilitar esta función. Este atributo de un establecimiento está disponible en EPS Rapid Content v.2.4.

¿Cómo puede la 2FA para Property Collect afectar una integración?

Si un socio desea procesar establecimientos que puedan precisar 2FA, la ruta de la reserva debe ser compatible con 2FA. Sin la compatibilidad de 2FA, la reserva de estos establecimientos puede fallar si el banco emisor de la tarjeta determina que se necesita 2FA para la transacción (por ejemplo, tarjetas emitidas en el EEE).

Cuando el establecimiento realiza un cargo por no show, EPS es el comerciante registrado. El descriptor del cargo en el extracto de la tarjeta no lo define el establecimiento. Es el socio quien define el valor del descriptor. Para personalizar este texto, póngase en contacto con el Servicio de Soporte para Socios de EPS. Para seguir cumpliendo con los requisitos de las marcas de las tarjetas y el proceso de lanzamiento de EPS Rapid, utilice la API Pagos aceptados para mostrar el valor processing_country en la página de pago en caso de no show. Esto es necesario para todas las transacciones en las que EPS es el comerciante registrado, y puede ocurrir si se utiliza 2FA y se produce un no show.

¿Cómo se pueden mitigar los impactos de una integración?

Si una integración de EPS Rapid no admite 2FA en el flujo de reservas, el riesgo de fallos en las reservas puede reducirse no vendiendo los establecimientos.

Póngase en contacto con el Servicio de Soporte para Socios de EPS a fin de eliminar estas tarifas de Property Collect de las respuestas de la API Disponibilidad.

Cuando se utiliza una herramienta de agente, la transacción está exenta de 2FA, conforme a la normativa. Utilice sales_channel de las API de Disponibilidad para indicar esto.

Manejo de errores

Las API Crear reserva y Completar sesión de pago pueden dar lugar a reservas y transacciones de pago confirmadas.

Su integración debe tener en cuenta las siguientes instrucciones para evitar pérdidas financieras y casos de operaciones de clientes: