.png)
Forter Integration Guide
Integrate Forter with commerce, payment, and fulfillment systems through REST APIs for real-time fraud decisions and transaction lifecycle updates.
Forter integration options at a glance
Forter’s primary integration mechanism is a REST API over HTTPS for submitting orders and customer context, receiving fraud decisions, and reporting transaction lifecycle events such as fulfillment, shipment, cancellation, refund, and chargeback outcomes. Forter access generally uses a site identifier and secret key in request headers; the exact format should be confirmed in the tenant’s API documentation. Universal webhooks, GraphQL, SOAP, bulk APIs, file exchange, and direct database access were not confirmed. Martini can expose an API for checkout requests, consume Forter REST endpoints, map JSON payloads, apply business rules, protect credentials with secrets, and route transient failures for controlled retry.
| Integration point | Supported by Forter? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Submit orders and customer context for approve, decline, or review decisions, then report fulfillment, shipment, cancellation, refund, and chargeback outcomes. | Martini can consume Forter REST endpoints, construct JSON requests, map responses, and expose a controlled API for upstream commerce or payment systems. |
| Authentication | Yes | Forter API access generally uses a site identifier and secret key issued for the merchant account and transmitted in HTTPS request headers. | Martini can store Forter credentials in secrets or protected environment configuration and apply them to outbound API requests. Header names and credential formatting should be verified against the current Forter API reference. |
| Webhooks / outbound callbacks | Limited | Some Forter products or account configurations may provide notifications or callbacks, but universal coverage for decisions and lifecycle events was not confirmed. | Martini can receive webhook-style requests when Forter documents and enables them for the relevant tenant, with validation, mapping, deduplication, and error handling. |
| JSON payloads | Yes | Forter’s core integration uses structured JSON containing orders, customers, payments, order items, shipments, and lifecycle information. | Martini can transform upstream application payloads into Forter’s JSON model and map Forter responses into canonical or target-system structures. |
| Synchronous transaction decisions | Yes | Fraud decisions are commonly requested during checkout, payment authorization, or order-management processing. | Martini can expose an API or receive a workflow request, call Forter synchronously, apply business rules, and return the decision with timeout and failure handling. |
| Bulk / async / batch APIs | Not confirmed | A generally available public bulk or batch API for the core transaction decision flow was not confirmed; historical or operational transfers may be account-specific. | Martini can orchestrate scheduled or queued processing only when Forter supplies a supported endpoint or approved export mechanism. |
| File / attachment APIs | Not confirmed | A standard public file or attachment API was not confirmed for Forter’s core integration. | Martini should use Forter’s REST APIs unless the tenant provides a separately documented file or export process. |
| GraphQL APIs | Not confirmed | No generally available Forter GraphQL API was confirmed. | Martini integrations should use Forter REST APIs unless Forter supplies a tenant-specific alternative. |
| SOAP APIs | Not confirmed | No generally available Forter SOAP API was confirmed. | Martini should not design a SOAP-based Forter integration without tenant-specific documentation. |
How Forter exposes data and business events
Forter REST APIs
Forter’s primary integration mechanism is REST over HTTPS. Merchants submit order and customer context for fraud decisions and send later transaction lifecycle updates, including fulfillment, shipment, cancellation, refund, and chargeback information where supported by the API version and account.
Martini implementation pattern
Martini implementation pattern: Martini receives a checkout, payment, or lifecycle request, validates the payload, maps it to Forter’s JSON model, adds the site credentials from protected configuration, calls the Forter REST API, and maps the response or error into the calling application’s model.
Implementation sequence
Synchronous transaction decisions
Forter decisions are commonly used in checkout, payment authorization, and order-management paths where an approve, decline, or review result influences the next business action.
Martini implementation pattern
Martini implementation pattern: Martini exposes a controlled API or receives an upstream workflow request, invokes Forter synchronously, applies merchant-specific routing rules, and returns the result within a defined timeout and fallback policy.
Implementation sequence
Lifecycle API updates
Forter supports sending subsequent transaction information such as fulfillment, shipment, cancellation, refund, and chargeback outcomes. Exact event types and required fields depend on the Forter API version and merchant configuration.
Martini implementation pattern
Martini implementation pattern: Separate Martini workflows consume order-management, fulfillment, payment, or dispute events, correlate them to the Forter order, construct the appropriate lifecycle request, and apply idempotency and retry controls.
Implementation sequence
Webhook-style notifications
A universal Forter webhook mechanism for all decision or lifecycle events was not confirmed. Certain products or account configurations may support callbacks or notifications, which must be verified before implementation.
Martini implementation pattern
Martini implementation pattern: If Forter enables a documented callback for the tenant, Martini exposes an authenticated API endpoint, validates the incoming request, deduplicates the notification, and orchestrates any required follow-up API call.
Implementation sequence
Common Forter integration patterns
Pattern 1: Return real-time checkout fraud decisions
When to use this pattern
Use this pattern when a commerce or payment flow needs an approve, decline, or review decision before continuing. The workflow should separate business decisions from technical failures and define a fallback for Forter timeouts or temporary unavailability.
Integration direction
Example Mapping
| Forter Field | Canonical Field | Target Field |
|---|---|---|
| order.id | transactionId | Forter order identifier |
| customer.email | customer.email | Customer email |
| items[].sku | orderItems[].sku | Order item SKU |
| payment.authorizationId | payment.authorizationId | Payment authorization identifier |
Martini implementation pattern
Martini exposes or receives a checkout request, validates required data, maps customer, address, payment, and item context, calls Forter synchronously, and returns the decision. Approval, decline, and review are routed as business outcomes, while authentication errors, timeouts, and retryable service failures follow separate error paths.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- validation
- business rules
- error handling
Pattern 2: Send payment authorization and lifecycle updates
When to use this pattern
Use this pattern when a payment processor produces authorization, capture, cancellation, refund, or dispute outcomes that must be correlated with Forter’s transaction context.
Integration direction
Example Mapping
| Forter Field | Canonical Field | Target Field |
|---|---|---|
| payment.id | paymentId | Forter payment identifier |
| payment.status | paymentOutcome | Authorization or payment outcome |
| payment.amount | transactionAmount | Forter transaction amount |
| dispute.reason | chargebackReason | Chargeback reason |
Martini implementation pattern
Martini consumes payment events, resolves the related merchant and Forter order identifiers, applies rules for eligible lifecycle events, and submits the corresponding Forter update. Stable keys prevent duplicate effects, and transient failures are retried without retrying a legitimate fraud decision.
Martini capabilities used
- workflows
- API consumption
- data mapping
- correlation
- business rules
- idempotency controls
- error handling
Pattern 3: Synchronize fulfillment and shipment status
When to use this pattern
Use this pattern when an order-management or fulfillment application must report shipment creation, tracking, delivery, cancellation, or refund milestones to Forter after the initial transaction decision.
Integration direction
Example Mapping
| Forter Field | Canonical Field | Target Field |
|---|---|---|
| order.id | orderId | Forter order identifier |
| shipment.trackingNumber | trackingNumber | Shipment tracking value |
| shipment.status | fulfillmentStatus | Forter shipment or lifecycle status |
| shipment.updatedAt | eventTimestamp | Lifecycle event timestamp |
Martini implementation pattern
A Martini workflow receives fulfillment events, validates source identifiers, maps shipment and order fields to Forter’s lifecycle model, and submits the update. The workflow records processing status, rejects stale events where appropriate, and routes retryable API failures to controlled replay.
Martini capabilities used
- event-driven workflows
- API consumption
- data mapping
- validation
- business rules
- retry handling
- monitoring
Pattern 4: Report chargebacks and confirmed fraud
When to use this pattern
Use this pattern when payment processors or finance systems produce dispute and chargeback information that should be reported against the original Forter transaction.
Integration direction
Example Mapping
| Forter Field | Canonical Field | Target Field |
|---|---|---|
| dispute.id | disputeId | Forter chargeback identifier |
| dispute.amount | disputedAmount | Chargeback amount |
| dispute.reason | disputeReason | Forter chargeback reason |
| payment.orderId | orderId | Forter order identifier |
Martini implementation pattern
Martini correlates each dispute to the original order and payment, deduplicates repeated notifications, maps the dispute reason and amount, and submits the Forter update. It stores an operational result for reconciliation and retries connection or service failures without duplicating a successfully submitted event.
Martini capabilities used
- workflows
- API consumption
- data mapping
- deduplication
- business rules
- secrets management
- error handling
Applications commonly integrated with Forter
Forter commonly participates in commerce and payment architectures where transaction context is evaluated before fulfillment or authorization and later lifecycle outcomes are reported. The following applications represent practical integration counterparts; exact product-level support and implementation details should be confirmed for the relevant Forter account.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Submit checkout and order context for fraud evaluation and route Forter decisions into commerce operations. | Shopify → Martini → Forter | Martini exposes or receives an order workflow, maps Shopify customer, payment, address, and item data to Forter JSON, calls the Forter REST API, and returns the decision while preserving correlation identifiers. |
| Adobe Commerce | Evaluate enterprise commerce orders before authorization or fulfillment and synchronize cancellation, refund, and shipment outcomes. | Adobe Commerce → Martini → Forter | A Martini workflow receives Adobe Commerce order events, validates required fields, submits the transaction to Forter, applies approval or review rules, and sends later lifecycle updates through separate controlled paths. |
| Salesforce Commerce Cloud | Support checkout fraud decisions and communicate order, payment, and fulfillment updates. | Salesforce Commerce Cloud → Martini → Forter | Martini acts as an orchestration layer between commerce APIs and Forter, using explicit mappings for customer, payment, order item, shipment, and decision fields and routing technical failures independently from business declines. |
| BigCommerce | Evaluate orders and coordinate approval, review, decline, cancellation, and fulfillment states. | BigCommerce → Martini → Forter | Martini consumes BigCommerce order data, constructs a Forter request, returns the synchronous decision to the commerce workflow, and processes later updates with stable order and event identifiers. |
| SAP Commerce Cloud | Apply Forter decisions to enterprise commerce orders and synchronize post-order events. | SAP Commerce Cloud → Martini → Forter | A reusable Martini workflow normalizes SAP Commerce Cloud order and payment structures into Forter’s JSON model, applies merchant rules, and records request status for reconciliation. |
| Stripe | Correlate payment authorization, capture, refund, and dispute information with Forter transaction decisions. | Stripe → Martini → Forter | Martini receives Stripe payment or dispute notifications where available, correlates them to the merchant order, maps the relevant lifecycle outcome, and submits the update to Forter without treating a fraud decline as a technical retry. |
| Adyen | Coordinate authorization, capture, cancellation, refund, and dispute events with Forter order decisions. | Adyen → Martini → Forter | Martini orchestrates Adyen payment events and Forter lifecycle calls, applying deduplication and retry rules while limiting sensitive payment data in logs and persisted records. |
| WooCommerce | Send checkout and order information to Forter for fraud evaluation. | WooCommerce → Martini → Forter | Martini receives WooCommerce order data through the available application interface, validates and maps it to Forter’s transaction model, and returns or stores the resulting decision for order processing. |
How to build a Forter integration in Martini
Objective
Establish the Forter API configuration using the merchant site identifier and secret key, with HTTPS and protected environment-specific credentials.
Instructions in Martini
- Create protected configuration for the Forter site identifier and secret key
- Confirm the current Forter header names and credential format
- Use Martini secrets rather than embedding credentials in mappings or source code
- Define timeout and sensitive-data logging policies
Objective
Select the business event that starts the integration, such as a checkout request, payment result, fulfillment update, refund, or chargeback notification.
Instructions in Martini
- Use an API-triggered workflow for synchronous checkout decisions
- Use application events or inbound requests for payment and lifecycle updates
- Use a documented Forter callback only if the tenant supports it
- Keep user-facing decision traffic separate from noncritical lifecycle processing
Objective
Accept the source payload and establish the identifiers needed to correlate the event with the Forter order and related payment or shipment.
Instructions in Martini
- Capture merchant order, payment, shipment, and dispute identifiers
- Validate required fields before making the Forter request
- Do not assume general-purpose historical retrieval or pagination is available
- Preserve a correlation identifier for operational tracing
Objective
Coordinate validation, transformation, the outbound Forter call, response handling, and downstream routing in a maintainable Martini workflow.
Instructions in Martini
- Call the Forter REST API through the workflow
- Separate business decisions from transport and service errors
- Apply merchant policies for approval, review, decline, and unavailable-service outcomes
- Reuse common mapping and error-handling logic where appropriate
Objective
Convert commerce, payment, fulfillment, and dispute structures into the Forter JSON request model and normalize responses for the source or target system.
Instructions in Martini
- Map orders, customers, payments, order items, shipments, and chargebacks explicitly
- Validate enum, amount, timestamp, and identifier formats
- Minimize personal and payment data sent to Forter and written to logs
- Map Forter responses into the upstream application’s decision model
Objective
Implement merchant-specific rules for decision routing, lifecycle eligibility, event ordering, deduplication, and fallback behavior.
Instructions in Martini
- Treat approval, decline, and review as business outcomes
- Use stable order, payment, shipment, and dispute identifiers for idempotency
- Prevent stale lifecycle events from overwriting newer state
- Define what happens when Forter is unavailable during checkout
Common Forter data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Orders | Represent the checkout or transaction submitted for a Forter fraud decision and subsequent lifecycle updates. | Commerce platforms, payment systems, order-management systems, Forter | Martini validates merchant and transaction identifiers, maps order fields to Forter JSON, sends the request, and stores correlation and decision status where required. |
| Customers | Provide customer identity, account, behavioral, and historical context associated with an order. | Commerce platforms, customer databases, Forter | Martini maps only required customer attributes, applies data-minimization rules, and avoids exposing unnecessary personal data in logs. |
| Payments | Carry payment method, authorization, wallet, processor, and transaction details relevant to fraud evaluation. | Stripe, Adyen, payment processors, commerce platforms, Forter | Martini correlates payment identifiers and authorization outcomes while protecting sensitive values and excluding full card data or security codes from logs. |
| Order items | Describe products, SKUs, quantities, prices, categories, and item status within an order. | Commerce platforms, ERP or order-management systems, Forter | Martini transforms line-item arrays, normalizes numeric and enum values, and validates required product fields before submission. |
| Shipments | Report fulfillment, shipment creation, tracking, and delivery information after the transaction. | Fulfillment systems, order-management systems, commerce platforms, Forter | Martini maps shipment identifiers, tracking data, status, and timestamps into the applicable lifecycle request and prevents stale updates from overwriting newer state. |
| Chargebacks | Report post-transaction disputes or confirmed fraud outcomes associated with an order or payment. | Stripe, Adyen, payment processors, finance systems, Forter | Martini correlates dispute identifiers to the original order, deduplicates repeated notifications, maps reason and amount fields, and retries only technical failures. |
Authentication and security considerations
Merchant credentials and HTTPS
Forter API access generally uses a site identifier and secret key issued for the merchant account. Requests should use HTTPS, and the exact header names and credential format should be confirmed in the current Forter API documentation.
Credential protection
- Store Forter credentials in Martini secrets or protected environment configuration.
- Do not embed secret keys in workflow mappings or source code.
- Restrict access to workflow configuration, logs, and error payloads.
- Confirm Forter account permissions and product-specific authentication requirements.
Sensitive data minimization
Forter requests can contain payment and identity-related information. Send only the fields required for the use case, and avoid logging full card numbers, security codes, authentication values, or unnecessary personal data.
Operational considerations for Forter integrations
Latency and availability
Fraud decisions can be part of a user-facing checkout path. Configure connection and read timeouts, define a merchant-approved fallback policy, and separate synchronous decision traffic from noncritical lifecycle updates.
Retries and idempotency
Retry transient network, timeout, rate-limit, or explicitly retryable service failures. Use stable order, payment, shipment, and dispute identifiers to distinguish a retry from a new event. Do not automatically retry a legitimate Forter decline.
Rate limits and event ordering
Confirm account limits and retry guidance with Forter. Lifecycle events may arrive out of order, so preserve source timestamps and prevent older events from overwriting newer state.
Schema and testing
Maintain explicit mappings for customers, payments, addresses, order items, device or session context, shipments, refunds, and chargebacks. Test required fields, enum changes, response variations, and API-version changes before production release.
Observability
Monitor request volume, latency, response outcomes, authentication failures, validation failures, retry queues, and reconciliation status. Use correlation identifiers while excluding unnecessary sensitive payload content from logs.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini provides a workflow layer between Forter and commerce, payment, fulfillment, and finance applications. This keeps Forter-specific request and response handling out of multiple point-to-point implementations.
Reusable integration logic
Teams can centralize credential handling, validation, mapping, decision routing, correlation, idempotency, and error handling in reusable workflows and APIs rather than maintaining isolated scripts.
Controlled change management
Explicit mappings and business rules make Forter API-version changes, new lifecycle events, and source-system differences easier to test and deploy without rewriting every upstream application.
Operational reliability
Martini can separate business outcomes from technical failures, apply controlled retry policies, monitor workflow execution, and route failed events for investigation or replay.
Frequently asked questions
Forter is primarily integrated through REST APIs over HTTPS. Commerce, payment, and order-management systems submit order and customer context for fraud decisions, while subsequent fulfillment, shipment, cancellation, refund, and chargeback outcomes can be sent through lifecycle API requests where supported. Forter generally authenticates requests with a site identifier and secret key.
Yes. Martini can integrate with Forter by consuming its REST APIs, mapping order, customer, payment, item, shipment, and chargeback data, exposing an API for upstream checkout systems, and orchestrating lifecycle updates. Webhook-style callbacks can be handled only if Forter documents and enables them for the relevant product and account.
No. A dedicated Forter connector is not required. Martini can use Forter’s confirmed native integration mechanisms, principally its REST APIs and merchant credential authentication, with workflows handling request construction, mapping, business rules, retries, and error routing.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Forter. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Forter, cloud infrastructure, payment providers, or other third-party systems depending on subscription, usage, and deployment model.
Use Forter’s REST APIs for new integrations. They support transaction decisions and related lifecycle communication over HTTPS. GraphQL and SOAP were not confirmed, and a general-purpose public bulk, file, or database interface was not confirmed.
A universal Forter webhook model for all decisions and lifecycle events was not confirmed. Some products or account configurations may support notifications or callbacks. The capability, authentication requirements, event coverage, and payload contract should be verified with Forter before designing an inbound Martini workflow.
Martini receives checkout, payment, fulfillment, refund, or dispute data, maps it to Forter’s transaction-oriented JSON model, calls the relevant REST endpoint, and maps the response or status back to the source system. Stable order, payment, shipment, and dispute identifiers support correlation and deduplication.
Martini can explicitly map and transform nested Forter concepts such as Orders, Customers, Payments, Order items, Shipments, and Chargebacks. Validation and business rules can normalize amounts, timestamps, identifiers, statuses, and required fields while limiting sensitive values in logs.
Treat authentication, validation, rate-limit, timeout, and service failures as technical conditions with appropriate routing and controlled retry. Treat an approve, decline, or review result as a business response, not an automatic retry condition. Stable transaction and event identifiers help prevent duplicate effects.
Yes. Martini can expose a controlled API that presents a stable interface to commerce, payment, or order-management applications, then validate and transform requests before calling Forter. This can isolate upstream systems from Forter-specific payload structures while centralizing credentials, business rules, and error handling.
Related Martini documentation
Workflows
Integrate Forter with Martini
Use Martini to connect Forter with commerce, payment, fulfillment, and finance systems through governed APIs and workflows. Request an integration briefing to define the transaction flows, data mappings, authentication model, and operational controls for your Forter environment.