Industry Enrichment
Enrich a dispute with a single PATCH using an industry-specific universal_order block, plus the universal fields, domain lookup, and errors for every vertical.
Industry Enrichment via the universal_order field is an upcoming addition to the Enrich Dispute API. The endpoints and schemas described here are not yet in the API reference. This section documents the model ahead of release so you can plan your integration. To enrich disputes today, use the current Enrich a Dispute guide, which covers the live order and transaction payloads.
PATCH /public/2025-04-01/disputes/{disputeId}
You are a merchant enriching a dispute for your industry. Every dispute is a story: the cardholder tells theirs to the issuer, and your job is to give Chargeflow the data to tell yours. Send all your evidence in one universal_order block matched to your vertical, and Chargeflow builds reason-code-aware evidence automatically. No explicit type declaration is needed, just include the right block.
Recommended: Industry Enrichment
Industry Enrichment via universal_order is the most up-to-date way to enrich disputes. It builds reason-code-aware narratives from a single payload tailored to your vertical. Find yours in Choose your block.
How enrichment works
- Your API call - send a
PATCHwithuniversal_ordercontaining your order data and the relevant industry block. - Field analysis - Chargeflow reads the industry fields and identifies the commercial story.
- Evidence builder - Chargeflow crafts a narrative from your data, optimized for the dispute's reason code.
- Submission - the completed evidence package is submitted to the issuer on your behalf.
Quick start
Enrich an accommodation dispute in under five minutes. Swap the accommodation block for your industry's block (see Choose your block), keeping customer and order as the anchors.
curl -X PATCH https://api.chargeflow.io/public/2025-04-01/disputes/dp_01HXYZ \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"universal_order": {
"customer": {
"email": "sarah.chen@example.com",
"name": "Sarah Chen"
},
"order": {
"external_id": "BK-20260315-8842",
"currency": "USD",
"amount": 847.50,
"ordered_at": "2026-02-10T14:23:00Z",
"status": "completed"
},
"accommodation": {
"property_name": "The Oceanview Hotel",
"property_type": "hotel",
"booked_check_in": "2026-03-15",
"booked_check_out": "2026-03-18",
"actual_check_in": "2026-03-15T16:02:00Z"
}
}
}'Once the request succeeds, Chargeflow detects the industry from the block, analyzes the fields against the reason code, builds a tailored narrative, and submits it to the issuer.
Re-enrichment
Disputes are re-enrichable by design. Call the endpoint again with new evidence whenever you have it. Chargeflow uses upsert semantics: send only the fields you have and they are added or updated.
`order` vs `universal_order`
These fields are mutually exclusive. A request with both returns a 400. The transaction field can be sent alongside universal_order without issue. See Error responses.
Universal fields
Every universal_order payload shares the same outer envelope. The industry block (accommodation, flight, dining, etc.) tells Chargeflow the commercial story; the envelope carries the cross-industry data. You never specify the type explicitly.
Everything is optional
Send whatever data you have. No required fields. Chargeflow builds the best narrative from whatever you provide.
| Field | Type | How Chargeflow uses it |
|---|---|---|
customer | object | Cardholder identity: email, name, phone, customer_since. Long tenure undermines "I never signed up"; a matching name ties the order to the card. |
order | object | The commercial story: external_id, amount, currency, ordered_at, status, confirmation_code, ip_address. |
charges[] | array | Itemized breakdown: charge_type (tax, fee, tip, deposit, discount, credit), amount, description. |
policies[] | array | Consent records: policy_type, consented_at, policy_url, acceptance_method. |
activities[] | array | Event log of event_name + event_at pairs (snake_case names like booking_confirmed, check_in, login). A timestamped audit trail of customer engagement. |
addresses[] | array | Named by kind: billing, shipping, property, venue, pickup, dropoff, provider, other. Supports latitude/longitude for GPS precision. |
refunds[] | array | Refund records: reason, amount, refunded_at, refund_method. |
The order object also supports confirmation fields that strengthen evidence:
| Field | Type | Purpose |
|---|---|---|
confirmation_code | string | The booking or order reference the customer received. |
confirmation_methods | array | How confirmation was sent, e.g. ["email"], ["email", "sms"]. |
confirmation_sent_to | string | The email or phone the confirmation was delivered to. |
confirmation_sent_at | timestamp | When the confirmation was dispatched. |
Recommended data points
A few data points help win most dispute reasons across every industry:
- Customer identity -
nameandemailshow you hold accurate records of your customers. - Addresses -
ip_address, shipping, and billing addresses prove delivery, verify billing/shipping match, and confirm the buyer's location. - Order and product information - descriptions, prices, discounts, refunds, and images show the customer had clear information about the purchase.
Choose your block
Search your industry or pick a card. Each block opens with what it covers, the fields that win disputes, and a full payload you can copy. If your platform spans several domains, send the block that matches the specific transaction being disputed: an OTA uses Accommodation for hotel bookings and Flights for air tickets, from the same platform.
Sending data: upsert, arrays, and linking
Call PATCH /{api_version}/disputes/{disputeId} with the Chargeflow dispute ID to add or update enrichment. The endpoint uses upsert semantics: send only the fields you have.
- Arrays are replace-in-full. When you update an array field (for example
productsorfulfillments), the passed array is stored exactly as sent. To add an item, include the existing items and the new one; omitted items are removed. To append safely, read the current array (or use thedispute.createdevent), thenPATCHwith the full array. - Inline vs. linked objects. Send full payloads, or pass IDs of objects already stored in Chargeflow to avoid duplication, e.g.
{ "transaction": "b6acc3e8408d1d6e78797725", "order": "e4d0437fb81cb881cc6bc26a" }. Chargeflow links them and reuses their data. - Multiple disputes on one transaction. Chargeflow reuses enrichment from earlier disputes on the same transaction when possible; pass existing object IDs to force explicit linking.
Error responses
For the full error reference, see Error handling.
| Status | When it occurs |
|---|---|
400 | Both order and universal_order are present in the same request. They are mutually exclusive. |
422 | Dispute status is not needs_response. You cannot enrich a dispute already submitted or closed. |
Mutual exclusivity
order and universal_order cannot coexist in one request. Migrating from the legacy order field to universal_order means removing order from your payload. The transaction field can be sent alongside universal_order.