Cumplimiento de la normativa sobre autenticación fuerte de clientes

Comprende las normas de autenticación para los pagos con tarjeta de crédito online.

Información general

Los organismos reguladores 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 el requisito de utilizar la autenticación fuerte del cliente (SCA) para los pagos en línea.

• Europa: La Directiva revisada sobre servicios de pago (PSD2) exige el uso de la SCA para las operaciones de pago en línea, excepto en los casos en que se apliquen exenciones específicas o out-of-scope.
• Japón: El mandato de la SCA de Japón exige el uso de la autenticación 3D Secure (3DS) para las transacciones en línea con tarjeta de crédito, con exenciones para algunos tipos de transacciones.

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

Esta página explica cómo se ven afectados los tipos de pago admitidos en Rapid API y qué medidas puedes tomar para cumplir la normativa cuando atiendas a viajeros.

Requisitos de cumplimiento

Los pasos para permitir las transacciones conformes en los países en los que se exige la SCA variarán en función de quién sea el Merchant de registro y de cómo se realicen los pagos al Rapid API.

Cuando tu organización es el Merchant de registro

Expedia Affiliate Collect

Las reservas que utilizan Expedia Affiliate Collect no se ven afectadas por la normativa SCA. No se necesitan cambios en el proceso de pago ni en la integración de la API con Rapid API para alcanzar la conformidad.

Sin embargo, la normativa puede afectarte si eres el Merchant de registro y cobras la tarjeta de crédito, la tarjeta de débito u otra forma de pago del viajero que esté 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 SCA-compliant en el proceso de pago. Ponte en contacto con tu procesador de pagos para obtener más información sobre sus capacidades para ayudar a los comerciantes a alcanzar el cumplimiento de la SCA y evitar transacciones fallidas.

Tarjetas de empresa

Si tu empresa es el Merchant de registro y paga a Rapid API con una tarjeta de crédito o débito emitida en un país con mandato de SCA, estos tipos de tarjeta están exentos del requisito de SCA:

• Tarjetas virtuales de un solo uso
• Tarjetas corporativas emitidas para tu empresa, no para un particular

Si las tarjetas SCA-exempt de la lista no son preferibles, tu organización puede solicitar una exención directamente al banco que ha 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 de 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 de registro

Si tu empresa utiliza Rapid API como Merchant de registro enviando tarjetas de viaje a Rapid, puede que te afecte la normativa. Cuando los viajeros reservan por Internet, sin un agente minorista, la normativa exige que las transacciones de pago sean autenticadas por el viajero a través de SCA. El proceso SCA-compliant para este requisito es utilizar 3DS 2.0 durante el proceso de pago. Si tu organización quiere utilizar Rapid API como Merchant de registro con cualquier tarjeta de crédito o débito emitida en países con mandatos de SCA, tendrás que adoptar nuestra solución para SCA.

Las transacciones que se reservan a través de un agente minorista o de un agente de un centro de llamadas 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 la propiedad es el Merchant de registro

Si tu empresa utiliza la recaudación de bienes inmuebles, la normativa puede afectarte. Hay circunstancias en las que un establecimiento puede intentar hacer un cargo en la tarjeta de un viajero sin que éste esté presente, como en el caso de las tasas por "no presentarse" o las fianzas. Estos cargos no son SCA-compliant si no se realiza la autenticación 3DS 2.0 antes del cargo. Si tu organización quiere utilizar el cobro en propiedad para viajeros que utilicen cualquier tarjeta de crédito o débito emitida en países con mandatos de SCA, tendrás que adoptar nuestra solución para SCA.

La solución Rapid API

Funcionamiento

Si utilizas Rapid API como Merchant de registro o utilizas la recogida de propiedades con tarjetas de viajero, puedes adoptar la solución API de Rapid para generar reservas que cumplan la normativa SCA. Nuestras API apoyan el cumplimiento de la SCA utilizando 3DS 2.0 en el flujo de reservas. Con 3DS 2.0 admitimos la autenticación risk-based, que reduce la fricción con los viajeros al conceder a los bancos discreción sobre cuándo desafiar a los viajeros a autenticarse de forma segura.

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

1. Añadirás un iframe a la página check-out que se utiliza para alojar la experiencia de autenticación de un banco emisor para el viajero. En la documentación de la integración se denomina iframe 3DS.
2. También incluirás una nueva biblioteca 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 la integración se denomina Biblioteca de conectores 3DS.
3. Rapid API aceptará la información del pagador para el banco y completará la reserva una vez finalizada la autenticación segura.

Cuando se utilicen conjuntamente JavaScript y Rapid API, el flujo de reservas con SCA incluirá ahora 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, colocado en la experiencia check-out, aloja una URL propiedad del banco card-issuing del viajero. Esta URL mostrará la experiencia de autenticación al usuario y transferirá cualquier información de traveler-supplied directamente a su banco. El iframe debe estar oculto inicialmente, con la posibilidad de superponerlo en la parte superior de la página cuando se requiera un reto de autenticación tras un intento de 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 apoyar 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 un intento de reserva, debe recopilarse información sobre el dispositivo del viajero para preparar una reserva para la autenticación. Esa información se envía a la issuing-bank del viajero para que la revise, de modo que el banco pueda evaluar el riesgo, decidir si la autenticación 3DS 2.0 es necesaria para la transacción y asegurarse de que se muestra correctamente. De acuerdo con las especificaciones 3DS 2.0, se recopilarán los siguientes datos del navegador del viajero: idioma, profundidad de color, altura de pantalla, anchura de pantalla, zona horaria, agente de usuario y si Java está activado.

Mostrar la experiencia 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 conjuntamente 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 un intento de reserva, hay que recopilar información adicional sobre el viajero para preparar una reserva para la autenticación. 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 posteriormente a la issuing-bank del viajero para su revisión, de modo que el banco pueda evaluar el riesgo y decidir si se requiere una autenticación segura para la transacción. Obtén más información consultando la API de registro de pagos que forma parte de la API de reservas rápidas.

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

Tras un intento de reserva con Rapid API y completado el proceso SCA en el navegador, Rapid debe ser invocado una vez más. Entre bastidores, confirmaremos que la autenticación se ha realizado correctamente para poder confirmar la reserva. Obtén más información revisando la Sesión Completa de Pagos en la API Rapid Booking.

Flujo de reserva

Si 3DS 2.0 está activado en el Perfil de socio Asistencia rápida, la API Comprobación de precios devolverá un enlace a la API Registrar pagos en lugar de a la API Crear 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.

Cuando se prepara una reserva para la autentificación, puede que no siempre sea necesaria. La necesidad de autenticación la determina el banco emisor de la tarjeta de crédito 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 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.

Para más información sobre los requisitos técnicos de la experiencia 3DS 2.0, consulta la especificación de funciones básicas y protocolo seguro 3D de EMVCo .

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

Para apoyar el SCA será necesario integrar Rapid API con una nueva biblioteca JavaScript, denominada Conector 3DS. Ambos se utilizan conjuntamente para presentar el 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.

La secuencia de llamadas a la API necesarias para admitir una reserva con 3DS 2.0 se describen a continuación y se detallan 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, el servicio de asistencia a socios de Rapid debe habilitar 3DS 2.0 para perfiles de socios individuales.

Rapid API

Si se activa la autenticación para un perfil de socio, las respuestas de la API serán diferentes para permitir un flujo de reservas revisado con 3DS 2.0.

API de disponibilidad

El valor del campo sales_channelde la solicitud API debe ser exacto para obtener una exención de autenticación cuando la normativa lo permita. Este valor, junto con muchos otros factores, es revisado por el banco emisor de la tarjeta para tomar su decisión durante la reserva. Sólo las herramientas de los agentes están exentas del 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 en el flujo de reservas de SCA y se produce después del método JavaScript setup.

La solicitud incluirá los datos de pago que forman parte del flujo de reservas de non-SCA y nuevos campos que permiten una autenticación correcta. 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 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": "/v3/itineraries?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
        }
    }
}

API de creación de reserva

Este será el cuarto paso en el flujo de reservas de SCA y se produce después del método JavaScript initSession. La solicitud no incluirá ningún campo nuevo para SCA---toda la información necesaria está contenida en el token del enlace Reserva devuelto por la API Registrar Pago. Si es correcta, la respuesta siempre incluirá un itinerary_id. Sin embargo, esto por sí solo no indica que la reserva esté confirmada, ya que puede ser necesaria la autenticación 3DS 2.0.

Si se requiere, 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 autenticación 3DS 2.0, la reserva se confirma y la respuesta incluirá enlaces para retrieve, cancely, opcionalmente, resume.

Ejemplo Crear respuesta de Reserva si se requiere 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 en el flujo de reservas de SCA y se produce después del método JavaScript challenge. Esta API es necesaria para completar el pago e informar a Rapid API de que se ha completado un intento de autenticación segura, con éxito o no.

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

La respuesta, si tiene éxito, contendrá información de confirmación de la reserva, incluyendo un itinerary_idy enlaces para retrieve, cancel, y, opcionalmente,resume.

Ejemplo de respuesta:

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

Implementación de la biblioteca Iframe y JavaScript

Cuando utilices el flujo de trabajo de reservas SCA, la página check-out debe incluir un nuevo iframe y la biblioteca JavaScript. El iframe, denominado iframe 3DS, mostrará la experiencia 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, se le puede atribuir un sandbox, 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 origen e integridad del elemento script deben ajustarse a los valores que se indican a continuación.

Nota: La URL de origen y la integridad cambiarán a medida que las futuras versiones estén disponibles para su adopción. 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.

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

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

Las marcas de tarjetas que admiten la autenticación 3DS pueden exigir 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:

Configuración

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

Firma del método: setup(setupRequest)

Parámetros:

Devoluciones: Promesa de SetupResponse

Inicia

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 para un InitSessionResponse

Desafío

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

Firma del método: challenge(challengeRequest)

Parámetros:

Devoluciones: 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 de initSessionresponse statusCode, procede con Rapid Booking API.

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, procede con Rapid API para completar la sesión de pago.

Pruebas con Rapid API y 3DS 2.0

Tu integración con Rapid API y los métodos del conector 3DS pueden probarse con valores de parámetros de entrada que correspondan a escenarios específicos admitidos por las API.

Rapid API

Para probar Rapid API, incluye una cabecera HTTP adicional llamada testen la petición HTTP y utiliza uno de los valores admitidos para esa API para probar un escenario admitido.

Dentro del flujo de reservas SCA, las respuestas de prueba de Rapid API también pueden utilizarse para probar los métodos de la biblioteca de conectores 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: 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 las cabeceras de prueba definidas en Solicitudes de prueba de reserva rápida para el flujo de reserva non-SCA, se admiten valores de cabecera de prueba adicionales para el flujo de trabajo SCA.

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.

Los valores encodedInitConfigtambién pueden generarse con las cabeceras de prueba admitidas para el flujo SCA de la API de Reservas.

Nota: Cuando se comprueba el valor del código de estado de la impugnación ÉXITO o FRACASO basado en la entrada del usuario con el iframe, la respuesta del método de impugnación esperará a que finalice 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 recogida de propiedades

Al reservar con cobro revertido, Expedia no realiza ningún cargo en la tarjeta. En su lugar, lo enviamos al alojamiento para que lo gestione. El alojamiento puede usar esta información para validar la tarjeta antes de la entrada. El viajero deberá pagar 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. Estos cargos pueden verse afectados por la normativa SCA porque implican el cargo en una tarjeta cuando el viajero 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. Las propiedades afectadas pueden ahora aprovechar Expedia Group para proporcionar autenticación en su nombre. Esto permite a los alojamientos proteger su negocio y garantiza que Rapid API pueda seguir ofreciendo la misma gama diversa de propiedades.

Rapid API proporciona la bandera de <payment_registration_recommended=true>en el Fichero de Contenido del alojamiento y en el Contenido del alojamiento, que puede ayudarte a identificar una propiedad cuando esté potencialmente implicada en el proyecto.

Posibles impactos en una integración

Si quieres ofrecer propiedades que puedan requerir una autenticación segura, la ruta de reserva debe admitir 3DS. Sin 3DS de apoyo, la reserva de estas propiedades puede fallar si el banco card-issuing determina que la autenticación es necesaria para la transacción.

Cuando la propiedad cobre una cuota a no-show, Rapid API será el Merchant de registro. El descriptor del cargo en el extracto de facturación de la tarjeta lo definirá tu organización, no la propiedad. Para personalizar este texto, contacta con el servicio de asistencia para colaboradores de Rapid.

Para seguir cumpliendo los requisitos de las marcas de tarjetas y el proceso de lanzamiento de Rapid API, utiliza la API de Pagos Aceptados para mostrar processing_countryen la página check-out en caso de no-show. Esto es necesario para todas las transacciones en las que Rapid API es el Merchant de registro, y puede ocurrir si se utiliza 3DS y se produce un 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 flujo de reservas, el riesgo de reservas fallidas puede reducirse no vendiendo estas propiedades. Ponte en contacto con el Servicio de Atención al Socio de Rapid para que eliminen las tarifas de recogida de propiedades afectadas de tus respuestas de la API de Disponibilidad.

Cuando se utiliza una herramienta de agente, la transacción está exenta de SCA 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: