Sandbox do Fraud Prevention Service

O Fraud Prevention Service oferece suporte a um recurso de sandbox que permite testar APIs em ambientes que não sejam de produção. Ele também permite que os usuários repliquem fluxos de decisão recomendados síncronos e assíncronos e testem a integração com o serviço de notificação como seria esperado no ambiente de produção.

Receber acesso ao Sandbox

Para ter informações detalhadas sobre a maneira de acessar o recurso e a configuração do produto, leia Sandbox. Durante a etapa de criação do cliente de API, busque o Fraud Prevention na lista de produtos disponíveis e adicione o escopo à sua conta.

Funcionalidades das APIs

Verificação de conta

A API de verificação de conta fornece uma recomendação relativa a fraude para transações de conta. A recomendação pode ser ACCEPT (aceitar), CHALLENGE (contestar) ou REJECT (rejeitar). As transações são marcadas como CHALLENGE quando não há sinais suficientes para recomendar ACCEPT ou REJECT. Esses incidentes de CHALLENGE passam por revisão manual, e uma recomendação corrigida é feita de modo assíncrono.

As recomendações desejadas podem ser emuladas com base no endereço de e-mail especificado no corpo da solicitação. A tabela a seguir lista os endereços de e-mail vinculados a cada fluxo de recomendação.

A API de atualização de conta é chamada quando há uma transição no ciclo de vida da conta, como o resultado de uma contestação, a restauração da conta ou a conclusão de uma ação de correção. Por exemplo, se a conta de um usuário for desativada, excluída ou restaurada, a API de atualização de conta será chamada para notificar o Expedia Group sobre a alteração. A API de atualização de conta também é chamada quando um usuário responde a uma autenticação multifator de login com base em uma recomendação relativa a fraude.

A API de atualização de conta não funciona se a transação de conta correspondente não existe. Portanto, a API de verificação de conta deve ser chamada primeiro ao fazer testes com a API de atualização de conta.

Verificação de compra de pedidos

A API de verificação da compra de pedidos fornece uma recomendação relativa a fraude para transações de compra de pedidos. A recomendação pode ser ACCEPT (aceitar), REJECT (rejeitar) ou REVIEW (revisar). As transações são marcadas como REVIEW quando não há sinais suficientes para recomendar ACCEPT ou REJECT. Esses incidentes de REVIEW passam por revisão manual, e uma recomendação corrigida é feita de modo assíncrono.

As recomendações desejadas podem ser emuladas com base no endereço de e-mail especificado no corpo da solicitação. A tabela a seguir lista os endereços de e-mail vinculados a cada fluxo de recomendação.

A API de atualização da compra de pedidos é chamada quando o status do pedido é alterado.

Por exemplo, se o cliente cancelar, fizer alguma alteração ou adicionar produtos ou viajantes à reserva, a API de atualização da compra de pedidos será chamada para notificar o Expedia Group sobre a alteração.

A API de atualização da compra de pedidos também é chamada quando o merchant cancela ou altera um pedido com base em uma recomendação relativa a fraude.

A API de atualização da compra de pedidos não funciona se a transação de compra de pedidos correspondente não existe. Portanto, a API de verificação da compra de pedidos deve ser chamada primeiro ao fazer testes com a API de atualização da compra de pedidos.

Recursos específicos ao sandbox

Invocação de decisões recomendadas

As decisões desejadas que se esperam no ambiente de produção podem ser replicadas no Sandbox usando endereços de e-mail específicos no corpo da solicitação. Esse recurso permite que os usuários também testem fluxos de recomendação assíncronos, em que as transações passam por revisão manual e os parceiros recebem uma recomendação corrigida depois. As listas a seguir mostram os endereços de e-mail associados a cada fluxo de recomendação síncrono e assíncrono.

Verificação de conta

Compra de pedidos

Emular o atraso entre alterações de decisão

No ambiente de produção, vai haver um atraso entre as alterações de decisão durante o fluxo de decisão assíncrono. Esse comportamento pode ser simulado e testado no Sandbox usando o sufixo -delay no endereço de e-mail, o que adiciona 5 minutos de atraso à atualização da decisão. Esse recurso compatível pode ser usado ao testar a integração com o serviço de notificação.

Por exemplo: usar o endereço de e-mail acceptreject-delay@test.com emula a alteração da decisão de ACCEPT para REJECT com um atraso de 5 minutos entre as mudanças.

Testar a integração com o serviço de notificação

Para ler informações detalhadas sobre o serviço de notificação, acesse Notificações.