Integration Guides

Fraud Management

Getting Started with Forter's Fraud Management Integration

Suggest Edits

Fraud Management Overview

With Forter’s Fraud Management integration, your company will be able to ensure that only good, legitimate customers are able to checkout on your site - while fraudsters are identified and blocked. Forter will send approve or decline decisions for every single transaction.

Forter's Fraud Management Product can be integrated:

  • Post-Authorization (AFTER payment has been authorized by your Payment Service Provider) OR
  • Pre-Authorization where an API request for a Forter approve/decline decision is sent BEFORE your system sends the payment request to the relevant bank for authorization. Pre-Authorization integrations are appealing if you have card testing by fraudsters or if your payment provider holds long card authorizations.

Completing the Fraud Management Integration is easy, as you’ll see from the process outlined here and explained in greater detail below the Integration Sequence Diagram.

  1. Place Forter’s JavaScript snippet on your website to allow us to analyze customers’ profiles as necessary for trust assessments
  2. Send Forter your basic order data to get a real-time trust assessment and recommendations
  3. Send Forter your post-order updates, including your payment authorization status (for pre-auth integrations) and order fulfillment status, via the order status API
  4. Send Forter chargeback data to enable Forter’s system to learn and continually improve future decisions, tailoring our system to your company’s needs.

Fraud Management Pre-Auth Integration

With Forter’s Fraud Management integration, your company will be able to ensure that only good, legitimate customers are able to checkout on your site - while fraudsters are identified and blocked. Forter will send approve or decline decisions for every single transaction.

The Pre-Authorization (Pre-Auth) integration is for you, if your company has decided that it would be best for Forter to send the approve/decline decisions before your system sends the payment request to the relevant bank for authorization. This can make sense, since that cuts down on the number of auth requests you need to send; if it’s a fraudster using a stolen credit card to attempt a transaction, there’s no need to ask for authorization.

Completing the Fraud Management Pre-Auth Integration is easy, as you’ll see from the process outlined here and explained in greater detail below the Integration Sequence Diagram.

Step 1: Front End Integration

In your dedicated Forter portal, you will receive a JavaScript snippet for both sandbox and production. For native mobile apps, you will receive links to download Forter's Native SDKs. You'll paste the JS script on the appropriate pages of your website or call mobile SDK methods on relevant mobile app screens so that it can load and asynchronously collect important behavioral data from your customer.

Step 2: Pre-Authorization Validation API

Pre-Auth Validation API Request
The Validation API should be called prior to the call made to your payment gateway to authorize customer funds. This API is used to provide Forter with all relevant data points that will help Forter determine whether the entity conducting the transaction/engagement is legitimate or fraudulent.
Key data points include:

  • Order ID - the unique identifier for the order in your system
  • Account Data - Information collected about the account owner such as the account owner name, email, etc..
  • Authorization Step - an indicator that the API is being called prior to authorization
  • Device and browsing data, to enable our system to distinguish between legitimate and suspicious signals
  • Payment Data such as Credit card BIN, last 4, expiration date ( Note - Forter is PCI DSS Level 1 Certified and does NOT collect the full credit card)
  • Billing Address details (when applicable)
  • Recipient details such as name, address, phone and email
  • Cart Item Data - details about the goods being purchased. Note some item data will depend on the vertical of the merchant (e.g. travel items contain different data than apparel items)

For more details and code samples please see our Validation API reference documentation.

Depending on your precise industry and use case, we may ask for some extra data points that aren’t in this table, but they’ll all be the same kind of information you see listed here - data points which have an obvious relevance and impact when it comes to making sure you can trust the right customers on your site.

In the case of a Pre-authorization integration, Forter can return a decision and a recommendation prior to the PSP/gateway authorizing the payment. In some cases, we may request you make an extra API call post-auth, so we can incorporate the relevant new information from the auth request into our decisions.

Pre-Auth Validation API Response
The API response will contain Forter's decision and applicable recommendations (for example, relating to policy enforcement or 3DS). We may ask your company to make an additional API call post-auth in order to provide an updated decision once supplemental data such as AVS/CVV check and 3DS data are available, as this data can play a helpful role in ensuring accurate decisions. For more details and code samples please see our Validation API Reference

Step 3: Order Status API

Order Status API Request
The Order Status API is used to provide Forter with updates after the initial decision was made in order to provide valuable information to inform our decision models after the order was submitted. It does not provide updated decisions. We use the orderID provided in the Pre-Authorization Validation API as the identifier to connect to the original order and ensure orders are tracked seamlessly.

Important data for this purpose includes:

  • Payment Authorization Data - such as the amount authorized, AVS and CVV check results (when applicable), the authorization code, and gateway/processor used and the transaction ID, which can help with chargeback matching (see step 4).
  • Order fulfillment data - most important is to send ongoing updates on the order’s fulfillment status, using both the Forter standardized status types and your company’s free text status.

👍

Note

The Order Status API is used for multiple Forter offerings and certain custom fields and objects such as return item data, compensation data, and payment authorization data may be included in the object as required fields to optimize our models and support different use cases.

You can send updates via the Order Status API for up to 18 months after the transaction is created.


For more details and code samples please see our Order Status API Reference

Order Status API Response
The response details whether or not the order status update was completed successfully. It will NOT return a new decision.

Step 4: Claims API

The Claims API is used to notify Forter about chargebacks and fraud alerts. This is extremely important because it enables Forter’s system to learn and continually improve future decisions, tailoring our system to your company’s needs.

Additionally, companies who have chosen to take advantage of Forter’s chargeback coverage option also need the Claims API to make sure Forter knows which chargebacks have been submitted and should be reimbursed.

While the Claims API is used to notify Forter about chargebacks, Forter also supports claims webhooks for supported payment gateways including:

  • Braintree
  • PayPal
  • Checkout.com
  • Stripe
  • Adyen

Claims API Request
The Claims API is used to provide Forter with information about chargebacks and fraud alerts in order to improve future decisions (and allow Forter to reimburse covered merchants). The full Claims API Request and Response data can be found in our Claims API Reference.

Key data points include:

  • orderId/matching transaction ID - the ID that corresponds to the original transaction that Forter received
  • amount of the claim
  • claim currency - the currency the claim is generated in
  • reason Code - the code provided by the payment processor (from the list of card scheme codes) to determine if the Chargeback is due to Fraud or Service issues
  • processorChargebackCaseId - the unique identifier of the claim that can be used for disputing it.
  • type of claim (e.g. Chargeback, Fraud alert)
  • additionalCost - any supplementary fees associated with the chargeback
  • status of the claim (e.g. OPEN / WON / LOST)
  • sourceType of the claim (e.g. PROCESSOR_CB) and sourceDetails (e.g. Worldpay)
  • issue date of the chargeback
  • due date to dispute the chargeback

Claims API Response
The response details whether or not the claim was received successfully. Chargebacks will also show on the original transaction in the Forter portal and can be included in relevant claims reporting in the portal as well.

Fraud Management Post-Auth Integration

With Forter’s Fraud Management, your company will be able to ensure that only good, legitimate customers are able to checkout on your site - while fraudsters are identified and blocked. Forter will send approve or decline decisions for every single transaction.

The Post-Auth integration is for you, if your company has decided that it would be best for Forter to send the approve/decline decisions after your system sends the payment request to the relevant bank for authorization. This can make sense, since supplemental information received as part of the auth process can be helpful in making decisions as accurate as possible.

Completing the Fraud Management Post-Auth Integration is easy, as you’ll see from the process outlined here.

Step 1: Set Up Forter JavaScript Snippet

In your dedicated Forter portal, you will receive a JavaScript snippet for both sandbox and production. You'll paste the script on the appropriate pages of your site so that it can load and asynchronously collect important behavioral data from your customer. The script will also generate a unique token for each user on your site that should be included in the Validation API request.

Step 2: Forter Validation API

**Post-Auth Validation API Request** The Post-Auth Validation API is used to provide Forter with all relevant data points that will help Forter determine whether the entity conducting the transaction/engagement is legitimate or fraudulent after the transaction has been authorized by the payment gateway. Full API Reference Documentation for the Validation API can be found in the Order Validation API Reference

Key data points include:

  • orderID - the unique identifier for the order in your system
  • Account Data - Information collected about the account owner such as the account owner name, email, etc..
  • Device and browsing data, to enable our system to distinguish between legitimate and suspicious signals
  • Payment Data such as Credit card BIN, last 4, expiration date ( Note - Forter is PCI DSS Level 1 Certified and does NOT collect the full credit card)
  • Billing Address details (when applicable)
  • Recipient details such as name, address, phone and email
  • Cart Item Data - details about the goods being purchased. Note some item data will depend on the vertical of the merchant (e.g. travel items contain different data than apparel items)

Depending on your precise industry and use case, we may ask for some extra data points that aren’t in this table, but they’ll all be the same kind of information you see listed here - data points which have an obvious relevance and impact when it comes to making sure you can trust the right customers on your site.

Post-Auth Validation API Response
The API response will contain Forter's decision and applicable recommendations (for example, relating to policy enforcement or 3DS).

We may ask your company to make an additional API call post-auth in order to provide an updated decision once supplemental data such as AVS/CVV check and 3DS data are available, as this data can play a helpful role in ensuring accurate decisions.

Step 3: Order Status API

The Order Status API helps Forter protect your company by ensuring that changes in an order status don’t expose your company to fraud. For example, if a customer calls up your customer support and asks to change the address to which they’re sending their delivery then that might be a suspicious sign, depending on the address used. With the Order Status API, your company can make sure Forter has the ongoing information we need to protect you.

The Order Status API is called after the Post-Auth Validation API, because this information only comes into play once the order has been placed.

Order Status API Request
The Order Status API is used to provide Forter with updates after the initial decision was made. We use the orderID provided in the Post-Auth Validation API as the identifier to connect to the original order and ensure orders are tracked seamlessly.

Important data for this purpose includes:

  • Order fulfillment data - most important is to send ongoing updates on the order’s fulfillment status, using both the Forter standardized status types and your company’s free text status.
  • OrderId - to connect the status of the order with the original transaction

Order Status API Response
The response details whether or not the order status update was completed successfully. It will NOT return a new decision
Please review our Order Status API Reference for more information.

Step 4: Claims API

The Claims API is used to notify Forter about chargebacks and fraud alerts. This is extremely important because it enables Forter’s system to learn and continually improve future decisions, tailoring our system to your company’s needs.

Additionally, companies who have chosen to take advantage of Forter’s chargeback coverage option also need the Claims API to make sure Forter knows which chargebacks have been submitted and should be reimbursed.

While the Claims API is used to notify Forter about chargebacks, Forter also supports claims webhooks for supported payment gateways including:

  • Braintree
  • PayPal
  • Checkout.com
  • Stripe
  • Adyen

Claims API Request
The Claims API is used to provide Forter with information about chargebacks and fraud alerts in order to improve future decisions (and allow Forter to reimburse covered merchants). The full Claims API Request and Response data can be found in our Claims API Reference.

Key data points include:

  • orderId/matching transaction ID - the ID that corresponds to the original transaction that Forter received
  • amount of the claim
  • claim currency - the currency the claim is generated in
  • reason Code - the code provided by the payment processor (from the list of card scheme codes) to determine if the Chargeback is due to Fraud or Service issues
  • processorChargebackCaseId - the unique identifier of the claim that can be used for disputing it.
  • type of claim (e.g. Chargeback, Fraud alert)
  • additionalCost - any supplementary fees associated with the chargeback
  • status of the claim (e.g. OPEN / WON / LOST)
  • sourceType of the claim (e.g. PROCESSOR_CB) and sourceDetails (e.g. Worldpay)
  • issue date of the chargeback
  • due date to dispute the chargeback

Claims API Response
The response details whether or not the claim was received successfully. Chargebacks will also show on the original transaction in the Forter portal and can be included in relevant claims reporting in the portal as well.

Updated 7 months ago