Cumplimiento de la PSD2 en Europa

Descubre las repercusiones que tiene para tu empresa la nueva normativa de pagos con tarjeta en el EEE.

Información general

La Directiva de Servicios de Pago 2 (PSD2) es una normativa del EEE que implica cambios en el proceso de pago y reserva para todas las transacciones en las que se utilice una tarjeta de crédito emitida por un estado del EEE.

La PSD2 mejora la seguridad y reduce el riesgo de fraude, pero también cambia considerablemente la forma de realizar pagos en toda Europa. Como parte de esta normativa, se debe utilizar una solución de autenticación reforzada de clientes cuando se gestionen pagos electrónicos de consumidores dentro del alcance de la normativa. Todos los emisores de tarjetas, bancos adquirentes e intermediarios deben contar con una solución de autenticación reforzada de clientes. Se producirá un error en el pago si no se cumple este requisito, ya que los bancos dentro del EEE aplican la normativa.

En esta página se explica cómo afecta a los tipos de pago que admite Rapid API y qué medidas pueden tomar los colaboradores para cumplir con la normativa cuando atienden a sus viajeros. Si quieres obtener más información sobre la directiva, consulta la legislación en el sitio oficial de la Comisión Europea.

Requisitos de cumplimiento

Los pasos para realizar transacciones que cumplan con la normativa en el EEE variarán según quién sea el intermediario oficial y cómo se realicen los pagos en Rapid API.

Colaborador como intermediario oficial

Expedia Affiliate Collect

Las reservas que utilizan EAC no se ven afectadas por la normativa PSD2. No es necesario realizar ningún cambio en el proceso de pago ni en la integración de la API con Rapid para cumplir con la normativa. Sin embargo, es posible que la normativa tenga repercusiones para ti si eres el intermediario oficial y cobras a los viajeros a través de una tarjeta de crédito, una tarjeta de débito u otra forma de pago dentro del alcance de la normativa de la UE. Es probable que debas utilizar una versión de la autenticación en dos pasos, o 2FA, que cumpla con la normativa en el proceso de pago. Contacta con tu procesador de pagos para obtener más información sobre cómo te puede ayudar a cumplir con la PSD2 y evitar que se produzca un error en las transacciones.

Tarjetas de colaboradores

Si tu empresa es el intermediario oficial y realiza un pago a Rapid con una tarjeta de crédito o débito propia emitida en el EEE, es posible que te afecte la normativa. Esta es la lista de tarjetas compatibles con la PSD2:

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

Es posible que también te afecte la normativa si cobras a los viajeros a través de una tarjeta de crédito, una tarjeta de débito u otra forma de pago dentro del alcance de la normativa del EEE. Es probable que debas utilizar una versión de la autenticación en dos pasos, o 2FA, que cumpla con la normativa en el proceso de pago. Contacta con tu procesador de pagos para obtener más información sobre cómo te puede ayudar a cumplir con la PSD2 y evitar que se produzca un error en las transacciones.

Si tu empresa prefiere no utilizar ninguna de estas tarjetas compatibles con la PSD2, puede solicitar una exención directamente al banco que haya emitido tu tarjeta de colaborador. Si se concede la exención, no será necesaria la autenticación en las transacciones con esa tarjeta, a menos que se requiera una verificación online única con 2FA. Este requisito puede variar según el banco. Ten en cuenta que obtener una renuncia puede ser un proceso largo y, además, el banco podrá responsabilizarte en caso de que se efectúe un pago fraudulento.

Rapid como intermediario oficial

Si el intermediario oficial de tu empresa es Rapid y, por tanto, envías las tarjetas de los viajeros a la plataforma, es posible que te veas afectado por la normativa. Cuando los viajeros reservan online, sin un agente minorista, la normativa exige que Rapid les permita verificar si se ha iniciado el pago. Para cumplir con este requisito de la PSD2, se debe utilizar la autenticación en dos pasos, o 2FA, durante el proceso de pago. Los colaboradores que quieran utilizar Rapid como el intermediario oficial para pagos con cualquier tarjeta de crédito o débito emitida en el EEE deberán adoptar nuestra solución de 2FA.

Sin embargo, las transacciones que se realizan a través de un agente minorista o de un centro de llamadas están exentas del requisito de 2FA. Solo es necesaria una indicación explícita de que esa reserva se realizó con la asistencia de un agente para que este tipo de transacciones cumpla con la normativa. Utiliza el campo sales_channel de la API de disponibilidad para indicarlo.

Alojamiento como intermediario oficial

Si tu empresa utiliza Property Collect, es posible que te veas afectado por la normativa. Hay circunstancias en las que un alojamiento puede intentar cobrar un cargo a través de la tarjeta de un viajero sin que este esté presente (p. ej., depósitos o cargos por no presentarse). Estos cargos no cumplen con la autenticación en dos pasos, o 2FA, que se debe realizar previamente. Los colaboradores que quieran utilizar Property Collect para pagos con cualquier tarjeta de crédito o débito emitida en el EEE deberán adoptar nuestra solución de 2FA.

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

Funcionamiento

Los colaboradores que utilizan Rapid como el intermediario oficial o Property Collect con tarjetas de viajeros pueden adoptar la solución de Rapid API para generar reservas que cumplan la normativa. Las API permiten cumplir la PSD2 al integrar la autenticación en dos pasos con 3DS 2.0 en el flujo de reserva. Con 3DS 2.0 integramos una autenticación basada en riesgos, que reduce la fricción con los viajeros al permitir que los bancos decidan cuándo se les debe aplicar un desafío de 2FA y cuándo no.

La solución de 2FA está formada por tres componentes distintos:

• Un iframe que los colaboradores añaden en la página de pago. Se utiliza para ofrecer la experiencia de 2FA de un banco emisor al viajero. En la documentación de integración se denomina "iframe 3DS".
• Una nueva biblioteca de JavaScript del lado del cliente que se encuentra en la página de pago. Se utiliza para recopilar datos del navegador, comunicarse con el iframe y mostrar la experiencia de 2FA dentro del iframe. En la documentación de integración se denomina "biblioteca 3DS Connector".
• Rapid recibe del banco la información del pagador y completa la reserva después de la 2FA.

Al usar JavaScript y Rapid juntos, ahora el flujo de reserva con 2FA incluirá algunos pasos adicionales antes y después de llamar a la API de reservas. A continuación, se muestra un diagrama en el que se representa este flujo de reserva actualizado.

El resultado de cada paso en este flujo de reserva revisado contiene datos que se deben introducir en el paso siguiente. Deben transmitirse los datos entre JavaScript en el navegador y Rapid.

Nota: El diagrama anterior es una simplificación del flujo real de la API y está pensado como una referencia introductoria. Consulta la documentación de integración para obtener más información sobre el flujo completo de la API.

Detalles de los componentes de la integración

iframe en el navegador

El iframe, ubicado en la página de pago, aloja una URL del banco emisor de la tarjeta del viajero. Esta URL mostrará la experiencia de 2FA al usuario y transferirá cualquier información proporcionada por el viajero directamente a su banco. El iframe tiene que estar oculto inicialmente, pero debe de tener la capacidad para superponerse en la parte superior de la página cuando se requiera un desafío de 2FA después de un intento de reserva.

Biblioteca de JavaScript en el navegador

Esta biblioteca se añade a la página de pago y se invoca en el momento de la reserva para ofrecer el proceso de 2FA. Las API de la biblioteca ofrecen las funciones que se indican a continuación.

Recopilación automática de información sobre el dispositivo del viajero

Antes de un intento de reserva, se debe recopilar información sobre el dispositivo del viajero para preparar la reserva para la 2FA. Después, se envía al banco emisor del viajero para que la revise, de modo que el banco pueda evaluar los riesgos, decidir si se es necesaria una 2FA para la transacción y asegurarse de que se muestre correctamente. De acuerdo con las especificaciones de 3DS 2.x, se recopilarán los datos siguientes del navegador del viajero: idioma, profundidad de color, altura de la pantalla, ancho de la pantalla, zona horaria, agente de usuario y si Java está habilitado.

Mostrar la experiencia de 2FA en el iframe del navegador

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

Rapid

Rapid incluye API que se utilizan junto con la biblioteca de JavaScript del lado del cliente. Actualmente, las API ofrecen las funciones que se indican a continuación.

Registro del viajero y detalles del pago

Antes de un intento de reserva, se debe recopilar más información sobre el viajero para preparar la reserva para la 2FA. Estos datos incluyen los detalles de la cuenta del viajero en el punto de venta y el pago que va a realizar. Después, estos datos se envían al banco emisor del viajero para que la revise, de modo que el banco pueda evaluar los riesgos y decidir si se es necesaria una 2FA para la transacción. Para obtener más información, revisa la API de registro del pago en Rapid.

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

Después de un intento de reserva con Rapid, y una vez finalizado el proceso de 2FA en el navegador, es necesario volver a invocar Rapid. Verificaremos en segundo plano si la 2FA se ha realizado correctamente para poder confirmar la reserva. Para obtener más información, revisa la finalización de la sesión de pago en Rapid.

Flujo de reserva

Información general

Si se habilita la 2FA para perfiles de colaboradores en la asistencia de Rapid, la API de comprobación de precios devolverá un enlace a la API de registro del pago en lugar de a la API de creación de reserva. A continuación, se muestra un diagrama de la secuencia de llamadas a la API necesaria después de que un viajero inicie una reserva. La secuencia involucra llamadas tanto a la biblioteca de JavaScript como a la de Rapid.

Aunque las reservas se preparan para la 2FA, no siempre es necesaria. Es el banco emisor de la tarjeta de crédito utilizada para el pago quien determina si se necesita una 2FA. Esta decisión se produce durante la transacción y se indica en la respuesta de la API de creación de reserva.

A continuación, se muestra un diagrama de la secuencia de llamadas necesaria para usar la API de retención y reanudación.

Nota: Los diagramas anteriores son una simplificación del flujo real de la API y están pensados como una referencia introductoria. Consulta la documentación de integración para obtener más información 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 de 2FA, revisa el protocolo de 3D Secure y la especificación de funciones básicas de EMVCo.

Guía de integración de la autenticación en dos pasos y Rapid

Información general

Para implementar la autenticación en dos pasos, o 2FA, será necesaria la integración con una nueva biblioteca de JavaScript, denominada 3DS Connector, y Rapid. Ambos se usan en conjunto para mostrar la 2FA en la página de pago y confirmar una reserva. Esta solución es compatible con ambos modelos de negocio, Expedia Collect y Property Collect.

La secuencia de llamadas a la API necesaria para hacer una reserva con 2FA se menciona a continuación y se detalla en las secciones siguientes:

1. Método de configuración de JavaScript
2. API de registro del pago de Rapid
3. Método de inicio de la sesión de JavaScript
4. API de reservas de Rapid
5. Método de desafío de JavaScript
6. API de finalización del pago de Rapid

Para permitir esta secuencia, se debe habilitar la 2FA para perfiles de colaboradores individuales en la asistencia para colaboradores de Rapid.

Rapid

Si se habilita la autenticación en dos pasos para los perfiles de colaboradores, las respuestas de la API cambiarán para ofrecer un flujo de reserva revisado con 2FA.

API de disponibilidad

Se debe introducir un valor específico en el campo sales_channel de la solicitud de la API para obtener una renuncia de la 2FA cuando lo permita la normativa. Este valor, junto con muchos otros factores, lo revisa el banco emisor de la tarjeta para tomar su decisión en el momento de la reserva. Solo las herramientas para agentes están exentas de 2FA. Para especificarlo, establece el valor de sales_channel en agent_tool.

API de comprobación de precios

La respuesta de la API incluirá un enlace a la API de registro del pago en lugar de a la API de creación de reserva.

Ejemplo de respuesta cuando se habilita la 2FA:

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

API de registro del pago

Este es el segundo paso en el flujo de reserva de JavaScript y Rapid conforme con la PSD2 y ocurre después del método setup de JavaScript.

La solicitud incluirá los mismos detalles del pago que se deben introducir en el flujo de reserva no conforme con la PSD2, además de nuevos campos para realizar correctamente una 2FA. Dos de estos campos, encoded_browser_metadata y version, se devuelven desde el setup method de la API de JavaScript.

La respuesta incluirá un payment_session_id y encoded_init_config. Estos valores se especifican como entradas en el método initSession de la biblioteca de JavaScript. El enlace de reserva incluido en la respuesta debe usarse 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": "/v3/itineraries?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
        }
    }
}

API de creación de reserva

Este es el cuarto paso en el flujo de reserva de JavaScript y Rapid conforme con la PSD2 y ocurre después del método initSession de JavaScript. La solicitud no incluirá ningún campo nuevo para la PSD2, ya que toda la información necesaria se encuentra dentro del token del enlace de reserva que devuelve la API de registro del pago. Si es correcta, la respuesta siempre incluirá un itinerary_id. Sin embargo, esto no indica que la reserva esté confirmada, ya que es posible que se requiera una 2FA.

Si se requiere una 2FA, la respuesta también incluirá un encoded_challenge_config. Los valores encoded_challenge_config y payment_session_id que devuelve el registro del pago deberán introducirse como parámetros en el método challenge de JavaScript.

La respuesta también incluirá un nuevo enlace para complete_payment_session. Este enlace debe usarse después del método challenge de la biblioteca de JavaScript.

Si no se requiere una 2FA, se confirmará la reserva y la respuesta incluirá enlaces para retrieve, cancel y, opcionalmente, resume.

Ejemplo de respuesta de creación de reserva si se requiere una 2FA:

{
    "itinerary_id": "8999989898988",
    "links": {
        "complete_payment_session": {
            "method": "PUT",
            "href": "/v3/itineraries/8999989898988/payment-sessions?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
        }
    },
    "encoded_challenge_config": "ABElifsiejfacies2@033asfe="
}

API de finalización de la sesión de pago

Este es el sexto paso en el flujo de reserva de JavaScript y Rapid conforme con la PSD2 y ocurre después del método challenge de JavaScript. Esta API es necesaria para completar el pago e informar a Rapid de que ha habido un intento de 2FA, independientemente de si se ha superado o no.

La solicitud no incluirá ningún campo nuevo para la PSD2.

Si es correcta, la respuesta incluirá un itinerary_id y enlaces para retrieve, cancel y, opcionalmente, resume. Se recibirá una respuesta que indica que la reserva está confirmada.

Ejemplo de respuesta:

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

Biblioteca de JavaScript 3DS Connector y iframe 3DS

Cuando se utiliza el flujo de reserva de la PSD2, la página de pago debe incluir un iframe y una biblioteca de JavaScript nuevos. El iframe, denominado "iframe 3DS", mostrará al viajero la experiencia de autenticación con 3D-Secure 2.x. La biblioteca de JavaScript, denominada "biblioteca 3DS Connector", permite que se transfiera la información a los bancos emisores y cargará el contenido de los bancos en el iframe.

Cómo añadir el iframe 3DS y la biblioteca de JavaScript

Cómo añadir el iframe 3DS

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

El diseño del contenedor se puede personalizar para adaptarlo a la página de alojamiento. A continuación, verás un ejemplo de implementación de referencia en el que se muestra el uso de 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 establecerse en uno de estos dos valores:

Se puede utilizar la URL de prueba para hacer pruebas (revisaremos este tema más adelante en este documento). Para restringir el contenido del iframe durante las pruebas, se le puede atribuir un entorno de pruebas siempre y cuando permita lo siguiente:

sandbox = 'allow-scripts allow-forms allow-same-origin';

Cómo añadir la biblioteca de JavaScript 3DS Connector

La biblioteca 3DS Connector se comunica con el iframe 3DS y envía datos al banco emisor, que proporciona contenido al iframe. En el ejemplo a continuación se muestra cómo se puede añadir la biblioteca a la página de pago.

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

Deben establecerse los valores source e integrity siguientes en el elemento script:

Nota: Los valores source URL e integrity cambiarán a medida que haya más versiones disponibles. Las versiones más recientes no deberían entrar en conflicto con la integración actual. Se podrá seguir accediendo a las versiones anteriores del script.

Cómo utilizar el iframe 3DS y la biblioteca de JavaScript

Para la biblioteca se deben utilizar promesas de JavaScript. A continuación, verás un ejemplo de implementación de referencia en el que se muestra cómo se intercambian los datos entre los métodos de JavaScript y 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 3DS Connector. El objetivo es mostrar un contenedor que admite la transferencia de información a las API.

En el ejemplo se usan valores estáticos para parámetros que deben determinarse durante la ejecución, como referenceId.

Directrices para la página de pago

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

Nota: Se incluirán los logotipos y las directrices de otras marcas de tarjetas cuando estén disponibles.

Documentación de la biblioteca de JavaScript 3DS Connector

Clase: ThreeDSConnector

Constructor

new ThreeDSConnector(threeDsIFrameId, threeDsIFrameOrigin)

Parámetros:

Método

Configuración

Configura la sesión de pago con la información básica del navegador que necesita el servicio de backend de 3DS, como el tamaño de la pantalla, la profundidad de color, etc.

Firma del método:

setup(setupRequest)

Parámetros:

Devuelve:

Promesa de SetupResponse

Inicio de la sesión

Inicia la sesión para la autenticación con 3DS. Como parte de la inicialización, se pueden recopilar más datos del navegador. Si el emisor de la tarjeta lo solicita, se puede cargar una URL de método 3DS en el iframe para permitir que el servidor de control de acceso del emisor de la tarjeta recopile los datos directamente desde el navegador. El cliente no tiene que esperar a que se invoque la llamada de finalización para crear el pedido.

Firma del método:

initSession(initSessionRequest)

Parámetros:

Devuelve: promesa de InitSessionResponse

Desafío

Carga la experiencia de autenticación 3DS, si así lo requiere el emisor de la tarjeta.

Firma del método:

challenge(challengeRequest)

Parámetros:

Devuelve: promesa de 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 la solicitud para el método initSession.

Propiedades:

Clase: InitSessionResponse

Estructura de la respuesta para el método initSession.

Propiedades:

Posibles valores para statusCode:

Nota: Para todos los valores statusCode de initSessionresponse, consulta la API de reservas de Rapid.

Clase: ChallengeRequest

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

Propiedades:

Posibles valores para statusCode

Nota: Para todos los valores statusCode de challengeResponse, consulta la finalización de la sesión de pago de Rapid.

Pruebas con la autenticación en dos pasos y Rapid

Se pueden hacer pruebas en tu integración de los métodos de 3DS Connector y Rapid con valores de parámetros de entrada que corresponden a situaciones específicas compatibles con las API.

Rapid

Para hacer pruebas en Rapid, incluye un encabezado HTTP adicional de prueba en la solicitud HTTP y utiliza uno de los valores compatibles con esa API para poner a prueba una situación válida.

Dentro del flujo de reserva de la PSD2, las respuestas de prueba de Rapid también se pueden usar para poner a prueba los métodos de la biblioteca 3DS Connector.

Registro del pago

Los valores de encabezados de prueba que se indican a continuación dan como resultado diferentes valores de encoded_init_config en la respuesta de la API y diferentes códigos de respuesta HTTP. El encoded_init_config se puede transferir a la llamada initSession de la biblioteca de JavaScript para activar diferentes casos de prueba dentro de la biblioteca 3DS Connector.

Nota: Diferentes casos de prueba de init_skip en Library.t_config de 3DS Connector pueden transferirse a initSession y forzar un statusCode de SKIPPED.

Creación de una reserva

Además de los encabezados de prueba definidos en Solicitudes de prueba de reservas de Rapid para el flujo de reserva no conforme con la PSD2, se admiten otros valores de encabezados de prueba para el flujo de trabajo de la PSD2.

Los valores de encabezados 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 de pago

Los valores de encabezados de prueba dan como resultado diferentes casos de error que pueden ocurrir al intentar completar un pago y confirmar una reserva.

Biblioteca 3DS Connector y iframe

Para hacer pruebas en 3DS Connector sin depender de recursos externos, los valores de parámetros específicos corresponden con las respuestas de los métodos admitidos. Este comportamiento solo se admite cuando el iframe se carga con la URL del entorno de pruebas.

Inicio de la sesión

Se pueden comprobar los valores admitidos del InitSessionResponse statusCode cambiando el initSessionRequest encodedInitConfig.

Nota: Los valores encoded_init_config también se pueden generar con los encabezados de prueba que admite la API de registro del pago.

Desafío

Se pueden comprobar los valores admitidos del challengeResponse statusCode cambiando el challengeRequest encondedChallengeConfig.

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

Nota: Cuando se prueban los valores de código de estado del desafío SUCCESS o FAILED según la entrada del usuario en el iframe, la respuesta del método de desafío esperará hasta que se complete la simulación en la interfaz de usuario de autenticación del iframe.

Ejemplo de interfaz de usuario en iframe 3DS:

Ejemplo de uso

A continuación, verás un ejemplo de implementación de referencia. En el ejemplo se muestra cómo se usan los valores de parámetros predefinidos para probar un desafío 3DS en la biblioteca sin que el usuario deba 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 en dos pasos y Property Collect

Acerca de la autenticación en dos pasos para Property Collect

Cuando se realiza una reserva con Property Collect, Expedia no efectúa ningún cargo en la tarjeta, sino que enviamos los datos al alojamiento para que gestione el pago. El alojamiento puede usar esta información para validar la tarjeta antes de la entrada. El viajero deberá pagar en persona al realizar el registro de entrada.

Sin embargo, a veces los viajeros no pueden realizar la entrada y los alojamientos pueden cobrar un cargo por no presentarse. Estos cargos pueden verse afectados por la normativa PSD2, ya que se van a cobrar a través de la tarjeta del viajero cuando no está presente.

En ese caso, es posible que se produzca un error en el pago o que el alojamiento reciba una sanción de la marca de la tarjeta si el cargo no cumple los requisitos.

Para proteger nuestra relación con los alojamientos y seguir ayudando a nuestros colaboradores, Expedia Group ofrece un método opcional que cumple con la normativa. Los alojamientos que se vean afectados ahora pueden solicitar a Expedia Group que realice la 2FA en su nombre. De ese modo, los alojamientos pueden proteger su negocio y nos aseguramos de seguir ofreciendo la misma variedad de alojamientos en Rapid.

Rapid incluye el indicador de <payment_registration_recommended=true> en el archivo de contenido del alojamiento y en el contenido del alojamiento para ayudarte a identificar los alojamientos que pueden estar involucrados en el proyecto.

Nota: Solo los alojamientos del Espacio Económico Europeo (EEE) cumplen los requisitos de la 2FA. La lista de alojamientos que pueden aplicar la 2FA puede ampliarse a medida que otros alojamientos decidan habilitar esta funcionalidad.

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

Si un colaborador quiere ofrecer alojamientos que pueden aplicar la 2FA, la página de reserva deberá ser compatible con la 2FA. De no ser así, se puede producir un error en las reservas de estos alojamientos si el banco emisor de la tarjeta determina que se requiere una 2FA para la transacción, como en el caso de las tarjetas emitidas en el EEE.

Cuando un alojamiento cobra un cargo al huésped por no presentarse, Rapid será el intermediario oficial. El alojamiento no definirá el descriptor del cargo que figura en el extracto de la tarjeta. El valor del descriptor lo define el colaborador. Para personalizar este texto, contacta con el servicio de asistencia para colaboradores de Rapid.
Para cumplir los requisitos de las marcas de tarjetas y el proceso de lanzamiento de Rapid, utiliza la API de pagos aceptados para mostrar processing_country en la página de pago en caso de que el huésped no se presente. Esto es obligatorio en todas las transacciones en las que Rapid es el intermediario oficial, lo cual puede ocurrir si se aplica la 2FA y el huésped no se presenta.

¿Cómo se puede mitigar el impacto en una integración?

Cuando una integración de Rapid no incluye la 2FA en el flujo de reserva, se puede reducir el riesgo de que se produzca un error en la reserva si no se ofrecen este tipo de alojamientos.

Contacta con el servicio de asistencia para colaboradores de Rapid para eliminar las tarifas de Property Collect afectadas de las respuestas de la API de disponibilidad.

Cuando se utiliza una herramienta para agentes, las transacciones están exentas de 2FA de acuerdo con la normativa. Utiliza el campo sales_channel de la API de disponibilidad para indicarlo.

Resolución de errores

A través de las API de creación de reserva y finalización de la sesión de pago se pueden confirmar reservas y transacciones de pago.

Ten en cuenta las siguientes instrucciones en tu integración para evitar pérdidas económicas y situaciones que involucren una gestión por parte del cliente: