Conformidade com regulamentos de autenticação forte do cliente

Entenda as normas de autenticação para pagamentos online com cartão de crédito.

Visão geral

Órgãos reguladores e redes de cartões estão introduzindo novos requisitos para reforçar a segurança dos pagamentos online e proteger os consumidores contra fraudes. Muitas dessas regulamentações incluíram a exigência de usar autenticação forte do cliente (SCA, na sigla em inglês) para pagamentos online.

• Europa: A Diretiva de Serviços de Pagamento Revisada (PSD2) exige o uso de SCA para transações de pagamento online, exceto onde se aplicam isenções específicas ou casos out-of-scope.
• Japão: O mandato SCA do Japão exige o uso de autenticação 3D Secure (3DS) para transações online com cartão de crédito, com isenções para alguns tipos de transação.

O 3D Secure 2 (3DS 2.0) é uma tecnologia desenvolvida pela EMVCo e pela indústria de processamento de pagamentos com cartão como uma solução que garante a conformidade, equilibrando segurança com uma experiência de finalização de compra tranquila. O 3DS 2.0 é a solução utilizada no Rapid API para garantir a conformidade com as regulamentações da SCA (Autenticação Forte do Cliente).

Esta página explica como os tipos de pagamento Rapid API suportados são afetados e quais ações você pode tomar para estar em conformidade ao atender seus viajantes.

Requisitos de conformidade

Os passos para permitir transações em conformidade em países onde a SCA é exigida variam dependendo de quem é o Merchant registrado e de como os pagamentos são feitos para o Rapid API.

Quando sua organização é a Merchant de registro

Expedia Affiliate Collect

As reservas feitas através do Expedia Affiliate Collect não são afetadas pelas regulamentações da SCA (Agência de Contrapartida de Software). Não são necessárias alterações no processo de pagamento ou na integração da API com Merchant para atingir a conformidade.

No entanto, você poderá ser afetado pelas regulamentações se for o Merchant registrado e cobrar do viajante no cartão de crédito, cartão de débito ou outra forma de pagamento que esteja dentro do escopo das regulamentações da SCA. É provável que as regulamentações exijam o uso do 3DS 2.0 como uma solução SCA-compliant no processo de pagamento. Entre em contato com seu processador de pagamentos para saber mais sobre os recursos que ele oferece para ajudar os comerciantes a atingirem a conformidade com a SCA e evitarem transações com falha.

Cartões da empresa

Se a sua empresa for a entidade responsável pelo pagamento e efetuar o pagamento com um cartão de crédito ou débito emitido num país com mandato de SCA (Autenticação Forte do Cliente), estes tipos de cartão estão isentos do requisito de SCA:

• Cartões virtuais de uso único.
• Os cartões corporativos são emitidos para a sua empresa, não para um indivíduo.

Caso os cartões SCA-exempt listados não sejam os mais adequados, sua organização pode solicitar uma isenção diretamente ao banco emissor do cartão. Se uma isenção for concedida, as transações com esse cartão não exigirão autenticação, exceto por uma possível verificação online one-time usando o 3DS 2.0. Esse requisito one-time 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.

Quando Rapid API é o Merchant oficial

Se a sua empresa utiliza Rapid API como o Merchant de registo ao enviar cartões de viajantes para a Rapid, poderá ser afetada pelos regulamentos. Quando os viajantes reservam online, sem um agente de viagens, os regulamentos exigem que as transações de pagamento sejam autenticadas pelo viajante através da Autenticação Forte do Cliente (SCA). O processo SCA-compliant para este requisito é usar o 3DS 2.0 durante o processo de pagamento. Se a sua organização quiser usar Rapid API como o Merchant de registo com quaisquer cartões de crédito ou débito emitidos em países com mandatos SCA, terá de adotar a nossa solução para SCA.

Transações realizadas por meio de um agente de varejo ou de um agente de call center estão isentas da exigência de SCA (Autenticação Forte do Cliente). 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.

Quando o propriedade é o Merchant oficial.

Se a sua empresa utiliza o código propriedade para coleta de dados, poderá ser afetada pelas regulamentações. Existem circunstâncias em que um propriedade pode tentar cobrar no cartão de um viajante sem a presença deste, como taxas de "não comparecimento" ou depósitos. Essas cobranças não são SCA-compliant sem que a autenticação 3DS 2.0 seja realizada antes da cobrança. Se a sua organização quiser usar o código propriedade para coletar dados de viajantes que usam cartões de crédito ou débito emitidos em países com exigências de SCA, você precisará adotar nossa solução para SCA.

A solução Rapid API

Como funciona

Se você usar Rapid API como o Merchant de registro ou usar propriedade para coletar dados com cartões de viagem, poderá adotar a solução de API da Rapid para gerar reservas que estejam em conformidade com as regulamentações da SCA. Nossas APIs oferecem suporte à conformidade com a SCA (Autenticação Forte do Cliente) por meio do uso do 3DS 2.0 no fluxo de reservas. Com o 3DS 2.0, oferecemos suporte à autenticação risk-based, que reduz o atrito com os viajantes, concedendo aos bancos a discricionariedade de decidir quando solicitar a autenticação segura dos viajantes.

A solução para o 3DS 2.0 é composta por três etapas distintas:

1. Você adicionará um iframe à página check-out que é usada para hospedar a experiência de autenticação do banco emissor para o viajante. Na documentação de integração, isso é referido como iframe 3DS.
2. Você também incluirá uma nova biblioteca client-side JavaScript na página check-out, que é usada para coletar dados do navegador, comunicar-se com o iframe e exibir a experiência SCA dentro do iframe. Na documentação de integração, isso é referido como a Biblioteca de Conectores 3DS.
3. Rapid API aceitará as informações do pagador junto ao banco e concluirá a reserva após a autenticação segura ser concluída.

Ao usar JavaScript e Rapid API em conjunto, o fluxo de reservas com SCA agora incluirá algumas etapas adicionais antes e depois da chamada da API de reservas. 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 a Rapid.

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

Detalhes do componente de integração

iframe do navegador

O iframe, inserido na experiência check-out, hospeda um URL pertencente ao banco card-issuing do viajante. Este URL exibirá a experiência de autenticação para o usuário e transferirá quaisquer informações traveler-supplied diretamente para o banco dele. O iframe deve estar inicialmente oculto, com a possibilidade de ser sobreposto à página quando for necessária uma autenticação após uma tentativa de reserva.

Biblioteca JavaScript do navegador

Esta biblioteca é adicionada à página check-out e é invocada no momento da reserva para dar suporte ao processo de autenticação. 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, é necessário coletar informações sobre o dispositivo do viajante para preparar a reserva para autenticação. Essa informação é enviada ao número issuing-bank do viajante para análise, para que o banco possa avaliar o risco, decidir se a autenticação 3DS 2.0 é necessária para a transação e garantir que ela seja exibida corretamente. De acordo com as especificações do 3DS 2.0, os seguintes dados serão coletados do navegador do viajante: idioma, profundidade de cor, altura da tela, largura da tela, fuso horário, agente do usuário e se o Java está habilitado.

Exibir a experiência de autenticação 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 autenticação, o sistema do banco pode coletar informações adicionais sobre o dispositivo do viajante para auxiliar na avaliação de risco. Esse processo é necessário para completar uma reserva.

Rapid API

Rapid API inclui APIs que funcionam em conjunto com a biblioteca client-side JavaScript. As APIs agora são compatíveis com os recursos descritos abaixo.

Cadastro do viajante e informações de pagamento

Antes de tentar efetuar uma reserva, é necessário coletar informações adicionais sobre o viajante para preparar a reserva para autenticação. Esses dados incluem detalhes da conta do viajante no ponto de venda e o pagamento do viajante. Esses dados são posteriormente enviados ao issuing-bank do viajante para revisão, para que o banco possa avaliar o risco e decidir se a autenticação segura é necessária para a transação. Saiba mais consultando a API de Pagamento Registrado, que faz parte do... API de Reserva Rápida.

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

Após uma tentativa de reserva com Rapid API e a conclusão do processo SCA no navegador, o Rapid deve ser invocado mais uma vez. Nos bastidores, confirmaremos se a autenticação foi realmente bem-sucedida para que a reserva possa ser confirmada. Saiba mais consultando a Sessão de Pagamentos Concluídos em API de Reserva Rápida.

Fluxo de reserva

Se o 3DS 2.0 estiver ativado no Suporte Rápido do Perfil do Parceiro, o Verificação de preços A API retornará um link para o Registrar pagamentos API em vez da API Criar Reserva. O diagrama abaixo mostra a sequência de chamadas da API que deve ser realizada depois que uma reserva é iniciada por um viajante. A sequência compreende as chamadas para a biblioteca JavaScript e a Rapid.

Ao preparar uma reserva para autenticação, nem sempre será necessário apresentá-la. A necessidade de autenticação é 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 Criar 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 a documentação de integração para saber mais sobre o fluxo completo da API.

Para obter mais informações sobre os requisitos técnicos da experiência 3DS 2.0, consulte a especificação do protocolo 3D Secure e das funções principais da EMVCo.

Guia de integração do Rapid API e do 3DS 2.0

Para dar suporte ao SCA, será necessário integrar Rapid API com uma nova biblioteca JavaScript, chamada de Conector 3DS. Os dois são usados em conjunto para apresentar o 3DS 2.0 na página check-out e confirmar uma reserva. Essa solução é compatível com os modelos de negócio Expedia Collect e Property Collect.

A sequência de chamadas de API necessárias para efetuar uma reserva com o 3DS 2.0 está descrita abaixo e detalhada nas seções seguintes:

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

Para permitir essa sequência, o 3DS 2.0 deve ser ativado para perfis de parceiros individuais pelo Suporte Rápido a Parceiros.

Rapid API

Se a autenticação estiver habilitada para um perfil de parceiro, as respostas da API serão diferentes para permitir um fluxo de reserva revisado com o 3DS 2.0.

API de Disponibilidade

O valor do campo sales_channelna solicitação da API deve ser preciso para obter uma isenção de autenticação quando permitido pelos regulamentos. Esse valor, juntamente com muitos outros fatores, é analisado pelo banco emissor do cartão para que ele tome sua decisão durante a reserva. Somente as ferramentas de agente estão isentas da SCA. Para especificar isso, defina o valor de sales_channel como 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 o 3DS 2.0 está ativado:

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

API de registro de pagamentos

Este será o segundo passo no fluxo de reserva SCA e ocorre após o método JavaScript setup.

A solicitação incluirá detalhes de pagamento que fazem parte do fluxo de reserva do non-SCA e novos campos que permitem uma autenticação bem-sucedida. Dois desses campos, encoded_browser_metadata e version, são retornados pela API do JavaScript setup 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 de 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"
        }
    ]
}

Resposta de exemplo:

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

Este será o quarto passo no fluxo de reserva SCA e ocorre após o método JavaScript initSession. A solicitação não incluirá nenhum campo novo para SCA — todas as informações necessárias estão contidas no token do link de reserva retornado pela API de Pagamento de Registro. A resposta, se bem-sucedida, sempre vai conter um itinerary_id. No entanto, isso por si só não indica que uma reserva está confirmada, pois a autenticação 3DS 2.0 pode ser necessária.

Se necessário, a resposta também incluirá um encoded_challenge_config. Os valores de encoded_challenge_config e payment_session_id retornados do registro de pagamento precisam ser transmitidos como parâmetros para o método 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 challenge da biblioteca JavaScript.

Se a autenticação 3DS 2.0 não for necessária, a reserva será confirmada e a resposta incluirá links para retrieve, cancele, opcionalmente, resume.

Exemplo de resposta de criação de reserva caso a autenticação 3DS 2.0 seja 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

Este será o sexto passo no fluxo de reserva SCA e ocorre após o método JavaScript challenge. Esta API é necessária para concluir o pagamento e informar Rapid API que uma tentativa de autenticação segura foi concluída, com sucesso ou não.

A solicitação não incluirá nenhum campo novo para SCA.

A resposta, se bem-sucedida, conterá informações de confirmação da reserva, incluindo um itinerary_ide links para retrieve, cancele, opcionalmente,resume.

Resposta de exemplo:

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

Implementação de iframe e da biblioteca JavaScript

Ao usar o fluxo de trabalho de reserva SCA, a página check-out deve incluir um novo iframe e a biblioteca JavaScript. O iframe, denominado iframe 3DS, exibirá a experiência de autenticação usando o 3D-Secure 2.0. 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.

Adicionando o iframe

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 para fins de 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 os testes, o iframe pode ser configurado com o atributo sandbox, mas deve permitir o seguinte:

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

Adicionando 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 de script devem ser definidos com os valores abaixo.

Nota: O URL de origem e a integridade serão 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.

Usando 3DS e JavaScript para SCA

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.

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

Diretrizes de design da página Check-out

As bandeiras de cartões que suportam autenticação 3DS podem exigir que seus logotipos e marcas sejam exibidos de acordo com 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 de conectores 3DS

Classe: ThreeDSConnector

Construtor: new ThreeDSConnector(threeDsIFrameId, threeDsIFrameOrigin)

Parâmetros:

Configuração

Configure a sessão de pagamento coletando detalhes básicos sobre o navegador necessários para o serviço 3DS de backend, como tamanho da tela, profundidade de cor, etc.

Assinatura do método: setup(setupRequest)

Parâmetros:

Retornos: Promessa de um SetupResponse

Inicializar

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

Retornos: Promessa de um InitSessionResponse

Challenge

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

Assinatura do método: challenge(challengeRequest)

Parâmetros:

Retornos: Promessa para um 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 o 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 initSessionresponse statusCode, prossiga com a API de Reserva Rápida.

Classe: ChallengeRequest

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

Propriedades:

Valores possíveis para statusCode

Nota: Para todos os valores de challengeResponse statusCode, prossiga com Rapid API para concluir a sessão de pagamento.

Testando com Rapid API e 3DS 2.0

A sua integração com Rapid API e os métodos do conector 3DS pode ser testada com valores de parâmetros de entrada que correspondem a cenários específicos suportados pelas APIs.

Rapid API

Para testar Rapid API, inclua um cabeçalho HTTP adicional chamadotest Na solicitação HTTP, utilize um dos valores suportados para essa API para testar um cenário compatível.

No fluxo de reserva SCA, as respostas de teste de Rapid API também podem ser usadas para testar os métodos da biblioteca do conector 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 com agendamento rápido Para o fluxo de reserva non-SCA, valores de cabeçalho de teste adicionais são suportados para o fluxo de trabalho SCA.

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

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.

OencodedInitConfig Os valores também podem ser gerados com os cabeçalhos de teste compatíveis com o fluxo SCA da API de Reservas.

Nota: Ao testar o valor do código de status do desafio (SUCESSO ou FALHA) com base na entrada do usuário no iframe, a resposta do método de desafio aguardará a conclusão da interface de autenticação 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 3DS e coleta propriedade

Ao reservar com o código propriedade Collect, a Expedia não cobra nada no cartão. Em vez disso, enviamos para o propriedade para processamento. A propriedade pode usar essas informações para validar o cartão antes do check-in. O viajante deverá efetuar o pagamento pessoalmente no check-in.

No entanto, às vezes, viajantes não conseguem fazer o check-in e as propriedades podem cobrar uma taxa de no show. Essas cobranças podem ser afetadas pelas regulamentações da SCA, pois envolvem a 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 usar a hashtag Expedia Group para fornecer autenticação em seu nome. Isso permite que as propriedades protejam seus negócios e garante que a Rapid API possa continuar oferecendo a mesma gama diversificada de imóveis.

Rapid API fornece o sinalizador de<payment_registration_recommended=true> no arquivo de conteúdo propriedade e no conteúdo propriedade, o que pode ajudá-lo a identificar um propriedade quando ele estiver potencialmente envolvido no projeto.

Possíveis impactos em uma integração

Se você deseja oferecer propriedades que podem exigir autenticação segura, o processo de reserva deve ser compatível com 3DS. Sem suporte para 3DS, a reserva dessas propriedades pode falhar se o banco card-issuing determinar que a autenticação é necessária para a transação.

Quando uma taxa no-show for cobrada pelo propriedade, Rapid API, este será o Merchant de registro. A descrição da cobrança na nota fiscal do cartão será definida pela sua organização, não pelo propriedade. Para personalizar esse texto, entre em contato com o suporte aos parceiros da Rapid.

Para cumprir os requisitos das bandeiras de cartão e o processo de lançamento da campanha Rapid API, utilize a API de Pagamentos Aceitos para exibir oprocessing_country na página check-out em caso de no-show. Isso é necessário para todas as transações em que Rapid API é o Merchant registrado, e pode ocorrer se o 3DS for usado e ocorrer um no-show.

Como mitigar o impacto na integração

Se uma integração Rapid API não suportar autenticação segura no fluxo de reservas, o risco de reservas malsucedidas pode ser reduzido evitando a venda desses imóveis. Entre em contato com o Suporte a Parceiros da Rapid para que as taxas de coleta propriedade afetadas sejam removidas das suas respostas da API de Disponibilidade.

Ao utilizar uma ferramenta de agente, a transação fica isenta de SCA (Autenticação Forte do Cliente) de acordo com os regulamentos. 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: