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:

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.

Every call also carries an explicit module config block that requests SEON's IP, email, and phone reputation modules and device fingerprinting — so those signals are evaluated on every check, rather than depending on account-level defaults in your SEON tenant.

By default, fraud checks fail open. 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.

You can change this per action with If SEON returns an error: Continue (the default, described above) or Halt. Halt applies whenever SEON cannot give a decision — it answers with an error or times out (including when SEON rejects the submitted data as invalid), or its credentials are missing, which is recorded as a configuration error — and stops the step there: the step's later actions (creating the contact, the CRM lead) do not run, and the customer sees a short message asking them to try again, which never names SEON. The halt is recorded in the session's action trace and in API Call Stats. The tradeoff is yours: Halt also blocks signups during a SEON outage.

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:

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

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

session

The device-fingerprint payload collected by SEON's JS agent — captured automatically on journey steps when the agent is configured (Step 1)

sessionId

Your flow's own stable id (sent as SEON's session_id) — used to correlate the checks a single signup makes across steps. Distinct from session: one is the fingerprint blob, the other is your correlation id

transaction_id

Your order / transaction id

brandId

Sent as SEON's top-level brand_id — identifies which of your brands the check belongs to

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

Adding the JavaScript agent (Step 1) is what collects the device fingerprint — it flows to SEON in the session field, and it's the biggest lift in catch rate over email/IP alone. The v6+ agent also collects behavioral signals (such as form-fill duration) and geolocation when configured.

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.

More settings shape the runtime behavior: a timeout (default 3000 ms; a timeout follows If SEON returns an error), If SEON returns an error (Continue by default, or Halt), and a block message (shown to the applicant when the check blocks them — point it at support). The decision mode, threshold, timeout, error handling, 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=<transaction> ST=<state> SC=<score> RLZ=<rule:score;…> — 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) and the action is set to Continue, the check is failing open and letting everyone through. Fix the connection; the errors are visible precisely so you can. A steady stream of SEON errors on one form can also mean the submissions themselves are malformed (for example, an invalid email) — consider Halt.
session vs sessionId. They are different fields, and swapping them silences your best signal: if your flow's own id is mapped into session, SEON never receives real device-fingerprint data. The fingerprint blob goes in session; your correlation id goes in sessionId.
card_last, not card_last4. If you're mapping card fields, SEON's v2.0 API uses card_last.