Screen orders for fraud with Forter

Use this process to connect a store to Forter 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. 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.

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.

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.

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.

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://<site_id>.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.
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.

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 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 <script> and closing </script> tags. StoreConnect adds them.
Script URL	Leave blank. If this field has a value, Content is ignored.

1. 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.
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 <head> 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 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.

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 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.
• 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://<site_id>.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 <script> tags.
5. If the store enforces a custom content security policy, the policy includes Forter’s rules. The browser console shows a blocked-script error when it does not.

Then open the page where the affected customers paid, such as a payment link page, and confirm the forterToken cookie is set. Orders from subscription renewals never carry the cookie because no customer browser is involved.

Forter’s webhook test returns 401. The Basic authentication username in Forter must equal risk.forter.webhook_secret, or the Secret Key when that variable is blank. The password must be empty.

Orders are held but Released and Rejected do not stick. The Risk Review field is syncing one way. Ask StoreConnect support to set it to read/write for your environment.

Every subscription renewal is declined or held. Renewals present a placeholder IP address to Forter. Ask Forter to exclude that address from IP and location rules for your site.