Conformidade com regulamentações de autenticação forte do cliente

Entenda os regulamentos de autenticação para pagamentos on-line com cartão de crédito.

Visão geral

Agências reguladoras e redes de cartões estão introduzindo novos requisitos para fortalecer a segurança dos pagamentos on-line e proteger os consumidores contra fraudes. Muitas dessas regulamentações incluíram a exigência de uso de autenticação forte do cliente (SCA) para pagamentos on-line.

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

3D Secure 2 (3DS 2.0) é uma tecnologia desenvolvida pela EMVCo e pelo setor de processamento de pagamentos com cartão como uma solução que garante a conformidade, equilibrando a segurança com uma experiência de checkout tranquila. 3DS 2.0 é a solução usada no Rapid API para fornecer conformidade com os regulamentos da SCA.

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

Requisitos de conformidade

As etapas para habilitar transações compatíveis em países onde o SCA é exigido variam dependendo de quem é o Merchant registrado e como os pagamentos são feitos ao Rapid API.

Quando sua organização é a Merchant registrada

Expedia Affiliate Collect

As reservas que usam o Expedia Affiliate Collect não são afetadas pelos regulamentos da SCA. Não são necessárias alterações no processo de pagamento ou na integração da API com Rapid API para atingir a conformidade.

No entanto, você pode ser afetado pelos regulamentos se for o Merchant registrado e cobrar o cartão de crédito, cartão de débito ou outra forma de pagamento do viajante que esteja dentro do escopo dos regulamentos da SCA. Os regulamentos provavelmente exigem o uso do 3DS 2.0 como uma solução SCA-compliant no processo de pagamento. Entre em contato com seu processador de pagamento para saber mais sobre seus recursos para ajudar os comerciantes a atingir a conformidade com a SCA e evitar transações malsucedidas.

Cartões de empresa

Se sua empresa for a Merchant registrada e pagar Rapid API com um cartão de crédito ou débito emitido em um país com um mandato SCA, estes tipos de cartão estarão isentos do requisito SCA:

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

Se os cartões SCA-exempt listados não forem preferíveis, sua organização pode solicitar uma isenção diretamente ao banco que emitiu seu 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 registrado

Se sua empresa usa Rapid API como Merchant registrado ao enviar cartões de viajantes para a Rapid, você pode ser afetado pelos regulamentos. Quando os viajantes fazem reservas on-line, sem um agente de varejo, os regulamentos exigem que as transações de pagamento sejam autenticadas pelo viajante por meio do SCA. O processo SCA-compliant para esse requisito é usar o 3DS 2.0 durante o processo de pagamento. Se sua organização quiser usar Rapid API como Merchant registrado com quaisquer cartões de crédito ou débito emitidos em países com mandatos SCA, você precisará adotar nossa solução para SCA.

Transações reservadas por meio de um agente de varejo ou de um agente de call center estão isentas do requisito do SCA. 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 registrado

Se sua empresa usa propriedade collect, você pode ser afetado pelas regulamentações. Há circunstâncias em que um propriedade pode tentar cobrar o cartão de um viajante sem a presença dele, como taxas de "não comparecimento" ou depósitos. Essas cobranças não são SCA-compliant sem que a autenticação do 3DS 2.0 seja realizada antes da cobrança. Se sua organização quiser usar o propriedade collect para viajantes que usam cartões de crédito ou débito emitidos em países com mandatos 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 com cartões de viajante, você pode adotar a solução de API da Rapid para gerar reservas que estejam em conformidade com os regulamentos da SCA. Nossas APIs oferecem suporte à conformidade com o SCA usando o 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 ao conceder aos bancos a liberdade de decidir quando desafiar os viajantes a se autenticarem com segurança.

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

1. Você adicionará um iframe à página check-out que é usada para hospedar a experiência de autenticação de um banco emissor para o viajante. Na documentação de integração, isso é chamado de 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 é chamado de Biblioteca de Conectores 3DS.
3. Rapid API aceitará as informações do pagador para o banco e concluirá a reserva após a autenticação segura ser concluída.

Ao usar JavaScript e Rapid API juntos, o fluxo de reserva com SCA agora incluirá algumas etapas adicionais antes e depois da chamada da API de reserva. 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, colocado na experiência check-out, hospeda uma URL de propriedade do banco card-issuing do viajante. Esta URL exibirá a experiência de autenticação ao usuário e transferirá qualquer informação traveler-supplied diretamente para seu banco. O iframe deve ser ocultado inicialmente, com a possibilidade de sobrepô-lo na parte superior da página quando um desafio de autenticação for necessário 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, informações sobre o dispositivo do viajante devem ser coletadas para preparar uma reserva para autenticação. Essas informações são enviadas ao issuing-bank do viajante para revisão, 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 conteúdo do banco pode coletar informações adicionais sobre o dispositivo do viajante para dar suporte à sua 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 uma tentativa de reserva, informações adicionais sobre o viajante devem ser coletadas para preparar uma 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. Para saber mais, analise a API de registro de pagamento na Rapid.

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

Após uma tentativa de reserva com Rapid API e o processo SCA ser concluído 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. Para saber mais, consulte a parte sobre conclusão da sessão de pagamento na Rapid.

Fluxo de reserva

Se o 3DS 2.0 estiver habilitado no Suporte Rápido do Perfil do Parceiro, o Verificação de preço A API retornará um link para o Registrar Pagamentos API em vez de Criar reserva API. 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.

Quando uma reserva é preparada para autenticação, ela nem sempre é necessária. A necessidade de autenticação é determinada pelo banco emissor do cartão de crédito usado para pagamento. Essa determinação ocorre durante a transação e é indicada na resposta da API de 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 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 para a experiência 3DS 2.0, revise o protocolo 3D Secure e a especificação de funções principais da EMVCo.

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

O suporte ao SCA exigirá a integração do Rapid API com uma nova biblioteca JavaScript, conhecida como 3DS Connector. 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 dar suporte a uma reserva com o 3DS 2.0 é descrita abaixo e detalhada nas seções a seguir:

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 habilitado para perfis de parceiros individuais pelo Suporte Rápido para 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 tomar sua decisão durante a reserva. Somente ferramentas de agente estão isentas do 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á habilitado:

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

API de registro de pagamentos

Esta será a segunda etapa no fluxo de reserva do SCA e ocorre após o método JavaScript setup.

A solicitação incluirá detalhes de pagamento que fazem parte do fluxo de reserva non-SCA e novos campos que dão suporte a 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

Esta será a quarta etapa no fluxo de reserva do 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 do 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,cancel e, opcionalmente, resume.

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

Esta será a sexta etapa no fluxo de reserva do 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 da biblioteca Iframe e JavaScript

Ao usar o fluxo de trabalho de reserva do SCA, a página check-out deve incluir um novo iframe e a biblioteca JavaScript. O iframe, conhecido como 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 o teste, o iframe pode ser atribuído com 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 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.

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 marcas de cartão que oferecem suporte à 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 de backend 3DS, como tamanho da tela, profundidade de cor, etc.

Assinatura do método: setup(setupRequest)

Parâmetros:

Retorna: Promessa para um SetupResponse

Inicializar

Inicialize a sessão para autenticação com o 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 um InitSessionResponse

Challenge

Carregue a experiência de autenticação 3DS, se exigido pelo emissor do cartão.

Assinatura do método: challenge(challengeRequest)

Parâmetros:

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

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

Testando com Rapid API e 3DS 2.0

Sua integração com Rapid API e os métodos do conector 3DS podem ser testados 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 chamado testna solicitação HTTP e use um dos valores suportados para essa API para testar um cenário suportado.

No fluxo de reserva do 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 de reserva rápida 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 suportados para o fluxo SCA da API de reservas.

Observação: ao testar o valor do código de status do desafio de SUCESSO ou FALHA com base na entrada do usuário com o 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 propriedade collect, a Expedia não cobra 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á pagar pessoalmente em 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 impactadas pelos regulamentos da SCA porque envolvem a cobrança de 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. Propriedades impactadas agora podem aproveitar Expedia Group para fornecer autenticação em seu nome. Isso permite que as propriedades protejam seus negócios e garante que Rapid API possa continuar a oferecer a mesma gama diversificada de propriedades.

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

Possíveis impactos em uma integração

Se você quiser oferecer propriedades que exijam autenticação segura, o caminho de reserva deve ser compatível com 3DS. Sem suporte ao 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 é cobrada pelo propriedade, Rapid API será o Merchant registrado. O descritor da cobrança no extrato do cartão será definido pela sua organização, não pelo propriedade. Para personalizar esse texto, entre em contato com o suporte aos parceiros da Rapid.

Para permanecer em conformidade com os requisitos das marcas de cartão e o processo de lançamento do Rapid API, use 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 oferecer suporte à autenticação segura no fluxo de reservas, o risco de reservas malsucedidas poderá ser reduzido não vendendo essas propriedades. Entre em contato com o Suporte ao Parceiro Rápido 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 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: