Layer 1 copy


This is a guide for an integration aimed at stopping chargebacks, promo abuse, or power buying on event ticket purchases.

Send User Events

A core integration includes the following (when applicable):

Integrate your website
Integrate your mobile app
Integrate your events
User creates an account
  • If users can create accounts, send a $create_account event.
  • If a user updates their account information outside of the checkout flow, send an $update_account event.
  • If users can checkout anonymously, follow our tutorial.
User buys a ticket
  • When a user buys a ticket, send a $create_order event with an $item for each ticket type:
    • $product_title should be a generalized event name, e.g. Golden State Warriors Regular Season Ticket, Chelsea FC Premier League Match, Zedd Concert Ticket.
    • $category should be the type of event the ticket is purchased for, e.g. Sports > NBA > Regular Season, Sport > Soccer > Premier League Football,Music > Electronic > Zedd
    • $tags should include any descriptors of the events i.e. teams names, geography, e.g. Barcelona FC, Real Madrid, , Portugal.
  • Send custom fields on the $create_order to capture differences between users and orders. For example:
    • 'days_to_event' : 1 (where 1 means tomorrow)
    • 'reservation_channel' : '', ''
    • 'venue_name' : 'Camp Nou', 'Davies Symphony Hall'
    • 'venue_type' : 'Sports Arena', 'Concert Hall', etc
    • 'ticket_type' : 'vip', 'box', 'standing room', etc
    • 'event_time' : (time of the event as a UNIX timestamp value in seconds)
You interact with a payment gateway
  • Send a $transaction event for each payment gateway interaction, as well as each other payment method accepted for the order (e.g. gift card).
  • When a payment gateway informs you of a chargeback, send a fraud label.
C2C ticket marketplaces

If your application includes a marketplace where users can post tickets, also see our marketplaces integration guide. Specific custom field suggestions for the $create_content event are:

  • 'num_listings' : 4 (value before this listing)
  • 'num_tickets_sold' : 14 (tickets sold before this posting)
  • 'tickets_listed' : 2 (tickets in this posting)
  • 'listing_venue_name' : 14
  • 'listing_venue_type' : 'Sports Arena', 'Concert Hall', etc
  • 'listing_ticket_type' : 'vip', 'box', 'standing room', etc
  • 'listing_days_to_event' : 1 (where 1 means tomorrow)

Additional Events

The following events can be sent to capture a more complete picture of users when applicable: $update_account, $login, $logout, $chargeback.

Send Feedback to Sift

One of the key strengths of the Sift Science platform is that as you give it feedback it continues to learn and adapt to patterns. By providing continuous feedback on who your good and bad users are, we will evolve our detection and improve the accuracy of risk scores. You’ll be able to stop bad actors even as they change their attack vectors. In addition to sending an optional historical backfill:

  • Create a Feedback focused Workflow where you review high scoring users and tell us how well we are predicting your fraudsters.
  • If you are already doing manual review in your existing system, just send the outcome of each review to our Labels API

Once you’re up and running with Sift, continuing to send feedback will improve your score accuracy in real-time, catching bad users as soon as they appear. This is an important part of a successful integration.

Make Decisions with Sift

Scores are an indication of how risky a user is for a given abuse type. You can use these scores as a means to block bad users, add friction to users you are unsure about (e.g., SMS verification), and let good users sail right through. You’ll likely be making this check at $create_order.

The two ways to do this are:

  • Create a Sift Workflow You can build application logic into Sift with our Workflow product. Workflows let you set up criteria that get evaluated whenever specified events occur. Learn more in our Workflows tutorial.
  • Build application logic in your system An alternate approach is to request abuse specific risk scores to be returned in the response of the user events you send. See our API documentation

Any questions? We're happy to talk it through.