Integrate a fraud check provider

General

Welcome to SCAYLE’s tutorial on integrating a fraud check provider. In today's world of online business, it's crucial to protect against fraudulent activities. It can cause financial losses, endanger customer data, and damage your brand's reputation. That's why integrating a fraud check provider is a key step in safeguarding your operations.

This tutorial will guide you through the process of integrating a fraud check provider seamlessly into SCAYLE. We will explore the necessary steps, offer best practices, and important considerations to ensure a successful setup. By the end of this guide, you'll be equipped with the skills to enhance your fraud prevention strategy, creating a secure environment for your business and customers.

Understand the interaction between SCAYLE and an external fraud check provider

SCAYLE offers a generic API, tailored for integration with an external fraud check provider. Once set up, SCAYLE initiates a request to the configured downstream service before confirming any order.

The process is outlined in the model below:

Interaction between SCAYLE and an external fraud check provider

An essential aspect of this setup is the necessity of an external fraud check provider. While SCAYLE efficiently handles risk check requests and manages responses, it requires a dedicated service to compute the fraud check result. Typically, an adapter bridges SCAYLE and the fraud check provider, facilitating seamless integration between the two systems.

In the process outlined in the diagram above, SCAYLE invokes a generic API whenever a customer attempts to confirm an order. The API request, as detailed in the next chapter, is first processed by the adapter. This adapter translates the request for the fraud check provider and then relays the provider’s response back to SCAYLE.

Once SCAYLE receives this response, it triggers the Automated Risk Assessment rules. These rules can block the order confirmation, redirecting the customer back to the previous step of the checkout process if necessary. The details and functionality of the Rule Engine, particularly in the context of Automated Risk Checks, are described in the next section. If no rule intervenes, the order progresses to confirmation, leading the user to the order success page.

In the SCAYLE Panel

Configure fraud check

In SCAYLE, you can tailor the fraud check feature for each shop country via the SCAYLE Panel. This flexibility allows you to implement the fraud check in specific countries, such as Germany, while opting not to use it in others like Austria.

To configure, follow these steps:

Navigate to Shops > [Shop Name] > Select country
Navigate to Storefront > Checkout Settings > Checkout Frontend Configuration > API Credentials
Input the complete URL of the webservice, along with the username and, if needed, a password. SCAYLE supports basic authentication for this process.
Click on Save.
To activate the feature across your platform, set the property ruleEngine.riskassessment to true. This is done at the tenant level and can be managed through the import feature, detailed at our User Guide.

Congratulations! You have successfully configured the fraud check. Next, let’s delve into the specific request process that SCAYLE will execute for every order confirmation from this point onwards.

Understanding the Generic API in SCAYLE

When SCAYLE initiates an API request for fraud checking, it includes the entire state of the order object at the moment of the request. This includes information on the following:

Customer details
Billing and shipping addresses
Selected payment method
Applied vouchers and other discounts
Items listed in the order
Costs

In SCAYLE, when a customer proceeds to confirm an order, the downstream service set up in the system comes into play. This service typically requires an intermediary step: the payload needs adapting before being sent to the fraud check provider. The response, then, is converted back into a format SCAYLE can use. It's crucial here that the response payload is a valid JSON object, yet its specific structure can be tailored to your needs. For instance, a straightforward response indicating a successful fraud check might look like this:

{
  "riskCheckResponse": "green"
}

In many scenarios, additional details are crucial, like specifying which payment methods or delivery options are permissible. Here's an example showing a more detailed response:

{
  "riskCheckResponse": "green",
  "payment_methods": [
    {
      "method": "PayPal",
      "allowed": true
    },
    {
      "method": "Invoice",
      "allowed": false
    }
  ]
}

You might be wondering how SCAYLE can interpret such a flexible structure. The answer lies in SCAYLE's ability to set up rules that interact with this returned object. It's key to understand that this response object is stored in the customer and order data underscore, making it accessible for rule definition in the Rule Engine. More details on this process are covered in the next chapter.

Check our Developer Guide for more details.

Configure the rule engine

Configuring the Rule Engine in SCAYLE is an essential step for interpreting the customizable result object from the fraud check.

To start, create a rule in the category 'Automated Risk Check' via the SCAYLE Panel.

Access the Rule Engine

Navigate to Shops > [Shop Name] > Select country.
Then, navigate to Storefront > Checkout Settings > Rule Engine
Click on Add first rule and provide a name and a short description for your new rule.

Setting conditions in the Rule Engine

In the "Conditions" section,add a rule to check the customData for either the customer or the order. This check offers flexibility in configuration.

For instance, you might set it up to look for a specific value within the customData. Based on our previous example response object, your condition might look something like this:

Remember, the fraud check result is stored in both the order and customer objects. This data remains unless the order is renewed with a new basket-key, or the customData is overwritten or removed.

Define results

In the 'Results' section, select the 'Automated Risk Assessment' type. This allows for five various actions:

Accept Order: The confirmation is not blocked.
The order is accepted: Block the order confirmation, but still allow the customer to retry it
Trigger Notification: Displays a notification message to the customer, which can be combined with other actions.
Trigger Error Message: Displays an error notification message to the customer, which can also be combined with other actions to communicate the reasons.
Block Confirmation and Disable Payment Method: Stops order confirmation and deactivates the chosen payment method to prevent retries.

You can combine multiple results of the "Automated Risk Assessment" type, like pairing “Block Confirmation and Disable Payment Method” with “Trigger Notification” for comprehensive feedback.

Imagine you've set a condition as described above, and your goal is to block the order confirmation, disable a payment method, and trigger an error message. Your result configuration would be tailored to reflect these actions:

When you block an order confirmation and guide the customer back to the checkout, all other rules are reassessed. For example, you can now implement rules to disable additional payment or shipping options.

Well done! You’ve successfully configured your fraud check in SCAYLE.