Fraud Prevention Service Sandbox

Fraud Prevention Service supports a Sandbox feature that lets you test APIs in non-production environment. It also allows users to replicate both synchronous and asynchronous recommended decision flows and test the integration with the notification service as it would be expected in production environment.

Getting Access to Sandbox

For detailed information on how to access Sandbox feature and product configuration, read Sandbox. During API client creation step, make sure to search for Fraud Prevention in the list of available products and add the scope to your account.

API Functionalities

Screen Account

The Account Screen API gives a Fraud recommendation for an account transaction. A recommendation can be ACCEPT, CHALLENGE, or REJECT. A transaction is marked as CHALLENGE whenever there are insufficient signals to recommend ACCEPT or REJECT. These CHALLENGE incidents are manually reviewed, and a corrected recommendation is made asynchronously.

Desired recommendations can be emulated based on the email address specified in the request body. Following table lists the email addresses tied to each recommendation flow.

The Account Update API is called when there is an account lifecycle transition such as a challenge outcome, account restoration, or remediation action completion. For example, if a user's account is disabled, deleted, or restored, the Account Update API is called to notify Expedia Group about the change. The Account Update API is also called when a user responds to a login Multi-Factor Authentication based on a Fraud recommendation.

The Account Update API will not work if the corresponding account transaction does not exist, so the Account Screen API must be called first when testing for the Account Update API.

Screen Order Purchase

The Order Purchase Screen API gives a Fraud recommendation for an order purchase transaction. A recommendation can be ACCEPT, REJECT, or REVIEW. A transaction is marked as REVIEW whenever there are insufficient signals to recommend ACEEPT or REJECT. These REVIEW incidents are manually reviewed, and a corrected recommendation is made asynchronously.

Desired recommendations can be emulated based on the email address specified in the request body. Following table lists the email addresses tied to each recommendation flow.

The Order Purchase Update API is called when the status of the order has changed.

For example, if the customer cancels the reservation, changes reservation in any way, or adds additional products or travelers to the reservation, the Order Purchase Update API is called to notify Expedia Group about the change.

The Order Purchase Update API is also called when the merchant cancels or changes an order based on a Fraud recommendation.

The Order Purchase Update API will not work if the corresponding order purchase transaction does not exist, so the Order Purchase Screen API must be called first when testing for the Order Purchase Update API.

Sandbox Specific Features

Invoking recommended decisions

The desired decisions expected in production environment can be replicated within the Sandbox using specific email addresses in request body. This capability allows users to also test asynchronous recommendation flows, where the transactions are manually reviewed and the partners later get a corrected recommendation. Following lists provide the list of email addresses associated with each synchronous and asynchronous recommendation flows.

Screen Account

Order Purchase

Emulating time delay between decision change

In the production environment, there will be a time delay in between decision changes during the asynchronous decision flow. This behavior can be mocked and tested in Sandbox using postfix -delay to the email address, which will add 5 minutes delay to the decision update. This supported feature could be used when testing the integration with the notification service.

e.g. Using email address acceptreject-delay@test.com will emulate decision change from ACCEPT to REJECT with 5 minutes delay between the decision changes.

Testing the integration with the notification service

For detailed information on Notification Service, read Notifications.