---
title: Abuse at Checkout
slug: abuse-at-checkout
docTags: 
createdAt: 2026-06-01T13:20:13.766Z
---

## Abuse Prevention Policies at Checkout

Forter supports the following policy types at checkout:

- Item Not Received (INR) Abuse
- Limited Item Abuse
- Promotion Abuse
- Reseller Abuse
- Reshipper Abuse
- Returns INR Abuse

## Integration Steps

::::WorkflowBlock
:::WorkflowBlockItem
### Include Required Data

In order to integrate Abuse Prevention at checkout, you will need to provide Forter with the relevant data as outlined in the [Checkout Integration](docId\:n0TxjlH0T2EhOj6QrY3Nd), [Post-purchase Updates](docId\:HkmA8mYwlXOzdB2ta49VG), and [Dispute Notifications](docId\:i34MoZGuU-nekmJ02nuj1) sections.

1. **Item Not Received Abuse:** To create policies related to Item Not Received including appeasements (ie. form of compensation to appease an end customer such a free item, store credit, etc.) send an Order Status API request that includes the `compensationStatus` object. This is critical to be able to define targeted refund/returns policies based on specific conditions even if applied at checkout. For INR policies related to service chargebacks, also send chargeback data along with appropriate reason code via Dispute API.
2. **Limited Item Abuse:** Send `basicItemData` as part of the Order API.
3. **Promotion Abuse:** Send the `discounts` object as part of Order API. Be sure to use the `discounts` object, and not `totalDiscount`, in order to include multiple promotion/coupon codes in a single transaction.
4. **Reseller Abuse:** Send the following objects as part of Order API: `payment`, `primaryDeliveryDetails`, `primaryRecipient`, `accountOwner`, `cartItems`
5. **Reshipper Abuse:** Send the following fields as part of Order API: `paymentRecipient.address.zip`, `cartItems.beneficiaries.address`
6. **Returns Abuse:** To create policies related to Returns including appeasements (ie. form of compensation to appease an end customer such a free item, store credit, etc.) send an Order Status API request that includes the `compensationStatus` object. This is critical to be able to define targeted refund/returns policies based on specific conditions even if applied at checkout. For Returns policies related to service chargebacks, also send chargeback data along with appropriate reason code via Dispute API.
:::

:::WorkflowBlockItem
### Handle Policy Decisions from the Order API response

When creating policies, you can elect to receive a decline decision or a recommendation when a transaction meets the policy criteria, in the API response.
The `recommendation` response will vary based on the policy type defined. In order to test your handling of Abuse policy recommendations, use the corresponding email address below in the `accountOwner` object within the API request.

| Customer Email                               | Order v3 Response                                          |
| -------------------------------------------- | ---------------------------------------------------------- |
| `test_limited_item_solution@forter.com`      | `"recommendation": "MONITOR_POTENTIAL_LIMITED_ITEM_ABUSE"` |
| `test_coupon_solution@forter.com`            | `"recommendation": "MONITOR_POTENTIAL_COUPON_ABUSE"`       |
| `test_item_not_received_solution@forter.com` | `"recommendation": "MONITOR_POTENTIAL_INR_ABUSE"`          |
| `test_return_solution@forter.com`            | `"recommendation": "MONITOR_POTENTIAL_RETURN_ABUSE"`       |

The response will also include a `merchantPolicyId` field: 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.
:::

:::WorkflowBlockItem
### Send Compensation Requests

As part of [Post-purchase Updates](docId\:HkmA8mYwlXOzdB2ta49VG), include compensation requests in your Order Status API updates to Forter. This will not return a decision, but provides valuable information to inform our decision models and enable Return/INR policy decisions. 
Important data for this purpose includes:

- orderId - of the full reservation details sent via Order API
- correlationId - to the corresponding compensation request (when applicable)
- compensationStatus - the main object that contains all relevant data about the compensation including:
  - 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)

It is critical to map your internal returns data to Forter’s fields and ENUMS on the  ItemCompensationStatus in order to define targeted refund/ returns policies based on specific conditions.
:::

:::WorkflowBlockItem
### [Dispute Notifications](docId\:i34MoZGuU-nekmJ02nuj1) 

Confirm that you are sending all disputes to Forter through webhooks from your PSP or the Dispute API.  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.
:::

:::WorkflowBlockItem
### Prepare and Upload [Historical Data](docId\:u_DHFiqGB8xXmZuFU66tb) 

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 compensation data in order to provide you with better accuracy from Day 1.

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.

###
:::
::::