Skip to main content

Payrails Fraud SDK provides abstraction on different fraud client SDKs

The SDK should be initialized as soon as possible to enable data collection as soon as possible. The SDK will then pass all the information needed to the Payrails Web SDK without additional work on the merchant client.

Including the SDK

Loading specific fraud providers

The load function accepts an array of providers with merchant specific configurations.

Supported providers

Cybersource

To initialize the Cybersource provider, merchantId and orgId needs to be passed.

Forter

To initialize the Forter provider, siteId needs to be passed.

Ravelin

To initialize the Ravelin provider, key needs to be passed.

Airwallex

Requires environment parameter. orderSessionId is optional and auto-generated if omitted:

Stripe Radar

To initialize the Stripe Radar provider, publishableKey needs to be passed:

Multiple Stripe accounts

Requires @payrails/fraud-sdk 1.9.0 and @payrails/web-sdk 6.1.2 or later. A Radar session is only valid for the Stripe account whose publishable key created it, and Payrails selects the account when the payment is routed, which happens after the session is created. If you process through more than one Stripe account, configure one entry per account, each with that account’s own publishableKey and the providerConfigId of the matching Payrails provider config:
stripe.js loads once regardless of how many entries you configure, and one Radar session is created per entry. The Web SDK sends them all when the payment is authorized, and Payrails uses the one matching the account it routed to. Each entry’s publishable key must belong to the account its providerConfigId points at. A mismatched pair is not rejected up front and instead surfaces as Stripe declining the payment with No such radar session. With a single Stripe account, omit providerConfigId and nothing changes.

Signifyd

To initialize the Signifyd provider, no required fields are needed. Optionally, pass orderSessionId — a merchant-generated session id (fewer than 128 characters, [a-zA-Z0-9_-]). If omitted, a UUID is auto-generated. This value is sent to the backend as device.sessionID.

Riskified

To initialize the Riskified provider, storeDomain needs to be passed (your Riskified shop domain, matching the X-RISKIFIED-SHOP-DOMAIN header on backend API calls). Riskified’s Beacon auto-generates the session id, which is sent to the backend as the order’s cart_token.

HiPay

To initialize the HiPay provider, username, password, and environment need to be passed. username/password are the same public HiPay SDK credentials configured for the HiPay provider in the Payrails portal. lang is optional and defaults to ‘en’. HiPay’s JS SDK collects a device fingerprint synchronously once loaded; this value is sent to the backend as device_fingerprint on the HiPay Order/Authorize API request.
Requires @payrails/fraud-sdk 1.10.0 or later.

Checkout.com

Requires @payrails/fraud-sdk 1.11.0 or later. To initialize the Checkout.com provider, publicKey and environment need to be passed. The SDK loads Checkout.com Risk.js on the page where the shopper pays and creates a device session. With the Payrails Web SDK, the session is sent automatically when the shopper pays, and Payrails passes it to Checkout.com as the risk device session ID.
Load one Checkout.com entry per page, for a single Checkout.com account. If a second entry with a different publicKey or providerConfigId loads on the same page, the SDK rejects it and keeps the first account’s session. The SDK reuses a Risk.js device session on the same page for 15 minutes. After that, the next load creates a new session.

API-only integrations

If you build your own frontend, load Checkout.com Risk.js yourself and send the device session ID in meta.risk.sessions on the authorize request:

HyperPay

Requires @payrails/fraud-sdk 1.12.0 or later. HyperPay uses a ThreatMetrix device session for server-to-server card payments. To initialize the HyperPay provider, orgId and merchantId need to be passed. Get both from HyperPay: the ThreatMetrix Org ID and the HyperPay MID for the account. The SDK loads ThreatMetrix and creates a session ID in the format {MID}_{uuid}. With the Payrails Web SDK or Drop-in, the session is sent automatically with the authorize request, and Payrails passes it to HyperPay as customer.browserFingerprint.id. The session is optional: without it, the payment goes through as before.
Load the HyperPay provider when the payment page opens, not right before the shopper pays. ThreatMetrix needs a few seconds to profile the device. The SDK creates one session per page. Later loads on the same page reuse it, and a new page load creates a new one. ThreatMetrix profiles only once per page, so don’t configure HyperPay together with Cybersource, which also uses ThreatMetrix. If ThreatMetrix is already running on the page, for example from Cybersource or a Signifyd script, the SDK skips HyperPay and logs a console warning. If you have more than one HyperPay MID, load the entry for the MID the payment will be routed to.

Server-to-server integrations

If you run ThreatMetrix yourself, load it on the checkout page with a session ID in the format {MID}_{uuid}, 30 to 128 characters long:
Then send the same session ID in meta.risk.sessions on the authorize request:
  • Add providerConfigId to the entry only if you send sessions for more than one HyperPay config. Payrails uses the session tagged with the config the payment is routed to, and otherwise the untagged HyperPay session.
  • Payrails doesn’t use meta.risk.sessionId for HyperPay.
  • Payrails doesn’t send a session ID outside 30 to 128 characters to HyperPay, so it can’t cause a decline.
  • The session applies only when the shopper is present, not to recurring payments.
Last modified on October 19, 2026