--- title: "Screen orders for fraud with Forter" source: https://support.storeconnect.com/articles/forter-fraud-screening type: article format: markdown site: StoreConnect Support — product and developer documentation for StoreConnect site_index: https://storeconnect.com/llms.txt docs_index: https://support.storeconnect.com/llms.txt note: Append .md to any page or article URL on this site to get its Markdown form. --- # Screen orders for fraud with Forter Use this process to connect a store to [Forter](https://www.forter.com) so that every card payment is screened for fraud before StoreConnect charges the payment provider. Forter returns an approve or decline decision in under two seconds. You choose whether StoreConnect only records that decision or acts on it, and you can hold borderline orders in Salesforce for a person to review. Screening is configured per store with **Store Variables**, so one Salesforce org can run Forter on some stores and not others, and can move a store from monitoring to enforcing without a deployment. ## Before you start - Your website runs StoreConnect v22 or later and your Salesforce org runs package v21.12 or later. The **Risk Review** field and **Fraud Review Queue** arrived in package v21.12; the screening itself arrived in website v22. - You have a Forter account with a TEST site and a production site. Your Forter implementation engineer creates these. - Your store's payment provider is one that StoreConnect charges from its own server. See [Which payments are screened](#which-payments-are-screened). A provider that takes the card on its own hosted page cannot be screened before the charge. - The store's **Audit Log Level** is not `Off`. Screening decisions are written to the **Audit Log**, and that is where you read them. Users who need to see them need the **StoreConnect Audit Viewer** permission set, which the **StoreConnect Administrator** permission set does not include. See [Audit Log Object Reference](audit-log-object-reference). ## How a screening decision is applied StoreConnect asks Forter for a decision immediately before it charges the card. What happens next depends on the decision and on the store's `risk.mode`. | Forter decision | `monitor` mode (default) | `enforce` mode | |---|---|---| | Approve or not reviewed | Payment proceeds. Audit Log records `Risk Screening Approved`. | Payment proceeds. Audit Log records `Risk Screening Approved`. | | Decline | Payment proceeds. Audit Log records `Risk Screening Declined` with outcome `monitored`. | The payment provider is never called. The customer sees "We could not process your order. Please contact Customer Care." Audit Log records `Risk Screening Declined` with outcome `enforced`. | | Forter unreachable or timed out, `risk.fail_mode` is `open` | Payment proceeds. Audit Log records `Risk Screening Error` with outcome `failed_open`. | Payment proceeds. Audit Log records `Risk Screening Error` with outcome `failed_open`. | | Forter unreachable or timed out, `risk.fail_mode` is `closed` | Payment proceeds. Monitor mode never blocks. | Treated as a decline. Audit Log records `Risk Screening Error` with outcome `failed_closed`. | A third path, holding the order for a person to review, sits alongside this table and is covered in [Hold orders for manual review](#hold-orders-for-manual-review). Start every store in `monitor` mode. It screens and records every order without changing what any customer experiences, so you can compare Forter's decisions with your own knowledge of your customers before a single order is blocked. ## Get your Forter credentials 1. Open the Forter Portal and go to **Integration** > **Credentials**. 2. Check the environment selector in the top right. Forter calls its sandbox the TEST environment. Start with TEST. 3. Copy the **Site ID** and the **Secret Key**. In the Forter Integrations screen these are labeled **Core API Site ID** and **Secret Key**. The **Credentials** page does not include the JavaScript snippet. You copy that from the **JS Snippets** page in [Add the Forter JavaScript snippet](#add-the-forter-javascript-snippet). The TEST site and the production site have different Site IDs and Secret Keys. Decisions from the TEST site are not real fraud decisions; see [Test the integration with the Forter sandbox](#test-the-integration-with-the-forter-sandbox). ## Add the risk store variables 1. Open the **Store** record and go to the **Store Variables** related list (`s_c__Store_Variable__c`). 2. Click **New** and create each variable in the table below. Enter the **Key** exactly as shown; keys are case sensitive. 3. Leave **Available in Liquid** unchecked on every risk variable. They are read by the server only, and the two credential values are secrets. 4. Save each record. | Key | Value | Required | Effect | |---|---|---|---| | `risk.provider` | `forter` | Yes | Turns on the Forter integration for this store. Any other value, or no value, leaves screening off. | | `risk.forter.site_id` | Your Forter Site ID, for example `56e66d524a80` | Yes | Selects the Forter site, and with it the TEST or production environment. Requests go to `https://.api.forter-secure.com`. | | `risk.forter.api_key` | Your Forter Secret Key | Yes | Authenticates every request to Forter. Treat it as a secret. | | `risk.forter.webhook_secret` | A long random string you choose | No | Authenticates the decision webhook Forter sends back to your store. When blank, the store expects Forter to authenticate with the Secret Key instead. See [Configure the Forter decision webhook](#configure-the-forter-decision-webhook). | | `risk.mode` | `monitor` or `enforce` | No, defaults to `monitor` | `monitor` records decisions and never blocks. `enforce` blocks declined payments before the provider is charged. Any other value behaves as `monitor`. | | `risk.fail_mode` | `open` or `closed` | No, defaults to `open` | What `enforce` mode does when Forter is unreachable. `open` lets the payment through. `closed` treats the outage as a decline. Ignored in `monitor` mode. | | `risk.review_on` | Comma-separated decision tokens, for example `not_reviewed,decline` | No, off when blank | Holds matching orders in Salesforce for manual review instead of treating them as routine. See [Hold orders for manual review](#hold-orders-for-manual-review). | Screening turns on as soon as `risk.provider`, `risk.forter.site_id`, and `risk.forter.api_key` are all present. Setting `risk.provider` alone does nothing. Enter the `risk.mode` and `risk.fail_mode` values in lowercase. A capitalized value is not recognized: `Enforce` silently falls back to `monitor`, with no error or warning. :::note **Store Variable** values are limited to 255 characters and are stored in Salesforce as plain text, the same as `captcha_secret_key` and other third-party keys. Restrict who can read **Store Variables** in your org accordingly. ::: ## Add the Forter JavaScript snippet The Forter JavaScript snippet sets a `forterToken` cookie in the customer's browser. StoreConnect sends that token with every screening request so Forter can use its device and behavior signals. Screening works without it, but the decisions are weaker, and Forter monitors the share of orders that arrive without it. If the rate is high, Forter contacts you to report missing cookie data. The snippet must load on every page where a customer can pay, not only the checkout. That includes the page a customer opens from a payment link sent from the point of sale or from Salesforce. A global **Script Block** covers all of these pages. ### Copy the snippet from Forter 1. Open the Forter Portal and go to **Integration** > **JS Snippets** at `https://portal.forter.com/app/dashboard/integration/js-snippets`. 2. Set the environment selector in the top right to the same environment as the store's `risk.forter.site_id`. The TEST and production snippets differ, and a snippet from the other environment sends its token to the wrong site. 3. Copy the snippet. ### Add the snippet as a Script Block 1. Go to the **Script Blocks** list (`s_c__Script_Block__c`). 2. Click **New**. 3. Fill in the fields below. See [Use script blocks](how-to-use-script-blocks) for more on each field. | Field | Value | |---|---| | **Script Block Name** | `Forter snippet` | | **Store** | The store you are screening | | **Active** | Checked | | **Channels** | `Web`. The storefront loads only Web script blocks. `POS` is not needed; a customer paying from a payment link pays on the web store. | | **Global** | Checked. A script block that is not global is not included on any page. | | **Position** | Any value. Load order does not matter for the Forter snippet. | | **Content** | The snippet, **without** its opening `` tags. StoreConnect adds them. | | **Script URL** | Leave blank. If this field has a value, **Content** is ignored. | 4. Click **Save**. :::warning Do not link a **Cookie** record to the Forter **Script Block**. A script block linked to a cookie only loads for visitors who accept that cookie in the privacy banner, so every customer who declines reaches Forter without a token. Forter's snippet supports fraud prevention on payment pages; confirm with your privacy advisor how to describe it in your privacy policy. ::: Forter recommends loading the snippet directly on the page rather than through a tag manager. Add it as a **Script Block**, not through Google Tag Manager. ### Allow the snippet in a strict content security policy Stores using the default content security policy need no change. If the store sets the `content_security_policy` store variable and `content_security_policy_type` is `enforce`, the browser blocks the snippet until the policy allows it. 1. In the Forter Portal, go to the same **JS Snippets** page and copy the content security policy rules and hashes for your environment. 2. Add those entries to the `content_security_policy` store variable. See [Store security settings](store-security-settings). 3. Turn on Forter's CSP mode in the snippet by setting `csp: true` in its `merchantConfig`, as described on the **JS Snippets** page. ### Confirm the snippet is loading 1. Open your storefront in a private browser window and go to any page. 2. Open the browser's developer tools and check the page `` for the Forter snippet. 3. In the developer tools, open the site's cookies and confirm a `forterToken` cookie is present. It can take a few seconds to appear after the page loads. 4. Place a test order, and ask your Forter implementation engineer to confirm it arrived with cookie data. The storefront now sets a `forterToken` cookie on every page, and Forter receives it with each screened order. When you switch the store to production credentials, repeat [Copy the snippet from Forter](#copy-the-snippet-from-forter) for the production environment and replace the **Content** of the same **Script Block**. ## Configure the Forter decision webhook Forter can reverse a decision after the fact, for example when one of its analysts reviews an order. It tells your store about this through a webhook, and StoreConnect records each update in the **Audit Log**. Without the webhook, the Audit Log only ever shows the original decision. 1. In the Forter Portal, go to **Integration Center** > **Tools** and click **Add webhook**. 2. Enter the destination URL, substituting your store's domain: ``` https://shop.example.com/async/inbound_webhooks/forter ``` 3. Set the authentication to HTTP Basic. Enter the value of `risk.forter.webhook_secret` as the username and leave the password blank. If you did not set `risk.forter.webhook_secret`, enter the Secret Key as the username instead. 4. Select the **Order decision update** notification type. 5. Send a test event from the same page. A `200` response confirms the store accepted it. The store rejects any webhook whose username does not match with a `401`, and Forter retries for about an hour before giving up. If test events return `401`, compare the username in Forter with the store variable character for character. ## Test the integration with the Forter sandbox With TEST credentials in place, Forter returns a randomized decision for most orders. Use these customer emails at checkout to force a specific result: | Customer email at checkout | Forter decision | |---|---| | `approve@forter.com` | Approve | | `decline@forter.com` | Decline | | `notreviewed@forter.com` | Not reviewed | 1. Place a test order on the store with `decline@forter.com` as the customer email and complete the card payment with your payment provider's test card. 2. Open the resulting **Order** record in Salesforce, or the **Cart** if the order was blocked, and open the **Audit Logs** related list. 3. Confirm a `Risk Screening Declined` row is present. Its **Outcome** is `monitored` in monitor mode or `enforced` in enforce mode. Its **Details** hold Forter's decision, recommendation, and transaction id, and its **Event Link** opens the order in the Forter Portal. 4. Repeat with `approve@forter.com` and confirm a `Risk Screening Approved` row. 5. Set `risk.mode` to `enforce` on the store, place another order with `decline@forter.com`, and confirm the checkout stops at the payment step with the Customer Care message and no **Order** is created. The **Cart** moves to `failed` and carries the audit row. 6. Set `risk.mode` back to `monitor` when you are done. The same rows appear in the Forter Portal against the order id, which is the **Cart** record's StoreConnect id. Forter's TEST site returns a randomized decision for any other email, and returns `Not reviewed` when the checkout form does not send the card's first six and last four digits. The reference theme's card form sends them; a custom theme may not. ## Roll out from monitor to enforce No deployment is needed for any of these steps. 1. Run in `monitor` mode with production credentials for long enough to see a representative spread of orders. Review the `Risk Screening Declined` rows in the **Audit Log** and the same orders in the Forter Portal, and raise any pattern you disagree with in your Forter rules workshop. 2. If the store takes subscription renewals, payments taken from Salesforce, or payments for an outstanding order balance, check how those are decided while still in monitor mode. Renewals run without a browser session, so Forter receives a placeholder IP address of `0.0.0.0` for them. A Forter policy that keys on IP or location can decline every renewal at once. 3. Set `risk.mode` to `enforce`. 4. Decide on `risk.fail_mode`. Leave it `open` unless your fraud exposure justifies refusing all card payments during a Forter outage. From this point a Forter decline stops the payment before the provider is charged, and the customer is asked to contact Customer Care. ## Hold orders for manual review Some decisions are neither a clear approve nor a clear decline. Set `risk.review_on` to route them to a person. The payment still completes and the **Order** is still created, but the order's **Risk Review** field (`s_c__Risk_Review__c`) is set to `Pending Review` so nobody fulfills it before the review. Before you set `risk.review_on`, ask StoreConnect support to confirm that **Risk Review** is synced read/write for your environment. If the field syncs one way, the hold reaches Salesforce but your `Released` and `Rejected` decisions never reach the store. ### Turn on review holds 1. Open the **Store** record and go to the **Store Variables** related list. 2. Create `risk.review_on` with a comma-separated list of the decisions or recommendations to hold. Matching is case insensitive. Common values: - `not_reviewed` holds orders Forter could not reach a decision on. - `decline` holds declines instead of letting them through in monitor mode. - `verification_required_3ds_challenge` holds orders where Forter recommends a 3D Secure challenge. 3. Save the record. A review match never weakens `enforce` mode. A decline that enforce mode would block stays blocked, even if `decline` is also listed in `risk.review_on`. Review only converts an order that was going to proceed into one that proceeds on hold. The **Audit Log** records these as `Risk Screening Review` with outcome `flagged`. While an order is on hold, the customer sees "Your order is being reviewed. We'll update you once it is processed." on the order confirmation page and on the order in their account. Emails about the hold, release, or rejection are not sent by StoreConnect. Build them in Salesforce from changes to the **Risk Review** field. ### Work the Fraud Review Queue 1. Go to the **Orders** list and select the **Fraud Review Queue** list view. It shows every order with **Risk Review** equal to `Pending Review`, with the order number, status, customer email, store, total, and submitted date. 2. Open an order and review the `Risk Screening Review` row in its **Audit Logs** related list. The **Event Link** opens the order in the Forter Portal. 3. To accept the order, set **Risk Review** to `Released` and fulfill it as normal. 4. To refuse the order, set **Risk Review** to `Rejected`, then cancel and refund it as normal. See [Process refunds for web orders](processing-refunds-for-web-orders). Users with the **StoreConnect Order Manager** or **StoreConnect Administrator** permission set can edit **Risk Review**. The field can also be set on the **Order** record page directly. StoreConnect writes `Pending Review` only once per order and never overwrites a value that is already set, so a retried payment or an additional payment cannot move an order you have released or rejected back into the queue. ## Which payments are screened Screening happens before the card is charged, which is only possible where StoreConnect makes the charge itself. Screened: - Web checkout card payments through Adyen, Adyen ACH, Afterpay, Authorize.net, Authorize.net ACH, Bambora, Braintree, CyberSource, Eway, NMI, NMI ACH, PayWay, PayPal, SecurePay, Square, StoreConnectPay, StoreConnectPay ACH, Stripe, TouchNet, Tyro (web), and Westpac Online Pay. - Web checkout orders paid entirely with vouchers, account credit, or reward points, so that a zero-card order is still screened. - Subscription renewals. - Payments taken from Salesforce with **Take Payment**. These are sent to Forter as phone orders. - Payments for an outstanding order balance made through a payment link. Not screened: - Point of sale. Card-present payments are out of scope. - Orders paid by bank transfer, pay later, pay by account, or that are free. No card is charged, so there is nothing to screen before. - Providers that take the card on their own hosted page or in their own browser component: Eway v2 (Rapid), Stripe ACH, ACI, CBOSS, Windcave, Latitude, Flywire, and ZipPay. The money has moved before StoreConnect hears about it. StoreConnect also reports account sign-ups and logins to Forter as information only. Nothing about login or registration is blocked by Forter. ## Read screening results in the Audit Log Every screening writes one **Audit Log** record in the `PAYMENTS` category, linked to the **Cart**, **Contact**, **Store**, and, once created, the **Order** and **Payment**. These are kept for seven years. See [StoreConnect Audit Event Object Reference](storeconnect-audit-event--mdt-object-reference) for how retention is defined. | Event type | Severity | When it is written | |---|---|---| | `Risk Screening Approved` | Notice | Forter approved, or could not review, the order. | | `Risk Screening Declined` | Warning | Forter declined. **Outcome** is `monitored` or `enforced`. | | `Risk Screening Error` | Warning | Forter was unreachable or timed out. **Outcome** is `failed_open` or `failed_closed`. | | `Risk Screening Review` | Warning | The decision matched `risk.review_on` and the order was held. **Outcome** is `flagged`. | | `Risk Decision Updated` | Warning | Forter sent a webhook changing an earlier decision. | The **Details** field carries the provider, decision, recommendation, mode, fail mode, and Forter's transaction id. Card numbers are never included. The **Event Link** field is a deep link to the order in the Forter Portal. ## Help a customer whose payment was declined In `enforce` mode a declined customer sees only "We could not process your order. Please contact Customer Care." The reason is never shown to them. 1. Open the customer's **Contact** record and go to the **Audit Logs** related list, or open their failed **Cart**. 2. Find the `Risk Screening Declined` row with outcome `enforced`. Its **Event Link** opens the order in the Forter Portal. 3. Either override the decision in the Forter Portal and ask the customer to try again, or take the order over the phone. Forter screens phone orders under separate rules. If Forter later reverses the decision, a `Risk Decision Updated` row appears on the same cart. StoreConnect does not create or change an order from a webhook; the customer must check out again. ## Limitations - Setting **Risk Review** to `Rejected` is not reported to Forter automatically. Forter is told when an order completes, but not when you cancel one. - A webhook from Forter only writes an **Audit Log** row. It never blocks, releases, or changes an order. - Payment providers that take the card on a hosted page or in their own browser component cannot be screened. See [Which payments are screened](#which-payments-are-screened). - A Forter recommendation to run a 3D Secure challenge is recorded but not acted on. - The customer-facing messages can be changed in your theme's translations under `sc.checkout.payment.create.errors.risk_declined` and `sc.orders.risk_review_notice`. ## Troubleshooting **No screening rows appear in the Audit Log.** All three of `risk.provider`, `risk.forter.site_id`, and `risk.forter.api_key` must be set on the store. Check for a typo in `risk.provider`; anything other than `forter` turns screening off. Check that the store's **Audit Log Level** is not `Off` and that you have the **StoreConnect Audit Viewer** permission set. **Every order shows `Risk Screening Error`.** The Site ID or Secret Key is wrong, or the store's server cannot reach `https://.api.forter-secure.com`. Re-copy both values from the Forter **Credentials** page for the same environment. **Forter reports missing cookie data on orders.** The `forterToken` cookie is not reaching the store. Check the Forter **Script Block** in this order: 1. **Active** and **Global** are both checked, and **Channels** includes `Web`. 2. It is assigned to the store that took the orders. 3. No **Cookie** record is linked to it. 4. **Content** holds the snippet for the same environment as `risk.forter.site_id`, without `