Ellipse Gradient for Header

Signifyd Integration Guide

Connect Signifyd's REST API and selected webhook notifications to ecommerce, order, payment, finance, and support workflows.

Signifyd integration options at a glance

Signifyd's primary integration mechanism is its REST API, which accepts ecommerce order, customer, payment, shipping, product, and transaction information for assessment and returns decisions and related order state. Signifyd also supports webhook-style or callback notifications for selected order and case lifecycle events, although coverage is not universal across all objects and transitions. Martini can authenticate with a Signifyd API key stored in secure configuration, transform commerce data into Signifyd request models, expose an API for inbound notifications, and route results to operational systems. Scheduled workflows can reconcile decisions, guarantees, and cases where supported endpoints provide filtering, timestamps, pagination, or status retrieval.

Integration pointSupported by Signifyd?Common use casesHow Martini supports it
REST APIsYesSubmit Order data containing customer, payment, shipping, product, and transaction information, then retrieve Decisions, Guarantees, Cases, and related order state where supported.Martini workflows can consume Signifyd HTTPS endpoints, map request and response models, expose reusable APIs, and apply business rules around returned decisions.
Webhooks / outbound callbacksLimitedReceive selected order, case, decision, or guarantee lifecycle notifications. Coverage should be confirmed for the merchant's enabled products and event types.Martini can expose a REST API to receive notifications, validate and correlate them, route them to downstream workflows, and handle replay or reconciliation.
AuthenticationYesSignifyd API requests use an API key associated with the merchant account and credential permissions, typically supplied in a request header.Martini can store the API key in secrets or environment-specific secure configuration and apply it to outbound REST requests.
Scheduled synchronizationYesReconcile Signifyd Orders, Decisions, Guarantees, or Cases when applicable endpoints support filtering, timestamps, pagination, or status-based retrieval.Martini scheduler-triggered workflows can maintain checkpoints, retrieve changed data, compare states, and repair missed notifications.
Pagination and incremental retrievalLimitedCollection retrieval and incremental synchronization depend on the applicable Signifyd endpoint and its documented filtering or pagination model.Martini can implement endpoint-specific pagination, timestamps, checkpoints, late-arriving update handling, and controlled concurrency.
Bulk / async / batch APIsNot confirmedNo general-purpose Signifyd bulk or batch API was confirmed in the supplied research.Martini can orchestrate individual REST operations or scheduled processing, but a bulk Signifyd capability should not be assumed.
File / attachment APIsNot confirmedNo general-purpose file import, export, or attachment API was confirmed for the core merchant integration.Martini should use confirmed REST endpoints and callbacks rather than assuming a Signifyd file exchange mechanism.
GraphQL APIsNot confirmedNo official Signifyd GraphQL API was confirmed.Martini can consume GraphQL generally, but Signifyd integrations should use the confirmed REST API instead.

How Signifyd exposes data and business events

Signifyd REST APIs

Signifyd's REST API is the principal merchant integration mechanism. It is used to submit ecommerce Orders containing customer, Payment, shipping, product, and transaction information and to retrieve or process Decisions, Guarantees, Cases, and related state where supported by the applicable API version and product configuration.

Martini implementation pattern

Martini implementation pattern: a workflow receives an order or operational request, authenticates with a Signifyd API key, maps the source model to the documented Signifyd payload, invokes the REST endpoint, interprets the response, and writes the result to commerce or operational systems. Reusable Martini APIs can abstract Signifyd operations from calling applications.

Implementation sequence

Receive an order or operational request
Validate required Signifyd fields and correlation identifiers
Map customer, payment, shipping, product, and transaction data
Call the Signifyd REST endpoint with the secured API key
Interpret the Decision, Guarantee, or Case response
Apply merchant business rules and update downstream systems

Signifyd webhook-style notifications

Signifyd supports webhook-style or callback notifications for selected order and case lifecycle events. This is partial event coverage, so event types, delivery behavior, authentication, and retry expectations must be confirmed for the merchant account.

Martini implementation pattern

Martini implementation pattern: expose a secured Martini REST API for Signifyd notifications, validate the request and its correlation data, acknowledge the callback appropriately, and run downstream updates through a workflow. Idempotency and scheduled reconciliation protect against duplicate or missed notifications.

Implementation sequence

Receive the Signifyd notification at a Martini REST API
Authenticate and validate the incoming request
Identify the related Order or Case
Check idempotency state before downstream changes
Map the event to commerce, finance, support, or fulfillment data
Acknowledge the notification and process longer work asynchronously where appropriate

Signifyd scheduled reconciliation

Scheduled synchronization can recover missed notifications and compare Signifyd state with commerce or financial systems when the applicable REST endpoints support filtering, timestamps, pagination, or status-based retrieval.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that retrieves relevant Signifyd objects, follows the documented collection and pagination behavior, compares current state with stored checkpoints and target-system state, and applies only required idempotent updates.

Implementation sequence

Start a scheduled reconciliation workflow
Load the last successful checkpoint
Retrieve changed Signifyd objects using supported filters
Follow pagination and account for late-arriving updates
Compare Signifyd state with the target system
Write differences and store the new checkpoint

Common Signifyd integration patterns

Pattern 1: Submit checkout orders for decisioning

When to use this pattern

Use this pattern when a commerce platform needs a Signifyd assessment before fulfillment or another order transition. The workflow should submit a complete but minimized Order payload and return the Decision to the commerce or order-management process quickly enough for the merchant's checkout requirements.

Integration direction
Shopify
Martini
Signifyd
Example Mapping
Signifyd FieldCanonical FieldTarget Field
merchantOrderIdorder.externalIdOrder.orderId
customer.emailcustomer.emailCustomer.email
payment.amountpayment.totalAmountPayment.amount
lineItemsorder.itemsOrder.products
Martini implementation pattern

Martini receives the source order through an API, event, or scheduled workflow, validates required fields, maps customer, payment, shipping, and product data, and calls Signifyd's REST API. It applies approval, hold, rejection, or review rules to the response, returns the outcome to the commerce process, and retries transient failures while routing validation and authorization errors to exception handling.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • secure configuration
  • error handling

Pattern 2: Route Signifyd events to order operations

When to use this pattern

Use this pattern for selected Decision, Guarantee, or Case lifecycle notifications that need to update commerce, fulfillment, finance, or customer-service systems after the initial order assessment.

Integration direction
Signifyd
Martini
Salesforce
Example Mapping
Signifyd FieldCanonical FieldTarget Field
orderIdorder.externalIdSalesforce.Order_Reference
caseIdfraudCase.idCase.ExternalId
decisionrisk.decisionCase.Decision
guaranteeStatusfinancialProtection.statusCase.GuaranteeStatus
Martini implementation pattern

A Martini REST API receives the callback, validates its authenticity and correlation fields, checks whether the event was already processed, and starts a workflow that maps the event to the target application. The workflow separates fraud, guarantee, fulfillment, and payment state, records processing outcomes, and supports replay when downstream systems are unavailable.

Martini capabilities used
  • API exposure
  • webhook consumption
  • workflows
  • data mapping
  • idempotency rules
  • error handling

Pattern 3: Reconcile decisions and guarantees

When to use this pattern

Use this pattern when a merchant needs a periodic control process to detect missed callbacks, late-arriving changes, or mismatches between Signifyd and commerce or financial systems.

Integration direction
Signifyd
Martini
NetSuite
Example Mapping
Signifyd FieldCanonical FieldTarget Field
signifydOrderIdorder.riskProviderIdNetSuite.Signifyd_Order_ID
decisionrisk.decisionNetSuite.Risk_Decision
guaranteeStatusfinancialProtection.statusNetSuite.Guarantee_Status
updatedAtsync.lastChangedAtNetSuite.External_Last_Updated
Martini implementation pattern

A scheduled Martini workflow loads a checkpoint, retrieves applicable Signifyd objects using supported filters and pagination, compares them with NetSuite state, and writes only material differences. It uses merchant order and Signifyd identifiers for correlation, handles late updates, persists failures for replay, and advances the checkpoint only after successful processing.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination handling
  • data mapping
  • checkpoint management
  • retry and reconciliation

Pattern 4: Route post-transaction cases and exceptions

When to use this pattern

Use this pattern when a post-transaction fraud case, payment issue, unavailable Signifyd object, or integration failure requires action by support, finance, or an exception-management team.

Integration direction
Signifyd
Martini
ServiceNow
Example Mapping
Signifyd FieldCanonical FieldTarget Field
caseIdexception.externalIdServiceNow.CorrelationId
caseTypeexception.categoryServiceNow.Category
orderIdorder.externalIdServiceNow.OrderReference
caseStatusexception.statusServiceNow.State
Martini implementation pattern

Martini consumes a supported Signifyd case notification or retrieves the current Case, classifies it with business rules, and creates or updates a ServiceNow incident or case. It enriches the work item with order and merchant identifiers, avoids duplicate tickets, and sends permanent mapping failures to a separate review queue.

Martini capabilities used
  • workflows
  • API consumption
  • business rules
  • data mapping
  • idempotent updates
  • exception routing

Applications commonly integrated with Signifyd

Signifyd commonly sits between ecommerce, payment, order-management, financial, customer-service, and exception-management applications. The following are representative enterprise architecture patterns; exact availability depends on the merchant's application configuration and Signifyd products.

Application Scenario Direction Martini Pattern
Shopify Send checkout and order information to Signifyd for assessment and return decisions to commerce operations. Shopify → Martini → Signifyd A Martini workflow receives Shopify order data, maps customer, payment, shipping, and line-item fields, submits the order to Signifyd, and routes the decision back to Shopify or an order-operations process. Callback handling and reconciliation can update later state changes.
Salesforce Commerce Cloud Assess orders before fulfillment and synchronize Signifyd decisions or guarantee state with commerce operations. Salesforce Commerce Cloud → Martini → Signifyd Martini exposes or consumes the commerce event, transforms the order into the Signifyd REST model, applies approval or review rules, and writes the result back to Commerce Cloud. Selected callbacks can initiate later updates.
Adobe Commerce Submit order, customer, payment, and fulfillment data for fraud screening and route decisions into the commerce workflow. Adobe Commerce → Martini → Signifyd A Martini workflow consumes Adobe Commerce order data, validates required fields, submits an assessment to Signifyd, and updates order status or review routing while recording correlation identifiers and failures.
BigCommerce Send orders for risk assessment and update order status or review queues based on Signifyd results. BigCommerce → Martini → Signifyd Martini maps BigCommerce orders to Signifyd payloads, invokes the REST API, applies merchant-specific approval, hold, or rejection rules, and sends the resulting state to BigCommerce with retry and duplicate protection.
NetSuite Synchronize approved orders, guarantee information, and post-transaction outcomes with ERP and financial operations. Signifyd → Martini → NetSuite Martini consumes Signifyd decisions, guarantees, or cases, enriches them with commerce identifiers, maps them to NetSuite records, and routes unavailable-record or validation failures to an exception workflow.
Salesforce Create or update customer-service or fraud-review records when Signifyd cases or decision changes require operational follow-up. Signifyd → Martini → Salesforce A Martini API receives selected Signifyd callbacks, validates and correlates the order or case, transforms the event into Salesforce fields, and performs idempotent updates with replay handling.
ServiceNow Route fraud, fulfillment, or integration exceptions into incident and case-management workflows. Signifyd → Martini → ServiceNow Martini classifies Signifyd failures, case changes, or operational exceptions, maps them to ServiceNow incident or case data, and maintains correlation information for resolution and audit.
Stripe Correlate payment transaction data and post-payment outcomes with Signifyd order assessments and downstream processing. Stripe → Martini → Signifyd Martini combines payment and commerce context, maps the required transaction and order fields to Signifyd, processes the decision, and propagates relevant outcomes to payment or order-management systems without assuming a native connector.

How to build a Signifyd integration in Martini

Objective

Establish the Signifyd REST integration using the account's API key and environment-specific configuration.

Instructions in Martini

  • Confirm the current Signifyd API version, endpoint paths, header spelling, and account permissions.
  • Store the API key in Martini secrets or secure environment configuration.
  • Configure the outbound REST request and avoid embedding credentials in workflow logic.

Objective

Select the trigger that matches the required timing and Signifyd capability.

Instructions in Martini

  • Use an inbound Martini REST API or source event for checkout decisioning.
  • Receive selected Signifyd callbacks through a secured Martini REST API.
  • Use a scheduler for reconciliation and recovery processing.

Objective

Acquire Orders, Decisions, Guarantees, Cases, Customers, and Payments through confirmed REST operations or selected notifications.

Instructions in Martini

  • Validate incoming source payloads and correlation identifiers.
  • Retrieve current Signifyd state when a callback contains only an event or reference.
  • Implement documented pagination, filtering, and checkpoint behavior where applicable.

Objective

Coordinate the Signifyd call, downstream updates, business-state decisions, and asynchronous exception handling.

Instructions in Martini

  • Separate synchronous checkout decisioning from longer-running case or reconciliation work.
  • Branch approved, declined, pending, review, guarantee, and exception states according to merchant rules.
  • Preserve Signifyd and merchant identifiers across each workflow step.

Objective

Convert commerce and operational models into Signifyd request and response models without losing important correlation data.

Instructions in Martini

  • Map customer, payment, shipping, product, and transaction fields carefully.
  • Minimize personal and payment data to what the applicable product requires.
  • Version mappings for Signifyd API and product-specific schema changes.

Objective

Use explicit business rules to determine order routing and post-transaction handling.

Instructions in Martini

  • Define how approved, declined, pending, and review decisions affect fulfillment.
  • Keep fraud, guarantee, payment, and fulfillment states separate.
  • Validate required fields and reject permanent errors without repeated retries.

Common Signifyd data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OrderEcommerce transaction submitted to Signifyd for assessment, including customer, payment, shipping, product, and transaction context.Shopify, Salesforce Commerce Cloud, Adobe Commerce, BigCommerce, NetSuiteMartini maps the source order into the applicable Signifyd request schema, preserves merchant and Signifyd identifiers, and applies validation and duplicate-submission rules.
DecisionSignifyd's assessment outcome and associated risk or guarantee information for an Order.Commerce platforms, order-management systems, NetSuite, SalesforceMartini transforms the decision into target status and business fields, separates approved, declined, pending, and review outcomes, and supports callback or reconciliation updates.
GuaranteeFinancial protection or guarantee associated with an eligible Order.NetSuite, finance systems, order-management systems, commerce platformsMartini correlates Guarantee data to the source order, maps state and identifiers, and synchronizes changes without conflating guarantee state with payment or fulfillment state.
CaseInvestigation or operational case associated with an Order, including fraud review or post-transaction issues.Salesforce, ServiceNow, customer-support and case-management systemsMartini receives selected case notifications or retrieves case data, maps it to operational cases, and routes exceptions for manual review or replay.
CustomerBuyer contact, account, and identity-related information used in order assessment.Shopify, Salesforce Commerce Cloud, Adobe Commerce, SalesforceMartini maps only the fields required by the applicable Signifyd product, applies data-minimization rules, and avoids exposing sensitive values in logs.
PaymentPayment and transaction information used as part of order evaluation.Stripe, commerce platforms, finance and order-management systemsMartini transforms payment context according to the Signifyd request model, protects sensitive data, and retains correlation identifiers rather than unnecessary raw payment payloads.

Authentication and security considerations

API-key authentication

Signifyd API requests use an API key associated with the merchant account and its credential permissions. Confirm the current header spelling and account requirements before implementation.

Credential protection

Store the Signifyd API key in Martini secrets or secure environment-specific configuration. Do not embed credentials in workflow logic or source-controlled mappings.

Data minimization

Order submissions may contain personal, address, payment, device, and transaction information. Send only the fields required by the applicable Signifyd product and merchant process.

Inbound notification security

For callbacks, confirm whether Signifyd supports a signature, shared secret, IP restriction, or another verification method. Protect the Martini endpoint and do not trust unverified order or case identifiers.

Operational considerations for Signifyd integrations

Rate limits and throughput

Confirm account-specific limits and throttling behavior. Use controlled concurrency, avoid duplicate assessments, and retry transient failures with backoff.

Pagination and checkpoints

For collection endpoints, follow the documented pagination model and store a checkpoint such as the last successful timestamp or identifier. Allow for late-arriving updates and clock skew.

Idempotency

Use merchant order identifiers, Signifyd identifiers, and event identifiers where available. Callback processing should tolerate duplicate delivery without creating repeated downstream cases or updates.

State management

Decision, Guarantee, Case, payment, and fulfillment states may change independently. Model them separately and define explicit handling for approved, declined, pending, review, canceled, refunded, and post-transaction conditions.

Testing and schema changes

Confirm the current API version and product-specific schemas, test representative order and callback payloads, and version mappings so optional fields and response changes can be managed safely.

Logging and replay

Persist safe correlation identifiers and failure context for controlled replay, but avoid logging full payment or personal-data payloads. Separate permanent validation or authorization errors from transient failures.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate more than an API call

Martini coordinates inbound orders, Signifyd REST requests, callback handling, reconciliation, downstream updates, and exception workflows in a maintainable integration flow.

Centralize mapping and rules

Reusable mappings and business rules keep commerce, fraud, guarantee, payment, and fulfillment states distinct while allowing each target system to receive the model it needs.

Improve operational resilience

Workflows can implement checkpoints, idempotency, controlled retries, validation, replay handling, and monitoring rather than leaving reliability logic scattered across scripts.

Expose reusable APIs

Martini can expose controlled APIs that abstract Signifyd operations from commerce and operational applications, reducing point-to-point coupling while preserving the ability to customize request and response handling.

Support enterprise change

Environment-specific secrets, versioned mappings, workflow-based orchestration, and reusable integration assets make changes to Signifyd schemas or surrounding applications easier to test and deploy.

Frequently asked questions

How can Signifyd be integrated with enterprise systems?

Signifyd can be integrated primarily through its REST API. Ecommerce systems submit Order data containing customer, payment, shipping, product, and transaction information, then process returned Decisions and related Guarantee or Case state. Signifyd also supports webhook-style notifications for selected lifecycle events, while scheduled REST retrieval can support reconciliation where the applicable endpoints provide filtering, timestamps, pagination, or status retrieval.

Can Martini integrate with Signifyd?

Yes. Martini can consume the Signifyd REST API, authenticate with an API key stored in secure configuration, map commerce and operational data, expose a REST API for selected Signifyd callbacks, and orchestrate updates to commerce, finance, support, and order-management systems.

Do I need a connector to integrate Signifyd with Martini?

No. A dedicated Signifyd connector is not required. Martini can integrate through Signifyd's confirmed REST API, selected webhook or callback mechanisms, API-key authentication, and scheduled workflows for reconciliation.

Is there any extra Lonti cost to integrate Signifyd with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Signifyd. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Signifyd, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.

Which Signifyd integration methods should a new implementation use?

The recommended approach is Signifyd's REST API for submitting Orders and retrieving Decisions, Guarantees, and Cases where supported. Webhook-style notifications can be used for selected lifecycle events, with scheduled reconciliation as a recovery control. GraphQL and SOAP were not confirmed for Signifyd.

Can Martini receive Signifyd events or webhooks?

Yes, Martini can expose a REST API to receive Signifyd webhook-style or callback notifications. Signifyd event coverage is partial, so the supported event types, delivery behavior, authentication or signature requirements, and retry policy should be confirmed for the relevant merchant account and product.

How does synchronization between Signifyd and other systems work?

A Martini workflow can submit commerce Orders to Signifyd, return Decisions to the originating system, process selected callbacks, and periodically reconcile Decisions, Guarantees, and Cases. Checkpoints, pagination, merchant and Signifyd identifiers, and idempotent updates help detect missed notifications and prevent duplicate downstream changes.

How does Martini handle Signifyd data mapping, errors, and duplicate events?

Martini maps customer, payment, shipping, product, transaction, decision, guarantee, and case fields between systems and can apply validation and business rules during transformation. Workflows can distinguish authentication, validation, rate-limit, timeout, and server failures, retry transient errors with controlled backoff, persist failed correlations for replay, and use event or object identifiers to make duplicate processing safe.

Related Martini documentation

APIs

Workflows

Data

Security

Operations

Connect Signifyd with your enterprise systems

Use Martini to orchestrate Signifyd order decisioning, selected event notifications, reconciliation, and downstream operational workflows through secure APIs and reusable integration logic.

EXPLORE MARTINI
BOOK A DEMO