Cumplimiento de las normativas SCA y PSD2

Conoce la normativa sobre autenticación para los pagos con tarjeta de crédito por Internet

Información general

Las agencias reguladoras y las redes de tarjetas están introduciendo nuevos requisitos para reforzar la seguridad de los pagos en línea y proteger a los consumidores contra el fraude. Muchas de estas normativas han incluido la obligación de utilizar la autenticación reforzada de clientes (SCA) para los pagos en línea.

• Europa: La Directiva revisada sobre servicios de pago (PSD2) exige el uso de la autenticación de alto nivel (SCA) para las transacciones de pago en línea, salvo en los casos en que se apliquen exenciones específicas o casos de « out-of-scope ».
• Japón: La normativa SCA de Japón exige el uso de la autenticación 3D Secure (3DS) para las transacciones con tarjeta de crédito por Internet, aunque hay excepciones para algunos tipos de transacciones.

3D Secure 2 (3DS 2.0) es la solución que se utiliza en Rapid API para garantizar el cumplimiento de la normativa SCA. 3DS 2.0 es una tecnología desarrollada por EMVCo y el sector de procesamiento de pagos con tarjeta como una solución que garantiza el cumplimiento normativo, al tiempo que equilibra la seguridad con una experiencia de pago fluida.

En esta página te explicamos cómo se ven afectados los métodos de pago compatibles con « Rapid API » y qué medidas puedes tomar para cumplir con la normativa a la hora de atender a los viajeros.

Requisitos de cumplimiento

Los pasos para habilitar transacciones que cumplan con la normativa en los países donde se exige la SCA variarán en función de quién sea el « Merchant » registrado y de cómo se realicen los pagos al Rapid API.

Cuando tu organización es la « Merchant » oficial

Expedia Affiliate Collect

Las reservas que utilizan « Expedia Affiliate Collect» no se ven afectadas por la normativa SCA. No hace falta cambiar nada en el proceso de pago ni en la integración de la API con Rapid API para cumplir con la normativa.

Sin embargo, es posible que te veas afectado por la normativa si eres el « Merchant » ( ) registrado y realizas el cargo en la tarjeta de crédito, la tarjeta de débito u otra forma de pago del viajero que entre dentro del ámbito de aplicación de la normativa SCA. Es probable que la normativa exija el uso de 3DS 2.0 como solución de « SCA-compliant » en el proceso de pago. Ponte en contacto con tu proveedor de pagos para saber más sobre cómo pueden ayudar a los comerciantes a cumplir con la normativa SCA y evitar que se produzcan transacciones fallidas.

Tarjetas de empresa

Si tu empresa es el « Merchant » registrado y realiza el pago Rapid API con una tarjeta de crédito o débito emitida en un país en el que se aplica la SCA, estos tipos de tarjetas están exentos del requisito de la SCA:

• Tarjetas virtuales de un solo uso
• Tarjetas de empresa emitidas a nombre de tu empresa, no a nombre de una persona

Si no te convienen las tarjetas de SCA-exempt que aparecen en la lista, tu organización puede solicitar una exención directamente al banco que haya emitido tu tarjeta. Si se concede una exención, las transacciones con esa tarjeta no requerirán autenticación, salvo una posible verificación en línea one-time mediante 3DS 2.0. Este requisito one-time 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.

Cuando « Rapid API » es el « Merchant » que figura en los registros

Si tu empresa utiliza Rapid API como « Merchant » oficial enviando las tarjetas de los viajeros a Rapid, es posible que te veas afectado por la normativa. Cuando los viajeros reservan por internet, sin pasar por un agente de viajes, la normativa exige que el viajero autentifique las transacciones de pago mediante la autenticación de alto nivel (SCA). El proceso de « SCA-compliant » para este requisito consiste en utilizar 3DS 2.0 durante el proceso de pago. Si tu organización quiere utilizar Rapid API como Merchant de referencia para cualquier tarjeta de crédito o débito emitida en países donde la SCA es obligatoria, tendrás que adoptar nuestra solución para la SCA.

>> Descubre nuestra solución para SCA

Las transacciones que se registren a través de un agente minorista o de un agente de un centro de atención telefónica están exentas del requisito de la SCA. 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.

Cuando el propietario que figura en el registro es el Merchant

Si tu empresa utiliza el servicio «Property Collect», es posible que te veas afectado por la normativa. Hay situaciones en las que un establecimiento puede intentar cobrar en la tarjeta de un viajero sin que este esté presente, como en el caso de los recargos por «no presentarse» o los depósitos. Estos cargos no se consideran « SCA-compliant » si no se ha realizado la autenticación 3DS 2.0 antes de realizar el cargo. Si tu organización quiere utilizar el cobro directo a la tarjeta para los viajeros que usen tarjetas de crédito o débito emitidas en países donde la SCA es obligatoria, tendrás que adoptar nuestra solución para la SCA.

>> Descubre nuestra solución para SCA

La solución « Rapid API »

Funcionamiento

Si utilizas Rapid API como Merchant oficial o utilizas Property Collect con tarjetas de viajero, puedes adoptar la solución API de Rapid para generar reservas que cumplan con la normativa SCA. Nuestras API garantizan el cumplimiento de la SCA mediante el uso de 3DS 2.0 en el proceso de reserva. Con 3DS 2.0 admitimos la autenticación « risk-based », que reduce las molestias para los viajeros al dar a los bancos libertad para decidir cuándo solicitarles que se autentiquen de forma segura.

La solución para 3DS 2.0 consta de tres pasos distintos:

1. Vas a añadir un iframe A la página « check-out », que se utiliza para alojar el proceso de autenticación que el banco emisor ofrece al viajero. En la documentación de integración, a esto se le llama «iframe 3DS».
2. También incluirás una nueva biblioteca de client-side JavaScript en la página check-out, que se utiliza para recopilar datos del navegador, comunicarse con el iframe y mostrar la experiencia SCA dentro del iframe. En la documentación de integración, esto se conoce como la biblioteca 3DS Connector.
3. Rapid API aceptará los datos del pagador del banco y completará la reserva una vez que se haya realizado la autenticación segura.

Si usas JavaScript y Rapid API a la vez, el proceso de reserva con SCA ahora 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 introducción. 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, que aparece en la experiencia de check-out, aloja una URL que pertenece al banco del viajero, card-issuing. Esta URL te mostrará el proceso de autenticación y enviará cualquier información de « traveler-supplied » directamente a tu banco. El iframe debería estar oculto al principio, pero con la opción de mostrarlo en la parte superior de la página cuando se pida una autenticación tras intentar hacer una reserva.

Biblioteca de JavaScript en el navegador

Esta biblioteca se añade a la página check-out y se invoca en el momento de la reserva para facilitar el proceso de autenticación. 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 intentar hacer una reserva, hay que recopilar información sobre el dispositivo del viajero para preparar la reserva de cara a la autenticación. Esa información se envía al issuing-bank del viajero para que la revise, de modo que el banco pueda evaluar el riesgo, decidir si la transacción requiere la autenticación 3DS 2.0 y asegurarse de que se muestre correctamente. Según las especificaciones de 3DS 2.0, se recopilarán los siguientes datos del navegador del viajero: idioma, profundidad de color, altura de la pantalla, anchura de la pantalla, zona horaria, agente de usuario y si Java está activado.

Mostrar el proceso de autenticación 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 autenticación, 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 API

Rapid API Incluye API que funcionan junto con la biblioteca client-side JavaScript. Actualmente, las API ofrecen las funciones que se indican a continuación.

Registro del viajero y detalles del pago

Antes de intentar hacer una reserva, hay que recopilar información adicional sobre el viajero para preparar la reserva y poder autentificarla. Estos datos incluyen los detalles de la cuenta del viajero en el punto de venta y el pago que va a realizar. Estos datos se envían después a la issuing-bank del viajero para que los revisen, de modo que el banco pueda evaluar el riesgo y decidir si se necesita una autenticación segura para la transacción. Para saber más, echa un vistazo a la API «Register Payment», que forma parte de la API «Rapid Booking».

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

Después de intentar hacer una reserva en Rapid API y de que se haya completado el proceso SCA en el navegador, hay que volver a abrir Rapid. En segundo plano, comprobaremos que la autenticación se haya realizado correctamente para que se pueda confirmar la reserva. Para saber más, échale un vistazo a la sección «Complete Payments» de la API de Rapid Booking].

Flujo de reserva

Si la versión 3DS 2.0 está activada en «Soporte rápido» del perfil de socio, la API de consulta de precios te mostrará un enlace a la API de registro de pagos en lugar de a la API de creación de reservas. 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.

Cuando se prepara una reserva para su autenticación, puede que no siempre sea necesario. La necesidad de autenticación la decide el banco emisor de la tarjeta de crédito que se usa para el pago. Esta determinación se realiza durante la transacción y se indica en la respuesta de la API de «Crear reserva».

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

>> Más información sobre «Pausar y reanudar»

Nota: Los diagramas anteriores son una simplificación del flujo real de la API y están pensados como introducción. Consulta la documentación de integración para obtener más información sobre el flujo completo de la API.

Si quieres más información sobre los requisitos técnicos para la experiencia 3DS 2.0, echa un vistazo a la guía de EMVCo Especificación del protocolo 3D Secure y de sus funciones principales.

Rapid API y la guía de integración de 3DS 2.0

Para que SCA funcione, habrá que integrar Rapid API con una nueva biblioteca JavaScript, conocida como «3DS Connector». Ambos se usan juntos para mostrar 3DS 2.0 en la página check-out y confirmar una reserva. Esta solución es compatible con ambos modelos de negocio, Expedia Collect y Property Collect.

A continuación te explico la secuencia de llamadas a la API necesarias para gestionar una reserva con 3DS 2.0; la encontrarás detallada 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 que esto funcione, Rapid Partner Support tiene que activar 3DS 2.0 en los perfiles de cada socio.

Rapid API

Si la autenticación está activada para un perfil de socio, las respuestas de la API serán diferentes para permitir un flujo de reserva adaptado a 3DS 2.0.

API de disponibilidad

El valor del campo « sales_channel » en la solicitud de la API debe ser correcto para obtener una exención de autenticación cuando la normativa lo permita. El banco emisor de la tarjeta tiene en cuenta este valor, junto con muchos otros factores, para tomar su decisión durante el proceso de reserva. Solo las herramientas para agentes están exentas de la SCA. 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 3DS 2.0 está activado:

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

API de registro del pago

Este será el segundo paso del proceso de reserva de SCA y se lleva a cabo después del método JavaScript setup.

La solicitud incluirá los datos de pago que forman parte del proceso de reserva de non-SCA, además de nuevos campos que permiten que la autenticación se realice correctamente. 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 que aparece en la respuesta debes usarlo 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": "2027-02-12T11:59:00.000Z",
        "create_date": "2027-09-15",
        "change_date": "2027-09-17",
        "password_change_date": "2027-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": "2027",
            "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": "2027-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 será el cuarto paso del proceso de reserva de SCA y tiene lugar después del método JavaScript initSession. La solicitud no incluirá ningún campo nuevo para SCA. Toda la información necesaria está incluida en el token del enlace de reserva que devuelve la API de registro de pagos. Si es correcta, la respuesta siempre incluirá un itinerary_id. Sin embargo, esto por sí solo no significa que la reserva esté confirmada, ya que puede que se requiera la autenticación 3DS 2.0.

Si es necesario, 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 la autenticación 3DS 2.0, la reserva queda confirmada y la respuesta incluirá enlaces a retrieve, cancely, opcionalmente, resume.

Ejemplo de respuesta «Create Booking» si se requiere la autenticación 3DS 2.0:

{
    "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 será el sexto paso del proceso de reserva de SCA y tiene lugar después del método JavaScript challenge. Esta API es necesaria para completar el pago e informar a Rapid API de que se ha realizado un intento de autenticación segura, tanto si ha tenido éxito como si no.

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

Si la respuesta es correcta, incluirá la información de confirmación de la reserva, como el « itinerary_id » y enlaces a retrieve, cancely, opcionalmente, resume.

Ejemplo de respuesta:

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

Implementación de la biblioteca «JavaScript » en iframes y

Cuando uses el flujo de trabajo de reservas de SCA, la página check-out debe incluir un nuevo iframe y la biblioteca JavaScript. El iframe, conocido como «iframe 3DS», mostrará el proceso de autenticación utilizando 3D-Secure 2.0. 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.

Añadir el iframe

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, puedes añadir el atributo «sandbox» al iframe, pero debe permitir lo siguiente:

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

Añadir la biblioteca JavaScript

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>

Los valores de «source» e «integrity» del elemento «script» deben establecerse en los valores que se indican a continuación.

** Nota:** La URL de origen y la integridad cambiarán a medida que se publiquen nuevas versiones. 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.

Usar 3DS y JavaScript para SCA

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 » forman parte del ejemplo y no de la biblioteca del conector 3DS. 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.

Check-out directrices de diseño de páginas

Las marcas de tarjetas que admiten la autenticación 3DS pueden exigir que sus logotipos y su imagen de marca se muestren siguiendo sus directrices.

Nota: Se irán incluyendo los logotipos y las instrucciones de otras marcas de tarjetas a medida que estén disponibles.

Documentación de la biblioteca de JavaScript 3DS Connector

Clase: ThreeDSConnector

Constructor: new ThreeDSConnector(threeDsIFrameId, threeDsIFrameOrigin)

Parámetros:

Configuración

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

Firma del método: setup(setupRequest)

Parámetros:

Devoluciones: Promesa de un SetupResponse

Inicializar

Inicializa 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:

Devoluciones: Promesa de un InitSessionResponse

Desafío

Inicia el proceso de autenticación de la 3DS, si así lo exige la entidad emisora de la tarjeta.

Firma del método: challenge(challengeRequest)

Parámetros:

Devoluciones: Promesa de un ChallengeResponse

Clase: SetupRequest

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

Propiedades:

Clase: SetupResponse

Respuesta de la llamada de configuración.

Propiedades:

| Nombre Tipo | Descripción | |----|----|----| | version | cadena | La versión de esta biblioteca. Es la misma versión que se puede ver en la ruta URL a la biblioteca. | | encodedBrowserMetadata | cadena | Un objeto codificado que contiene los datos recopilados del navegador. El cliente debe tratarlos como datos opacos que se envían a los servicios de pago de backend sin analizar. |

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 de « initSessionresponse statusCode », utiliza la API de Rapid Booking.

Clase: ChallengeRequest

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

Propiedades:

Posibles valores para statusCode

Nota:. Para todos los valores de « challengeResponse statusCode », sigue con Rapid API para completar la sesión de pago.

Pruebas con « Rapid API » y 3DS 2.0

Puedes probar tu integración con Rapid API y los métodos del conector 3DS utilizando valores de parámetros de entrada que se correspondan con escenarios específicos compatibles con las API.

Rapid API

Para probar Rapid API,, incluye un encabezado HTTP adicional llamado « test » en la solicitud HTTP y utiliza uno de los valores admitidos para esa API con el fin de probar un escenario compatible.

Dentro del proceso de reserva de SCA, también se pueden utilizar las respuestas de prueba de Rapid API para probar los métodos de la biblioteca del conector 3DS.

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: init_skip hay diferentes casos de prueba dentro del 3DS Connector Library.t_configque se pueden pasar a initSessiony forzar un statusCodecon el valor «SKIPPED».

Creación de una reserva

Además de los encabezados de prueba definidos en «Solicitudes de prueba de reserva» para el flujo de reserva « non-SCA », se admiten valores de encabezado de prueba adicionales para el flujo de trabajo de SCA.

>> Explora las solicitudes de prueba de reservas

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 de « encoded_init_config » también se pueden generar con los encabezados de prueba compatibles de la API de «Register Payments».

Desafío

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

Los valores de « encodedInitConfig » también se pueden generar con los encabezados de prueba compatibles con el flujo SCA de la API de reservas.

Nota: Cuando compruebes si el código de estado del desafío es SUCCESS o FAILED en función de lo que introduzcas en el iframe, la respuesta del método de desafío esperará a que termine la interfaz de autenticación simulada en el 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 3DS y recopilación de datos del alojamiento

Al hacer una reserva con «Property Collect», Expedia no realiza ningún cargo en la tarjeta. En lugar de eso, se lo mandamos al edificio para que se encarguen de ello. El alojamiento puede usar esta información para validar la tarjeta antes de la entrada. Se espera que el viajero pague en persona en check-in.

Sin embargo, a veces los viajeros no pueden realizar la entrada y los alojamientos pueden cobrar un cargo por no presentarse. Estas transacciones pueden verse afectadas por la normativa sobre la SCA, ya que implican realizar un cargo en una tarjeta sin que el viajero 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. Las propiedades afectadas ya pueden utilizar Expedia Group para que se encargue de la autenticación en su nombre. Esto permite a los propietarios proteger su negocio y garantiza que Rapid API pueda seguir ofreciendo la misma variada selección de propiedades.

Rapid API Incluye el indicador « <payment_registration_recommended=true> » en el archivo «Property Content» y en «Property Content», lo que te puede ayudar a identificar una propiedad cuando pueda estar relacionada con el proyecto.

Posibles repercusiones en una integración

Si quieres ofrecer alojamientos que puedan requerir una autenticación segura, el proceso de reserva debería ser compatible con 3DS. Si no es compatible con 3DS, la reserva de estos alojamientos podría fallar si el banco card-issuing decide que es necesaria la autenticación para la transacción.

Cuando el alojamiento cobre una tarifa de « no-show », Rapid API será el Merchant que figure en el registro. El nombre que aparecerá en el extracto de la tarjeta como descripción del cargo lo pondrá tu organización, no el alojamiento. Para personalizar este texto, contacta con el servicio de asistencia para colaboradores de Rapid.

Para cumplir con los requisitos de las marcas de tarjetas y el proceso de lanzamiento de « Rapid API », usa la API de «Accepted Payments» para mostrar la página « processing_country » en la página « check-out » en caso de que no-show. Esto es obligatorio para todas las transacciones en las que Rapid API sea el Merchant registrado, y puede ocurrir si se utiliza 3DS y se produce una no-show.

Cómo mitigar el impacto en la integración

Si una integración de Rapid API no admite la autenticación segura en el proceso de reserva, puedes reducir el riesgo de que las reservas fallen dejando de vender esos alojamientos. Ponte en contacto con el servicio de asistencia de Rapid Partner para que se eliminen las tarifas del alojamiento afectado de las respuestas de tu API de disponibilidad.

Cuando se utiliza una herramienta de agente, la transacción queda exenta de la SCA según lo establecido en 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: