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.
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.
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.
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.
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.
This connector listing is developed, published, and supported by Fibric. It describes integration with Forter through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy