Overview

Sift allows you to connect the decisions you make on users/orders to real business actions in your backend. If you want to use automated Decisions, or create review queues to add these Decisions too, please read the Creating A Workflow Guide.

In this tutorial we will cover the following:

  • How to create a new decision.
  • Adding Decisions to your Explore mode lists.
  • Linking that decision to a business action on your backend.

You will need:

  • A fraud manager or other fraud specialist to determine which decisions should be supported.
  • A backend engineer to connect Sift’s output to the actual business actions which need to be taken (4 hours)

Creating a new Decision

Before we begin explaining how to create a Decision in the console, there are a few things you should know:

What is a Decision?

A Decision is an action that can be taken by your team through review queues, the Explore Tab, or automatically through a Flow (see the Creating A Workflow Guide, for more information on this). For the purpose of this tutorial we will focus on Decision taken through queues and the Explore Tab. When a Decision is triggered, it will send an HTTP notification to an endpoint you specify during the creation of the Decision.

When should I make a Decision?

Depending on your business model, there will be different points in time that you want to make Decisions about a particular User or Order. For example, if the fraud you experience is promotion abuse you will want to review and take Decisions on users who have just created accounts or placed orders with promotions. Whereas if you have chargeback issues on your orders, you’ll want to review orders that have been placed before you fulfill them, regardless of promotions used.

In order to ensure you’re able to review at these key points, you should create a Workflow which is triggered by users taking those actions on your site. Please read our Creating A Workflow Guide to learn more about Workflows.

What Decisions should I support?

Each business has unique actions that they will want to take in different situations. Generally those actions boil down into 3 main categories:

  • Block an account/order.
  • Watch an account/order.
  • Allow an account/order to be created.

With this in mind you can start with 3 Decisions covering these actions, but add as many as you require to satisfy your business needs.

Creating a decision

In order to create a new decision, start by clicking the “Make decisions” button in the Getting Started Tab of our console:

Developer Task: Identify Decision Points

  • Provide a webhook for the Decisions to send notifications to.

In the modal that opens up, you will need to provide the following information:

  • Name (Required) - a descriptive name for this action, such as “Block Order for Chargeback Risk”
  • Decision Type (Required) - the type of decision this is. There are 3 options: Block, Allow, and Watch. Here is a quick description of when you should use each type:
    • Block - If the business action is to block the user from interacting with your site, whether it be placing an order or something else.
    • Allow - Any action which allows the user to continue interacting with your site, whether that means placing orders, publishing content, etc.
    • Watch - Any action which is not explicitly blocking or allowing the user to interact with your site. Some examples are requesting they contact support, initiating mobile verification, etc.
  • Fraud Type (Required) - The fraud type that this action tackles. For example you may have separate actions for blocking an account due to promo abuse and blocking an order due to chargeback risk.
  • Show Decision In Explore? (Required) - Decisions by default can be added to review queues. If you would like this decision to be taken from our Explore Tab, check this box.
  • Webhook (Required) - The endpoint that you want Sift to send our HTTP notification to. If you’re not sure what endpoint to use, consult with your backend engineer to get one.
  • Description (Optional) - A long form description of this action.

Connecting your Decisions to backend actions

Now that you’ve created a Decision that can be taken in the Sift console and provided an endpoint for the HTTP notification which are generated, you need to parse that notification to understand what action should be taken. Please see the code example below:

# Sample Decisions API HTTP notification
{
  "entity": {
    "type": "user",
    "id": "soju12345"
  },
  "decision": {
    "id": "block-user"
  },
  "time": 1461963439151
}

This is a sample notification that would be received by your backend. Here are some of the pieces of information that will be needed to execute the appropriate action:

  • Decision name - This is stored under decision.id, and is the name of the Decision which was taken.
  • Entity type - what entity the action should be taken on, can have the values “user” or “order”. It is stored under entity.type.
  • Entity ID - The identifier of the user/order, stored under entity.ref.type. This should be the same as your internal identifier for that user/order.

With these pieces of information you will be able to take the appropriate action on the correct entity. For more information on the output of our Decisions please see the Decisions API Reference Documentation.