Conformidade com a PSD2 europeia

Entenda o impacto do novo regulamento de pagamento com cartão do EEE nos seus negócios

Visão geral

A Diretiva de serviços de pagamento 2 (PSD2) é um regulamento do Espaço Econômico Europeu (EEE) que exige alterações no processo de pagamento e reserva para todas as transações envolvendo um cartão de crédito emitido por um estado do EEE.

A PSD2 aumenta a segurança e reduz a fraude, mas também muda de maneira fundamental como os pagamentos funcionam em toda a Europa. Como parte desses regulamentos, é necessária uma solução de autenticação forte do cliente ao lidar com pagamentos eletrônicos de consumidores dentro do escopo dos regulamentos. Todos as emissoras de cartão, bancos e merchants são obrigados a oferecer suporte a uma solução de autenticação forte do cliente. A não conformidade vai resultar em falhas no pagamento, pois os regulamentos estão em vigor nos bancos do EEE.

Esta página explica como os tipos de pagamento aceitos pelo Rapid são afetados e quais ações os parceiros podem tomar para manter a conformidade ao atender os seus viajantes. Para mais informações sobre a diretiva, consulte a legislação no site oficial da Comissão Europeia.

Requisitos de conformidade

As etapas para habilitar transações compatíveis no EEE variam dependendo de quem é o Merchant of Record e de como os pagamentos são feitos no Rapid.

O parceiro é o Merchant of Record

Expedia Affiliate Collect

As reservas que usam o EAC não são afetadas pelos regulamentos da PSD2. Nenhum processo de pagamento ou alterações na integração da API com o Rapid são necessários para manter a conformidade. No entanto, os regulamentos podem afetar você se for o Merchant of Record e realizar cobranças em cartão de crédito, cartão de débito ou outra forma de pagamento dos viajantes dentro do escopo dos regulamentos da UE. É provável que os regulamentos exijam que você ofereça suporte para uma versão da autenticação de dois fatores, ou 2FA, compatível com a PSD2 no processo de pagamento. Entre em contato com o seu processador de pagamento para saber mais sobre os recursos disponíveis para ajudar os merchants a estar em conformidade com a PSD2 e evitar transações com falha.

Cartões de parceiros

Se a sua empresa é o Merchant of Record e paga o Rapid com um cartão de crédito ou débito da sua empresa emitido pelo EEE, esses regulamentos podem afetar você. A lista de cartões compatíveis com a PSD2 é:

• Cartões virtuais de uso único emitidos no EEE.
• Cartões corporativos emitidos para a sua empresa, não para um indivíduo, no EEE.
• Qualquer cartão emitido fora do EEE.

Os regulamentos podem afetar você se realizar cobranças em cartão de crédito, cartão de débito ou outra forma de pagamento de viajantes dentro do escopo dos regulamentos do EEE. É provável que os regulamentos exijam que você ofereça suporte para uma versão da autenticação de dois fatores, ou 2FA, compatível com a PSD2 no processo de pagamento. Entre em contato com o seu processador de pagamento para saber mais sobre os recursos disponíveis para ajudar os merchants a estar em conformidade com a PSD2 e evitar transações com falha.

Se preferir não usar os cartões de parceiro compatíveis com a PSD2 acima, a sua organização pode solicitar uma isenção direto ao banco que emitiu o seu cartão de parceiro. Se uma isenção for concedida, as transações nesse cartão não vão exigir autenticação, exceto para uma possível verificação on-line única usando 2FA. Essa verificação única pode variar de acordo com o banco. Receber uma isenção pode ser um processo demorado e também significa que o seu banco pode responsabilizar você por quaisquer pagamentos fraudulentos.

Rapid é o Merchant of Record

Se a sua empresa usa o Rapid como Merchant of Record ao enviar cartões de viajantes para o Rapid, os regulamentos podem afetar você. Quando os viajantes reservam on-line, sem um agente de varejo, os regulamentos exigem que o Rapid permita aos viajantes confirmar se iniciaram o pagamento. O processo em conformidade com a PSD2 para este requisito é a autenticação de dois fatores, ou 2FA, durante o processo de pagamento. Os parceiros que desejam usar o Rapid como Merchant of Record com qualquer cartão de crédito ou débito emitido pelo EEE precisam adotar a nossa solução Rapid para 2FA disponível no Rapid v2.2+.

No entanto, as transações reservadas por meio de um agente de varejo ou agente da central de atendimento estão isentas do requisito 2FA. A conformidade para essas transações exige apenas uma indicação explícita de que essa reserva foi feita com a assistência de um agente. Use o campo sales_channel da API de disponibilidade para essa indicação.

A propriedade é o Merchant of Record

Se a sua empresa usa o Property Collect, os regulamentos podem afetar você. Há circunstâncias em que uma propriedade pode tentar cobrar o cartão de um viajante que não está presente, por exemplo, taxas de no show ou depósitos. Para que essas cobranças estejam em conformidade com os regulamentos, a autenticação de dois fatores, ou 2FA, deve ser realizada antes da cobrança. Os parceiros que desejam usar o Property Collect para viajantes usando um cartão de crédito ou débito emitido pelo EEE precisam adotar a nossa solução Rapid para 2FA disponível no Rapid v2.2+.

Visão geral da solução do Rapid

Como funciona?

Os parceiros que usam o Rapid Merchant of Record ou Property Collect com cartões de viajantes podem adotar a solução da Rapid API para gerar reservas em conformidade com os regulamentos. As APIs oferecem conformidade com a PSD2 ao oferecer suporte à autenticação de dois fatores com 3DS 2.0 no fluxo de reserva. Com o 3DS 2.0, oferecemos suporte à autenticação baseada em risco, o que reduz o atrito com os viajantes ao deixar a critério do banco quando solicitar a 2FA aos viajantes.

A solução para 2FA é composta por três componentes distintos:

• Um iframe que os parceiros adicionam à página de pagamento. Ele é usado para hospedar a experiência de 2FA de um banco emissor para o viajante. Na documentação de integração, é chamado de iframe 3DS.
• Uma nova biblioteca JavaScript no lado do cliente na página de pagamento. Ela é usada para coletar dados do navegador, comunicar-se com o iframe e exibir a experiência de 2FA no iframe. Na documentação de integração, é chamada de biblioteca de conectores 3DS.
• O Rapid aceita as informações do pagador para o banco e conclui a reserva após a 2FA.

Ao usar JavaScript e Rapid juntos, o fluxo de reservas com 2FA agora vai incluir algumas etapas extras antes e depois que a API de reservas for chamada. O diagrama abaixo descreve esse fluxo de reservas atualizado.

Durante cada etapa do fluxo de reservas revisado, o resultado de uma etapa contém dados que vão ser inseridos na próxima etapa. Os dados precisam ser passados entre o JavaScript no navegador e o Rapid.

Observação: o diagrama acima é uma simplificação do fluxo real da API para fazer uma introdução. Consulte o documento de integração para saber mais sobre o fluxo completo da API.

Detalhes do componente de integração

iframe do navegador

O iframe, posicionado na experiência da página de pagamento, hospeda um URL de propriedade do banco emissor do cartão do viajante. Esse URL vai exibir a experiência de 2FA para o usuário e transferir qualquer informação fornecida pelo viajante direto para o banco. A princípio, o iframe deve estar oculto, com a capacidade de se sobrepor ao topo da página em forma de pop-up quando a 2FA for solicitada após uma tentativa de reserva.

Biblioteca JavaScript do navegador

Essa biblioteca é adicionada à página de pagamento e é chamada no momento da reserva para dar suporte ao processo de 2FA. As APIs da biblioteca são compatíveis com os recursos descritos abaixo.

Coleta automática de informações do dispositivo do viajante

Antes de uma tentativa de reserva, as informações sobre o dispositivo do viajante devem ser coletadas para preparar uma reserva para a 2FA. Depois, são enviadas ao banco emissor do viajante para análise, para que o banco possa avaliar o risco, decidir se a 2FA é necessária para a transação e garantir que ela seja exibida da maneira correta. De acordo com as especificações do 3DS 2.x, os seguintes dados serão coletados do navegador do viajante: idioma, profundidade de cor, altura da tela, largura da tela, fuso horário, agente de usuário e se o Java está ativado.

Mostrar a experiência de 2FA no iframe do navegador

Após uma tentativa de reserva, a biblioteca é usada para exibir o pop-up do iframe e carregar o conteúdo do banco no iframe.  Durante o processo de 2FA, o conteúdo do banco pode coletar outras informações sobre o dispositivo do viajante para dar suporte à sua avaliação de risco. Esse processo é necessário para completar uma reserva.

Rapid

As versões Rapid v2.2 e superiores incluem novas APIs que funcionam em conjunto com a biblioteca JavaScript no lado do cliente.  As APIs agora são compatíveis com os recursos descritos abaixo.

Cadastro do viajante e informações de pagamento

Antes de uma tentativa de reserva, novas informações sobre o viajante devem ser coletadas para preparar uma reserva para a 2FA. Esses dados incluem detalhes da conta do viajante no ponto de venda e o pagamento do viajante. Depois, os dados são enviados ao banco emissor do viajante para análise, para que o banco possa avaliar o risco e decidir se a 2FA é necessária para a transação. Para saber mais, analise a API de registro de pagamento no Rapid v2.2+.

Conclusão de um pagamento e confirmação de reserva

Após uma tentativa de reserva com o Rapid e o processo de 2FA ser concluído no navegador, o Rapid deve ser invocado mais uma vez. Nos bastidores, vamos confirmar que a 2FA foi de fato bem-sucedida, para que a reserva possa ser confirmada. Saiba mais revisando a página Concluir sessão de pagamentos no Rapid v2.2+.

Fluxo de reserva

Visão geral

Se a 2FA estiver ativada no suporte ao perfil do parceiro Rapid, a API de verificação de preço vai retornar um link para a API registro de pagamentos em vez da API criação de reserva. O diagrama abaixo mostra a sequência de chamadas da API que deve ser realizada depois que uma reserva for iniciada por um viajante. A sequência compreende as chamadas para a biblioteca JavaScript e o Rapid.

Quando uma reserva é preparada para a 2FA, a autenticação nem sempre é necessária. A necessidade da 2FA é determinada pelo banco emissor do cartão de crédito utilizado para o pagamento. Essa determinação ocorre durante a transação e é indicada na resposta da API criação de reserva.

O diagrama abaixo exibe a sequência de chamadas da API que deve ser realizada ao usar a Espera e retomada.

Observação: os diagramas acima são uma simplificação do fluxo real da API para fins introdutórios. Consulte o documento de integração para saber mais sobre o fluxo completo da API.

Mais informações

Para mais informações sobre os requisitos técnicos para a experiência de 2FA, revise o protocolo 3D Secure da EMVCo e a especificação das funções principais

Guia de integração de autenticação de dois fatores e do Rapid

Visão geral

O suporte à autenticação de dois fatores, ou 2FA, exige a integração com uma nova biblioteca JavaScript, chamada de biblioteca do conector 3DS, e com o Rapid.  Os dois são usados em conjunto para apresentar a 2FA na página de pagamento e confirmar uma reserva.  Essa solução inclui os modelos de negócio Expedia Collect e Property Collect.

A sequência de chamadas da API que deve ser realizada para dar suporte a uma reserva com a 2FA é descrita abaixo e detalhada nas seções a seguir.

1. Método de configuração do JavaScript
2. API de registro de pagamento do Rapid
3. Método de inicializar sessão do JavaScript
4. API de reserva do Rapid
5. Método de desafio do JavaScript
6. API de conclusão de pagamento do Rapid

Para permitir essa sequência, a 2FA deve ser habilitada para perfis de parceiros individuais pelo suporte aos parceiros do Rapid.

Rapid

Se a autenticação de dois fatores estiver habilitada para um perfil de parceiro, as respostas da API serão diferentes para permitir um fluxo de reserva revisado com a 2FA.

API de disponibilidade

O valor do campo sales_channel na solicitação de API deve ser preciso para receber uma isenção da 2FA quando permitido pelos regulamentos. Esse valor, junto com muitos outros fatores, é analisado pelo banco emissor do cartão para tomar uma decisão no momento da reserva. Apenas ferramentas de agente estão isentas da 2FA. Para especificar isso, defina o valor de sales_channel para agent_tool.

API de verificação de preço

A resposta da API vai incluir um link para a API de registro de pagamentos em vez da API de criação de reserva.

Exemplo de resposta quando a 2FA está ativada:

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

API de registro de pagamentos

Essa é a segunda etapa no fluxo de reserva JavaScript-Rapid PSD2 e ocorre após o método setup do JavaScript.

A solicitação vai incluir as informações de pagamento que fazem parte do fluxo de reserva que não é PSD2 e novos campos que dão suporte a uma 2FA bem-sucedida. Dois desses campos, encoded_browser_metadata e version, são retornados pela API do JavaScriptsetup method.

A resposta vai incluir a payment_session_id e a encoded_init_config. Elas são inseridas no método initSession da biblioteca JavaScript. O link da reserva incluído na resposta deve ser usado após o método initSession.

Exemplo de solicitação:

{
    "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"
        }
    ]
}

Exemplo de resposta:

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

API de criação de reserva

Essa é a segunda etapa no fluxo de reserva JavaScript-Rapid PSD2 e ocorre após o método de initSession do JavaScript. A solicitação não vai incluir novos campos para a PSD2, todas as informações necessárias estão contidas no token do link Reservar retornado pela API de registro de pagamento. A resposta, se bem-sucedida, sempre vai conter um itinerary_id. No entanto, isso por si só não indica que uma reserva foi confirmada porque a 2FA pode ser necessária.

Se a 2FA for necessária, a resposta também vai incluir um encoded_challenge_config. Os encoded_challenge_config e payment_session_id retornados de registro de pagamento vão precisar ser passados como parâmetros para o método de challenge do JavaScript.

A resposta também vai incluir um novo link para complete_payment_session. Esse link deve ser usado após o método de challenge da biblioteca JavaScript.

Se a 2FA não for necessária, a reserva vai ser confirmada e a resposta vai incluir links para retrieve, cancel e, de maneira opcional, resume.
Exemplo de Resposta de Criação de Reserva se a 2FA for necessária:

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

API de conclusão de sessão de pagamento

Essa é a sexta etapa no fluxo de reserva JavaScript-Rapid PSD2 e ocorre após o método de challenge do JavaScript. Essa API é necessária para concluir o pagamento e informar ao Rapid que uma tentativa de 2FA foi concluída, com sucesso ou não.

A solicitação não vai incluir novos campos para a PSD2.

A resposta, se bem-sucedida, vai conter um itinerary_id e links para retrieve, cancele, de maneira opcional, resume. Uma resposta bem-sucedida de que uma reserva foi confirmada.

Exemplo de resposta:

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

Biblioteca JavaScript do conector 3DS e iframe 3DS

Ao usar o fluxo de trabalho de reserva PSD2, a página de pagamento deve incluir um novo iframe e biblioteca JavaScript.  O iframe, chamado iframe 3DS, vai exibir a experiência de autenticação usando o 3D-Secure 2.x para o viajante. A biblioteca JavaScript, conhecida como biblioteca de conectores 3DS, vai dar suporte à transferência de informações para bancos emissores e carregar o conteúdo dos bancos no iframe.

Adição do iframe 3DS e da biblioteca JavaScript

Como adicionar o iframe do 3DS

O iframe 3DS deve ser encapsulado em um contêiner a princípio oculto, mas que pode ser exibido quando uma autenticação for necessária para processar um pagamento.

O design do contêiner pode ser personalizado para se adequar à página de hospedagem. Abaixo vemos um exemplo de implementação destinado apenas a orientação, usando um modal de bootstrap:

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

A origem do iframe deve ser definida para um dos dois valores:

O URL de teste oferece suporte a testes e esse tópico é analisado depois neste documento. Para restringir o conteúdo do iframe durante o teste, o iframe pode ser atribuído com o sandbox, mas deve permitir o seguinte:

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

Como adicionar o iframe 3DS e a biblioteca JavaScript

A biblioteca de conectores 3DS se comunica com o iframe 3DS e envia dados ao banco emissor, que fornece o conteúdo do iframe. Abaixo vemos um exemplo de como adicionar a biblioteca à página de pagamento.

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

Os valores de origem e integridade do elemento script devem ser definidos para os valores abaixo:

Observação: o URL de origem e a integridade vão ser alterados à medida que versões futuras estiverem disponíveis para adoção. Versões mais recentes não devem interromper a integração existente. Versões mais antigas do script ainda vão estar acessíveis.

Como usar o iframe 3DS e a biblioteca JavaScript

A biblioteca requer o uso de JavaScript Promises. Abaixo é mostrado um exemplo de implementação destinado apenas para orientação e uma demonstração de como os dados são transferidos entre os métodos JavaScript e a 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 => {
    ...
  });

Observação: as referências à classe RapidIntegration fazem parte do exemplo e não da biblioteca de conectores 3DS. Elas servem para demonstrar um wrapper que permite a transferência de informações para as APIs.

Observação: o exemplo usa valores estáticos para parâmetros que devem ser determinados no tempo de execução, por exemplo, referenceId.

Diretrizes da página de pagamento

As marcas de cartão que dão suporte a 2FA podem exigir que os seus logotipos e as suas marcas sejam exibidos de acordo com as suas diretrizes.

Observação: logos e orientações para outras marcas de cartão serão incluídos à medida que estiverem disponíveis.

Documentação da biblioteca JavaScript do conector 3DS

Classe: ThreeDSConnector

Construtor

new ThreeDSConnector(threeDsIFrameId, threeDsIFrameOrigin)

Parâmetros:

Método

Configuração

Configure a sessão de pagamento ao coletar os detalhes básicos sobre o navegador que o serviço 3DS de back-end precisa, como tamanho da tela, profundidade de cor etc.

Assinatura do método:

setup(setupRequest)

Parâmetros:

Retorna:

Promessa de SetupResponse

Sessão de inicialização

Inicializa a sessão para autenticação com 3DS. Como parte da inicialização, outros dados podem ser coletados do navegador. Se solicitado pela emissora do cartão, um URL de método 3DS pode ser carregado no iframe para permitir que o servidor de controle de acesso da emissora do cartão colete dados direto do navegador. O cliente não precisa esperar o callback de conclusão ser invocado para que o pedido seja criado.

Assinatura do método:

initSession(initSessionRequest)

Parâmetros:

Retorna: promessa de InitSessionResponse

Challenge

Carrega a experiência de autenticação 3DS, se exigida pela emissora do cartão.

Assinatura do método:

challenge(challengeRequest)

Parâmetros:

Retorna: promessa de ChallengeResponse

Classe: SetupRequest

Estrutura de solicitação para a chamada de configuração.

Propriedades:

Classe: SetupResponse

Resposta da chamada de configuração.

Propriedades:

Classe: InitSessionRequest

Estrutura de solicitação para método initSession.

Propriedades:

Classe: InitSessionResponse

Estrutura de resposta para o método initSession.

Propriedades:

Valores possíveis para statusCode:

Observação: para todos os valores de statusCode de initSessionresponse, continue com a API de reserva da Rapid.

Classe: ChallengeRequest

Estrutura de solicitação para o método Challenge.

Propriedades:

Valores possíveis para statusCode

Observação: para todos os valores de statusCode de challengeResponse, prossiga com a Rapid para concluir a sessão de pagamento.

Testes com a Rapid e a autenticação de dois fatores

A sua integração com os métodos Rapid e conector 3DS pode ser testada com valores de parâmetro de entrada que correspondem a situações específicas suportadas pelas APIs.

Rapid

Para testar o Rapid, inclua mais um cabeçalho HTTP chamado Teste na solicitação HTTP e use um dos valores compatíveis com essa API para testar uma situação compatível.

Dentro do fluxo de reserva PSD2, as respostas de teste do Rapid também podem ser usadas para testar os métodos da biblioteca de conectores 3DS.

Registrar pagamentos

Os seguintes valores de cabeçalho de teste resultam em diferentes valores de encoded_init_config na resposta da API e diferentes códigos de resposta HTTP. É possível transmitir encoded_init_config à chamada initSession da biblioteca JavaScript para acionar diferentes casos de teste da biblioteca de conectores 3DS.

Observação: diferentes casos de teste de init_skip na biblioteca de conectores 3DS Library.t_config que podem ser transmitidos a initSession e forçar um statusCode de SKIPPED

Criar reserva

Além dos cabeçalhos de teste definidos em Solicitações de teste de reserva do Rapid para o fluxo de reserva que não é PSD2, há suporte para valores de cabeçalho de teste adicionais para o fluxo de trabalho PSD2.

Os valores do cabeçalho de teste resultam em valores encodedChallengeConfig diferentes que podem ser passados para a chamada challenge da biblioteca JavaScript para acionar diferentes casos de teste.

Concluir sessão de pagamento

Os valores do cabeçalho de teste resultam em diferentes casos de erro que podem ocorrer ao tentar concluir um pagamento e confirmar uma reserva.

Biblioteca de conectores 3DS e iframe

Para testar o conector 3DS sem dependências externas, valores de parâmetros específicos correspondem às respostas de método com suporte. Esse comportamento só tem suporte quando o iframe é carregado com o teste do URL do Sandbox.

Inicializar sessão

Os valores compatíveis do InitSessionResponse statusCode podem ser testados variando o initSessionRequest encodedInitConfig.

Observação: os valores encoded_init_config também podem ser gerados com os cabeçalhos de teste compatíveis da API de registro de pagamentos.

Challenge

Os valores compatíveis do challengeResponse statusCode podem ser testados variando o challengeRequest encondedChallengeConfig.

Observação: os valores encodedInitConfig também podem ser gerados com os cabeçalhos de teste compatíveis com o fluxo PSD2 da API de reserva.

Observação: ao testar o valor do código de status do Challenge de SUCCESS ou FAILED com base na contribuição do usuário com o iframe, a resposta do método Challenge vai aguardar a conclusão da autenticação da UI (interface do usuário) simulada no iframe.

Exemplo de UI (interface do usuário) em iframe 3DS:

Exemplo de uso

Abaixo vemos um exemplo de implementação destinado apenas a orientação. O exemplo demonstra como usar os valores de parâmetro predefinidos para testar a biblioteca para um desafio 3DS sem que o usuário precise interagir com o 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
    });

Autenticação de dois fatores e Property Collect

Sobre a autenticação de dois fatores para Property Collect

Nas reservas com Property Collect, a Expedia não realiza uma cobrança no cartão, apenas encaminha para tratamento pela propriedade. A propriedade pode usar essas informações para validar o cartão antes do check-in. O viajante deve realizar o pagamento no momento do check-in.

No entanto, às vezes os viajantes não conseguem fazer o check-in e as propriedades podem cobrar uma taxa de no show. Essas cobranças podem ser afetadas pelos regulamentos da PSD2 porque envolvem realizar uma cobrança em um cartão quando o viajante não está presente.

Se as transações forem afetadas, os pagamentos podem falhar ou as propriedades podem enfrentar penalidades das marcas de cartão se a cobrança não estiver em conformidade.

Para proteger o nosso relacionamento com as propriedades e continuar atendendo os nossos parceiros, o Expedia Group está oferecendo às propriedades um caminho opcional para a conformidade. As propriedades afetadas agora podem aproveitar a 2FA oferecida pelo Expedia Group. Isso permite que as propriedades protejam os seus negócios e garante que o Rapid possa continuar a oferecer propriedades diversificadas.

O Rapid 2.4+ fornece o sinalizador de <payment_registration_recommended=true> no arquivo de conteúdo da propriedade e no conteúdo da propriedade, que pode ajudar você a identificar uma propriedade que pode estar envolvida no projeto.

Observação: apenas propriedades dentro do Espaço Econômico Europeu, ou EEE, se qualificam para a 2FA.

Observação: o conjunto de propriedades que pode exigir a 2FA não é estático – ele pode crescer à medida que outras propriedades optam por habilitar esse recurso. Esse atributo de uma propriedade está disponível no Rapid Content v.2.4.

Como a 2FA para Property Collect pode afetar uma integração?

Se um parceiro quiser oferecer propriedades que possam exigir a 2FA, o caminho de reserva vai oferecer suporte a 2FA. Sem suporte a 2FA, a reserva dessas propriedades pode falhar se o banco emissor do cartão determinar que a 2FA é necessária para a transação, como em cartões emitidos no EEE.

Quando uma taxa de no show for cobrada pela propriedade, o Rapid vai ser o Merchant of Record. A descrição da cobrança na fatura do cartão não vai ser definida pela propriedade. O valor da descrição é definido pelo parceiro. Para personalizar este texto, entre em contato com o suporte aos parceiros da Rapid.
Para manter a conformidade com os requisitos das marcas de cartão e o processo de inicialização da Rapid, use a API de pagamentos aceitos para exibir processing_country na página de pagamento em caso de no show. Isso é necessário para todas as transações em que a Rapid é o Merchant of Record e pode ocorrer se a autenticação de dois fatores for usada e ocorrer um no show.

Como os impactos em uma integração podem ser mitigados

Se uma integração Rapid não oferecer suporte a 2FA no fluxo de reservas, o risco de reservas com falha pode ser reduzido ao não vender as propriedades.

Entre em contato com o suporte aos parceiros do Rapid para remover as tarifas Property Collect afetadas das respostas da API de disponibilidade.

De acordo com os regulamentos, ao usar uma ferramenta de agente, a transação está isenta de 2FA. Use o campo sales_channel da API de disponibilidade para indicar isso.

Tratamento de erros

A API de criação de reserva e a API de conclusão de sessão de pagamento podem resultar em reservas confirmadas e transações de pagamento.

A sua integração deve considerar as seguintes instruções para evitar perdas financeiras e casos de operação de cliente: