Reference · built on requestConnectorPayments, billing & fraud

Forter

Order validation decisions, order status updates, dispute claims, and evidence uploads through the Forter API and webhooks.

About

Forter is a fraud and abuse prevention platform. A merchant calls the Order API before or after payment authorization and gets back approve, decline, not reviewed, or verification required. The Order Status API then carries fulfillment, cancellation, and compensation updates. Chargebacks reach Forter through forwarded processor webhooks, SFTP files, or its Dispute API, and its Request for Evidence webhook tells you which documents a claim needs and when they are due.

On Fibric, an operator watches those decisions and evidence requests and proposes the reply: mark an order sent or canceled, forward a chargeback, or upload the invoice and proof of delivery a claim asks for. You approve each one, and a record of what was sent stays with the order.

This is a reference listing. It documents what Fibric would read from Forter and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Order decisions from the Order API: action values approve, decline, not reviewed, and verification required, with reasonCode and, in v3, forterDecision and recommendation
  • Notification webhooks registered in the portal's Integration Center under Tools, delivered as JSON POSTs
  • Request for Evidence webhooks carrying claimId, orderId, processorCaseNumber, requestedEvidenceTypes such as INVOICE and PROOF_OF_DELIVERY, dueDate, and hoursLeftUntilDisputed
  • A reminder Request for Evidence when five days remain on a claim still in Pending Evidence
  • Dispute claims Forter ingests from processor webhooks for Adyen, Braintree, Checkout.com, PayPal, PayU Latam, Primer, and Stripe
  • HTTP 429 from the TEST environment above 10 requests per second

Proposed actions

  • Target capability: propose an Order Status API update with updatedStatus processing, sent, completed, canceled by merchant, or canceled by customer, and eventTime
  • Target capability: propose a compensationStatus update naming compensationTypeGranted, reasonCategory, returnMethodGranted, and totalGrantedAmount
  • Target capability: propose forwarding a chargeback through the Dispute API with processorChargebackCaseId, reasonCode, amount, issueDate, and dueDate
  • Target capability: propose uploading a requested file through POST /v3/disputes/evidence/file, or structured data through POST /v3/disputes/evidence/datapoints

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Answer a Request for Evidence before dueDate

    The webhook names the claim, the order, and the evidence types wanted. The operator gathers the invoice and delivery proof from your order system and proposes the upload. You approve, and the evidenceId comes back on the claim.

    With Chargeback Evidence

  • Keep order status current after a decline

    When Forter declines and the order is canceled, the operator proposes the Order Status update with canceled by merchant so the account's history stays accurate.

    With Order Risk, Cancellation Window

  • Report a goodwill credit as compensation

    After a refund or replacement is granted, the operator drafts the compensationStatus update with the reason category and amount and asks you to confirm it.

    With Concession Review, Returns Triage

Requirements

  • A Forter site with credentials from the portal's Credentials page; the TEST site has its own site ID and returns no real decisions
  • An api-version header, for example 10.1, and Content-Type: application/json on each call
  • processorTransactionId or additionalIdentifiers.additionalOrderId on each order, or incoming chargebacks may not match
  • For file evidence, a dispute-evidence folder in the assigned S3 bucket under s3://forter-file-transfer/
  • A webhook endpoint that returns 200 with an application/json body
Authentication
HTTP Basic with the site's API key as the username and an empty password, plus X-Forter-SiteID and an api-version header on every request to https://{site_id}.api.forter-secure.com.

Limits

  • Evidence files must be PDF, JPEG, or PNG, and attachments over 1 MB fail.
  • Evidence is matched only to open claims; files sent for claims that are expired, won, or lost are not matched.
  • A failed webhook is retried a few times over the next hour, and the same event can arrive twice; the connector records each delivery.
  • The Order API and Order Status API reference pages sit behind a portal login. This listing is written from Forter's public guides.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Forter ↗

Questions and answers

When should the Order API be called?
For pre-authorization flows, before the call to your payment gateway. For post-authorization flows, after the gateway responds, and the request must include that authorization response. The reply is approve, decline, not reviewed, or verification required.
How do chargebacks get to Forter?
Four ways: dispute webhooks forwarded from processors such as Adyen, Braintree, Checkout.com, PayPal, Primer, and Stripe; SFTP for processors like Amex and Chase Paymentech; the Dispute API; or an S3 CSV upload as a fallback.
What does a child site need for webhook verification?
A webhook set up on a child site is sent with the parent site's ID, and the parent site's secret key is used to verify it.
Ask about Forter

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.