Fraud Management
Overview
5 min
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 for every transaction sent to forter, forter will return an approve or decline decision it achieves this through persona graph forter has built a dataset of one billion personas for every interaction, we look across this vast network to see if we know the persona machine learning forter applies machine learning to deliver decisions that are 100% automated forter's fraud management product can be integrated before or after your system sends the payment request for authorization pre authorization integration integrating 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 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 pre authorization integrations are appealing if you have card testing by fraudsters or if your payment provider holds long card authorizations post authorization integration integrating post authorization (post auth) 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 in this case, supplemental information received as part of the authorization process can be used in the decision model integration steps front end integration docid\ i0th2q4hrfbn h8chrv1d in order to provide forter with critical information about user behavior used in the decision model, you'll need to add a javascript snippet to your website 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 order api request if you have a mobile application, forter's mobile sdks should be used to provide this behavioral information for users on your mobile app install the sdk on each of your native or hybrid platform applications checkout integration docid\ zli8xrrlbmssvw0jlvxqb forter's order api is used to provide forter with all relevant data points, including payment authorization information, that will help forter determine whether the entity conducting the transaction/engagement is legitimate or fraudulent for a pre authorization flow, the order api endpoint should be called prior to the call made to your payment gateway to authorize customer funds for a post authorization flow, the order api endpoint should be called after to the call made to your payment gateway to authorize customer funds the order api response will contain forter's decision and any applicable recommendations, such as 3dsecure next steps or abuse policy enforcement post purchase updates docid\ kboks dbapjvvc0r5csre as you receive payment authentication updates (pre auth flows) and the order fulfillment status changes, it's important to keep forter notified, so that this information can be used in future decisions dispute notifications docid\ dcfboyebigyyebqkr9yqj notifying forter of disputes (also called claims, chargebacks, or fraud alerts) is extremely important because it enables forter's system to learn and continually improve future decisions, tailoring our system to your company's needs you can send these updates to forter via a webhook from your psp or via forter's dispute api endpoint prepare and upload historical data docid\ y6pmf 8whdvom7pogm7ea to ensure the highest level of accuracy for our decisioning model, forter customizes our model to fit the specific risk profile of each of our customers we achieve this by training the model with your past order and account data, including actual fraud outcomes, in order to provide you with better accuracy from day 1 complete integration tests https //docs forter com/qa#uk1vi the purpose of forter's integration tests is to make sure that your integration covers all relevant use cases, while still in the sandbox or test environment each use case may need a different combination of attributes and values to make sure you have covered each of the use cases we expect in your integration, please go through the test scenario list in the integration tests section of portal for each, you'll need to create the scenario in your sandbox site that will generate a call to forter's api then, select the corresponding api request that forter received and click run to verify that the sample request meets the criteria deploy to production once the integration tests have passed, and you've reviewed any gaps with a forter implementation engineer please, deploy your code to your production environment, with two critical adjustments replace your site id and secret key with your production credentials https //docs forter com/reference/environments#x fxu update your javascript snippet and mobile sdks to use your production site id and the production hash keys, if relevant please note that this does not yet complete your integration until forter has switched your site to live (after data validation and listen mode), all forter decisions will return "not reviewed" data validation https //docs forter com/qa#qeexu once in production, forter uses a data validation tool to execute a set of automated tests across your live data in aggregation the test outputs are daily reports that validate the accuracy and completeness of the production data we receive from you you can monitor this output in forter portal under integration center tools we recommend checking the report daily to identify any failed tests, which will prevent you from moving forward to listen mode listen mode https //docs forter com/qa#dkxgh in "listen mode", we will monitor the production traffic on your site and calibrate our models before we begin to provide you with decisions this is a critical stage to ensure you meet your kpis, and usually lasts around 7 14 days your implementation engineer will update you on the specific timeline for your integration during this time, forter will continue to return "not reviewed" decisions in the api response go live as forter begins to send decisions and recommendations, confirm that your production site is handling responses as expected