> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/integrations/fraud-and-risk/seon-fraud-prevention.md). # SEON PeakCommerce integrates with **SEON** to screen signups and orders for fraud before they're accepted. SEON evaluates an applicant from their email, phone, IP, device, and billing details and returns a fraud score plus the signals (applied rules) behind it — so you can stop bad orders before they ever become a subscription. Watch how to configure the signals your fraud check sends — add a field from the journey's own data, and update an existing one: {% embed url="" %} ## How it works SEON runs as a **`fraud_check` commerce action** on a journey step, powered by a SEON integration you connect once and reuse. It is opt-in and journey-configured: you place the check exactly where a fraudulent signup or order would be costly (signup, checkout) rather than running it as a blanket global guardrail. When a customer reaches the step, PeakCommerce calls SEON's **Fraud API (v2.0)** with the fields you've mapped, receives a **score** and **state** plus the applied rules, and the action returns a decision — **allow** or **block** — that the rest of your journey logic acts on. A block halts the journey with a message you control; an allow lets the remaining actions on the step run. {% hint style="info" %} **Fraud checks fail *****open*****, by design.** If SEON can't be reached — missing credentials, a timeout, an API error, or an unrecognized state — the check returns **allow** so a real customer is never stranded by an outage. Every such event is still recorded in **API Call Stats** with the underlying error, so you can see and fix it. A fraud *block* is only ever the result of SEON actually scoring the applicant as risky. {% endhint %} ## Before you start * A **SEON account** with a license (API) key and, optionally, your SEON **JavaScript agent** URL for device fingerprinting. * Permission to manage integrations in PeakCommerce (the **integrations** resource, create and update) — typically an administrator. * A **journey** where you want to screen applicants — a signup or checkout flow. ## Step 1 — Connect SEON Go to **Settings → Integrations**, choose **SEON**, and fill in the connection:
SEON integration form in Settings, showing API base URL, license key, and JavaScript agent URL fields with a Test connection button

Settings → Integrations → SEON — connect your license key, then test the connection before saving.

| Field | What to enter | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | **API base URL** | Your SEON API host. Defaults to `https://api.seon.io` — leave it unless SEON gave you a regional host. | | **License key** | Your SEON API key. Stored encrypted and never shown back; on edit, leave it blank to keep the existing key. | | **JavaScript agent URL** | *(Optional)* Your SEON device-fingerprinting agent, e.g. `https://cdn.seondf.com/js/v6/agent.js`. Enables device and browser signals. | Click **Test connection** before saving. PeakCommerce sends a minimal, harmless request to SEON's Fraud API — any success confirms the key works; an invalid key surfaces SEON's own error message. The connection is scoped to your tenant; keys are never shared across tenants. ## Step 2 — Add a fraud check to a journey step Open the journey and click **Edit journey**. On the step where screening should happen (e.g. **Signup** or **Payment**), add a commerce action that runs your **SEON** integration's **Fraud check** operation. Place it **before** the actions that create the account or subscription, so a block stops them from running. ## Step 3 — Map the fields SEON evaluates A fraud check is only as good as the data it sends. In the action's **field mappings**, map each SEON request field to a source — a value from the journey's own **context** (the picker in the video above), a **literal**, or a **dynamic**/generated value. Only the fields you map are sent.
The journey action editor for a fraud check, showing the field mappings table, a Test integration panel, and a Response Outputs table that promotes SEON's response into journey context

The fraud-check action editor — field mappings, Test integration, and Response Outputs.

PeakCommerce supports SEON's Fraud API v2.0 request fields, including: | SEON field | Source examples | | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | `email`, `phone`, `ip` | The applicant's email, phone, and IP from the signup form / session | | `sessionId`, `transaction_id` | Session token from the JS agent; your order / transaction id | | `transactionAmount`, `transactionCurrency` | Order total and currency | | `user_firstname`, `user_lastname`, `user_dob` | Name and date of birth | | `card_bin`, `card_last`, `card_hash`, `card_fullname` | Card metadata (v2.0 uses `card_last`, **not** `card_last4`) | | `billing_country`, `billing_city`, `billing_region`, `billing_zip`, `billing_street`, `billing_street2` | Billing address (flat fields in v2.0) | | `customFields.*` | Any extra key/values you want SEON to see | {% hint style="info" %} Adding the **JavaScript agent** (Step 1) lets you pass a `sessionId` so SEON can factor in device and browser fingerprint signals — a big lift in catch rate over email/IP alone. {% endhint %} ## Step 4 — Test the payload, then promote the result The action editor has two more sections below the field mappings: * **Test integration** — a pre-flight that resolves the payload from sample context and catches problems (like a bad value) before you rely on the action live. Run it once your mappings are in place; no order is required. * **Response Outputs** — promote fields from SEON's response into the journey's **context** so later actions on the step can use them. Tick **Promote** on the rows you need and name the **context key** (e.g. `score → seonScore`, `state → seonState`). Promoted keys are available downstream via the Context source or `(key)` expression tokens — which is how the Zuora writeback below gets the values it writes. Common promotions: `decision`, `transactionId`, `score`, `state`, `applied_rules`, `labels`, `latencyMs`. ## How the decision is made You don't have to configure anything for the check to work — sensible defaults apply — but it helps to know how SEON's response becomes allow / block: * **Score mode** *(default)* — block when the fraud **score** is **at or above the threshold** (default **20**), otherwise allow. A missing score allows. Lower the threshold to catch more (and risk blocking good customers); raise it to be more permissive. * **State mode** — act on SEON's **state** instead of the number: **APPROVE** or **REVIEW** → allow; **DECLINE** → block; anything unrecognized → fail-open (allow, and logged). In state mode the threshold is ignored. State matching is case-insensitive. Two more settings shape the runtime behavior: a **timeout** (default **3000 ms**; on timeout the check fails open) and a **block message** (shown to the applicant when the check blocks them — point it at support). The decision mode, threshold, timeout, and block message are part of the fraud-check action's configuration; the defaults above apply until you change them. ## What gets recorded A fraud check leaves a trail you can act on downstream: * **On the customer** — the fraud **score** and **state** are stamped on the user record, so you can see how any customer scored. * **In journey context** — whatever you promote in **Response Outputs** (decision, transaction id, score, state, applied rules, labels) becomes available to later actions on the step. * **In your billing system** — a subsequent **Update account** action can write the result back to Zuora's `SeonFraudResult__c` field via an expression, in the compact form `ID= ST= SC= RLZ=` — for example `ID=a7bdbc2bd8c8 ST=APPROVE SC=1.0 RLZ=E122:1.0`. This keeps the fraud verdict alongside the account for later reference and reporting. ## Gotchas & troubleshooting * **A fraud block is never silently skipped.** Unlike other actions, a `fraud_check` block is a security decision — it can't be bypassed by continue-on-failure or retry settings. * **SEON is fraud-only.** It carries no catalog, accounts, or billing — it *scores*, and other actions (create order, update account) act on that score. Don't expect it to write subscriptions or invoices. * **"Everything is being allowed through."** Check **API Call Stats** for SEON errors — if calls are failing (bad key, timeout, wrong base URL), the check is failing *open* and letting everyone through. Fix the connection; the errors are visible precisely so you can. * **`card_last`, not `card_last4`.** If you're mapping card fields, SEON's v2.0 API uses `card_last`. ## See also * [Fraud and risk integrations](/integrations/fraud-and-risk/fraud-and-risk.md) * The fraud-check step is a *commerce action* — see the Commerce Actions guide for how actions run on journey steps. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/integrations/fraud-and-risk/seon-fraud-prevention.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.