Secure your business from login to chargeback
Stop fraud, break down data silos, and lower friction with Sift.
- Achieve up to 285% ROI
- Increase user acceptance rates up to 99%
- Drop time spent on manual review up to 80%
This guide helps companies that have a single payment form to accept donations or to accept payments for services that do not require fulfillment of items prevent chargebacks.
A core integration includes the following (when applicable):
$transacton_status : '$pending'
$transaction_type : '$sale'
(or '$authorize'
if you authorize before capturing $user_id
if they're not logged in to an account.$amount
field to the amount they are donating.$payment_method
object as possible.$transaction
event for our risk assessment (see the 'Make Decisions' section below).$transaction
event with$transacton_status : '$success', '$failure'
(based on response from the payment gateway)$transaction_type : '$sale'
(or '$authorize'
- the same as before)$transaction
event.$transaction
event with $transaction_type : '$capture'
$transaction
events.The following events can be sent to capture a more complete picture of users when applicable: $update_account (whenever a user updates their account information, e.g. adds payment information or changes contact info), $login, $logout.
Whenever your automated systems or analysts take action, send those actions into Sift as Decision events. Actions range from positive (eg Approve Order), to neutral (Flag Account), to negative (Ban User). The key thing is that you should send all Actions you take to Sift, not just your negative actions.
In order to send Decision events you'll first have to create the specific Decisions your business takes in the Sift Console. While we start all accounts out with a few generic Decisions, Decisions are fully customizable so you can create a Decision for every action that your business takes. Some examples of Decisions are:
See the Decisions tutorial for more context.
During your integration, you should send the Decisions that your business is currently making through any internal fraud engines or Manual Review processes to the Sift Decisions API. If you currently do not have in-house fraud logic or a manual review process, work with Sift to setup your initial Workflows within Sift's platform.
When you are initially integrating with Sift, your scores will be based on whatever data you’ve sent us. So if it is a brand new integration with no backfilled data, Sift will need a week or two of data to learn your unique fraud patterns. One of the key strengths of the Sift platform is that it consistently learns as you send more and more data to it. You should see a substantial increase in accuracy of your scores during these first weeks as you send more Decisions and User Events.
During this stage, you should be assessing your Sift Scores in the Sift Console and determining which actions you want to take for different score ranges. Since all businesses are different, finding your unique score thresholds that achieve your business goals is key.
To reduce the amount of time required in this initial learning phase, you can send a historical backfill so that Sift can learn about your user's fraud patterns.
Now that you sending both user events and business decisions to Sift, you’re ready to start using Sift scores in your business logic. At this point, you’ll have an understanding how scores correlate to different levels of risk. Based on the user’s risk score, you’ll set up different outcomes within your application (eg users with low score are automatically approved).
To build this logic, you'll want to evaluate a user's Sift Score at the key events where bad users can hurt your business or good users can have a more frictionless experience.
The two ways to use Sift Scores:
Any questions? We're happy to talk it through.
Stop fraud, break down data silos, and lower friction with Sift.