Reference · built on requestConnectorPayments, billing & fraud

Chargeflow

Disputes, pre-chargeback alerts, evidence uploads, and dispute webhooks through the Chargeflow Merchants API, version 2025-04-01.

Request accessPricing ↗

About

Chargeflow is a chargeback automation service. It pulls disputes from your connected payment processors into one model with a stage (inquiry, chargeback, pre_arbitration, arbitration) and a status (needs_response, under_review, won, lost), drafts the rebuttal, and submits it. Its Merchants API at api.chargeflow.io exposes those disputes, pre-chargeback alerts from Ethoca, CDRN, RDR, and fraud warnings, and endpoints for adding evidence and order data to a case.

An operator on Fibric listens for dispute.created and alert events, pulls the order, shipment, and support history behind each one from your other systems, and proposes the enrichment or refund that follows. You approve, the connector makes the call, and the dispute keeps a record of what was added.

This is a reference listing. It documents what Fibric would read from Chargeflow 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

  • Disputes from GET /disputes and GET /disputes/{disputeId}, with source, source_id, reason, due_by, amount, currency, status, stage, and closed_at
  • Expanded transaction, order, subscription, and customer_communication objects on a dispute through the expand query parameter
  • dispute.created webhooks wrapped in type, data, creationDate, and webhookId, signed in X-Chargeflow-Hmac-Sha256
  • Pre-chargeback alerts from GET /alerts, filtered by type (fraud_warning, ethoca, cdrn, rdr, other), status, reason, and created_at range
  • alerts.created, alerts.transaction.linked, and alerts.updated webhooks delivered flat, with status alerted, pending, refund_initiated, or prevented
  • Key and account health from GET /health-check and GET /health-check/access-key

Proposed actions

  • Target capability: propose enriching a dispute with transaction and order data through PATCH /disputes/{disputeId}
  • Target capability: propose uploading a file through POST /disputes/{disputeId}/evidence with evidenceUploadCategory tracking_information, customer_communication, invoice, additional_evidence, or additional_notes
  • Target capability: propose attaching a support thread through POST /customer-communication, linking messages with sender, date, and body_plain_text to one or more disputes
  • Target capability: propose reporting an alert's outcome through POST /alerts/{alertId}/outcome as refunded, previously_refunded, duplicate, decline, error, or transaction_not_found
  • Target capability: propose adding subscription details to a dispute through POST /disputes/{disputeId}/subscription

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

What you can build

  • Enrich a new dispute with the order behind it

    dispute.created arrives with reason and due_by. The operator finds the order and shipment in your commerce platform and proposes a PATCH with transaction and order data before Chargeflow submits the rebuttal.

    With Chargeback Evidence

  • Refund on a pre-chargeback alert

    An alerts.created event names the transaction and network details. The operator checks your refund policy, proposes the refund in your processor, and then proposes reporting the outcome as refunded.

    With Refund Policy, Concession Review

  • Attach the support conversation to a delivery dispute

    For a dispute the customer raised as not received, the operator pulls the support thread and proposes a customer-communication ticket linked to the dispute id.

    With Delivery Dispute, Chargeback Evidence

Requirements

  • An active Chargeflow account; any account can generate an API key with no plan requirement or approval step
  • Requests addressed to https://api.chargeflow.io/public/2025-04-01
  • An HTTPS endpoint on your side that accepts POST and answers 2XX, registered with + Add Webhook under Settings → Developers
  • A Chargeflow Alerts subscription for the /alerts endpoints and alert events
Authentication
An API Access Key sent in the x-api-key header, generated under Settings → Developers in the Chargeflow App, with an optional HMAC-SHA256 signature over method, path, and body in x-chargeflow-hmac-sha256 using the API Secret Key.

Limits

  • Rate limits are not yet published. A 429 response carries a Retry-After header, and Chargeflow asks for exponential backoff.
  • Array properties on PATCH /disputes/{disputeId} are overwritten in full, so every item to keep must be resent.
  • The alert outcome endpoint applies only to the merchant-managed handling model.
  • Alert webhooks carry the alert type in their type field, not the event name, so the connector tells them apart by payload shape.

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 Chargeflow ↗

Questions and answers

How does the connector check that a webhook came from Chargeflow?
Each POST includes an X-Chargeflow-Hmac-Sha256 header, an HMAC-SHA256 over the method, path, and body, signed with your API Secret Key. The Access Key and Secret Key have separate jobs; the Secret Key is never sent as x-api-key.
What do the dispute stage and status mean?
Stage is where the case sits in the network's escalation path: inquiry, chargeback, pre_arbitration, arbitration, and it only moves forward. Status is who the case waits on: needs_response, under_review, won, or lost. The two advance on their own triggers.
How are list results paged?
List endpoints take a zero-based offset and a limit, default 25 and at most 100, and return a pagination object with totalCount, offset, limit, and totalPages.
Ask about Chargeflow

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Chargeflow 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