Abuse Prevention Integration Steps - Checkout

Integration Steps (Checkout Only)

Abuse Prevention requires as a baseline a Fraud Management integration

The Order API can be called prior to or after 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.

Step 1: Handle abuse decisions and recommendations from the Order API response

When creating policies, merchants can elect to receive a decline decision or a recommendation when a transaction meets the policy criteria, in the API response.
The recommendation responses will vary based on the policy type. There are six available policy types, each type has a unique response (see below). However, only one needs to be tested - and the testing can occur by setting a policy via Policy Zone in the Forter Dashboard.

The merchantPolicyId field, is the unique ID that Forter assigns to a policy when a user creates a policy in Policy Builder. The ID can be used in downstream systems to have custom flows. If the decision was not influenced by a user-defined policy, then the field will return a blank string.

Recommendation Responses per policy type

• Reseller: MONITOR_POTENTIAL_RESELLER_ABUSE
• Reshipper: MONITOR_POTENTIAL_RESHIPPER_ABUSE
• Limited Item: MONITOR_POTENTIAL_LIMITED_ITEM_ABUSE
• Promotion: MONITOR_POTENTIAL_COUPON_ABUSE
• Item Not Received: MONITOR_POTENTIAL_INR_ABUSE
• Returns: MONITOR_POTENTIAL_RETURN_ABUSE

Step 2: Send compensation request data

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. It does not provide updated decisions. We use the orderID provided in the OrderAPI as the identifier to connect to the original order and ensure orders are tracked seamlessly.
Important data for this purpose includes:

• orderId - of the full reservation details sent via Order API
• correlation ID - to the corresponding compensation request (when applicable)
• Compensation Request Data - the main object that contains all relevant data about the compensation (whose structure will vary given item level/order level integration). It includes:
  • the type of compensation that was requested by the consumer (e.g. Replacement, Refund, Return etc..)the channel through which the request was made,
  • For returns, the items being returned
  • The reason provided for the request (e.g. Changed My Mind)
  • The return method granted
  • The return condition of the item back to the merchant distribution center (eg. Damaged)

Note: To apply Returns/INR policies at checkout, The Order status update must include the CompensationStatus Object, via the order status API. Within the compensationStatus Object - Merchant must map their internal returns data to Forter’s fields and ENUMS on the ItemCompensationStatus. This is critical to be able to define targeted refund/ returns policies based on specific conditions. Data Mapping Required of Internal Merchant Reasons to Forter ENUMS

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

Step 3: Share Historical Compensation Data

Provide 1 year historical data for returns and INR, where possible, so that INR & returns policies can take effect immediately, and velocity counters take into consideration prior returns/INR refunds. At the time of implementation, a CSV file template will be provided.

Step 4: Send Dispute Data

Confirm that you are sending all disputes to Forter through the Dispute API or via webhook from your PSP. Forter uses prior chargeback data to evaluate future refund requests as well as enforce Item Not Received and returns policies at checkout and post purchase.