The shared data types, enumeration values, and currency codes used across every FlexFactor report. Reference this page when parsing CSVs, validating data types, or resolving what a given enum value means. Field-level detail per report is in the Field Schema Reference.

Data types

UUID

• Pattern: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12 hex digits)
• Example: c8f3e2a1-5b4d-4c6e-9f8a-1b2c3d4e5f6a
• Use: unique identifiers for entities and transactions

DateTime

• Standard: ISO 8601 UTC
• Pattern: YYYY-MM-DDTHH:MM:SSZ
• Example: 2026-07-22T14:30:45Z
• Timezone: always UTC (the Z suffix). Convert to a local reporting timezone as needed; the stored value does not shift.
• Exception: activity-detail carries EventTimestamp as MM/DD/YYYY HH:MM:SS (e.g. 07/28/2026 14:30:45). The value is still UTC even though no timezone suffix is present — parse this report's timestamps with the US-style pattern.

Decimal (String)

• Pattern: -?[0-9]+(\.[0-9]{1,2})?
• Examples: 1234.56, 0.00, -99.99
• Precision: up to two decimal places. Settlement and disbursement reports carry fixed two-place values (45.70); activity-detail may omit trailing zeros (45.7, 100) — normalize to two places when loading
• Sign: varies by report family — aggregate columns in the flat reports are positive magnitudes you subtract; transaction detail rows and the disbursement-fee RS section are signed (reductions negative). See the sign-conventions table in the Reconciliation Guide

Integer

• Whole-number counts and numeric codes — for example OrderCount, BatchCount, Year, and the numeric CurrencyCode.

String

• Free-text or opaque identifiers — for example ExternalMerchantIdentifier, ExternalId, and ExceptionReason.

Enumeration reference

TransactionType

• Order — sale / purchase transaction
• Return — refund / return transaction

OrderState

The order-status categories (not exhaustive; varies by implementation):

• completed — successfully completed
• refunded — fully refunded (appears in activity-exceptions)
• disputed — disputed / chargebacked
• voided — cancelled / voided
• cancelled — order cancelled
• processing — processing in progress
• onhold — order on hold
• problem — order has issues

Processor-level states such as declined and failed exist but do not appear in the reports — activity reports carry processed transactions only (declined and failed authorization attempts are never reported).

ExceptionType (activity)

• refunded — customer refund
• disputed — chargeback / dispute
• voided — transaction void

ExceptionType (settlement)

• FAILED — batch processing failed
• ERROR — system error
• REJECTED — rejected by the bank

FeeType

• FlexFee — standard processing fee
• FlexReturnFee — refund processing fee
• FlexChargebackFee — chargeback processing fee

PayoutStatus

• SUCCESS — successfully paid
• FAILED — payout failed
• ERROR — payout error
• REJECTED — rejected by the bank
• PENDING — awaiting processing

DisputeStage / Kind (dispute-detail Kind field)

The dispute-detail report does not carry a win/loss status — the Outcome, Status, and Amount Won columns are always empty. Dispute stage is carried in the Kind field, which has ten values:

• RDR — Rapid Dispute Resolution (pre-dispute automated refund)
• CHARGEBACK — standard chargeback dispute
• PRE-DISPUTE — pre-chargeback warning (funds and the dispute fee are debited at this stage, not later at the chargeback stage)
• REVERSED — chargeback reversed / won
• EARLY_WARNING — early fraud-warning alert
• DISPUTE_NOTICE — dispute notice received (TC 15)
• FRAUD_NOTICE — fraud notice received (TC 40)
• UNMAPPED — unknown / unmapped dispute type
• ORDER_INSIGHT — Visa Order Insight inquiry
• CONSUMER_CLARITY — Mastercard Consumer Clarity

Payment Instrument Type

Processor-supplied, not a closed enum, and the value style differs by report:

• activity-detail (PaymentInstrumentType / PaymentInstrumentSubtype) and disbursement-fee (Payment Instrument Type / Payment Instrument Subtype) — Credit Card, with the card brand in the subtype field (Visa, Mastercard, ...).
• dispute-detail — processor values such as credit, debit, and prepaid, with the card brand in the separate Card Type field (VISA, MASTERCARD, ...).

Currency codes

Reports carry the currency both as an ISO 4217 alpha code (the Currency field) and, in some settlement reports, as the ISO 4217 numeric code (the CurrencyCode field).

📘

FlexFactor currently settles in USD (840). The non-USD codes above appear in the schema for forward compatibility. Contact FlexFactor if you expect settlement in another currency.

Field note: in reports that carry both, Currency is the 3-letter alpha code and CurrencyCode is the numeric code. In activity-summary, CurrencyCode is a legacy duplicate of Currency (alpha, not numeric) — see the Field Schema Reference.

Card data fields

Where card data appears, only PCI-compliant partial data is present:

• Bin — first 6–8 digits of the card, or N/A (8-digit BINs appear as card networks migrate to the longer format)
• Last4 — last 4 digits of the card, or N/A

These fields appear in activity-detail, activity-exceptions, and settlement-detail. In dispute-detail, the card number is fully masked (****). No full PAN, CVV, or expiry is present in any report.

Multi-section report format

Two reports (dispute-detail and disbursement-fee) use a Braintree-compatible multi-section format. Each row begins with a record-type prefix identifying which section it belongs to.

Record types

• RH — report header (report metadata; one row)
• RS — report summary (merchant-level aggregation; disbursement-fee only)
• RD — report detail (individual records)
• RF — report footer (record counts and totals; one row)

dispute-detail layout

Each section begins with a header row — the same record-type prefix followed by the section's column names — then its data rows:

RH,Report name,Report status,Report Date and Timestamp,Hierarchy     ← RH header row
RH,Dispute Detail Report,Success,2026-07-29T12:49:50Z,<partner-uuid> ← RH data row
RD,Merchant Account ID,Dispute ID,Original Dispute ID,...            ← RD header row (46 columns)
RD,,<dispute-uuid>,,2026-07-28,2026-07-28,...,PRE-DISPUTE,104,...
RD,,<dispute-uuid>,,2026-07-28,2026-07-28,...,CHARGEBACK,4837,...
RF,File number,Total Records,Total Files                             ← RF header row
RF,1,2,1

disbursement-fee layout

Each section begins with a header row — the same record-type prefix followed by the section's column names — then its data rows:

RH,Report name,Report status,Report date and timestamp,Hierarchy     ← RH header row
RH,Disbursement and Fees,Success,2026-07-29T13:44:17Z,<partner-uuid> ← RH data row
RS,Merchant Account ID,Transfer ID(s),Bank Account,Currency,...      ← RS header row (14 columns)
RS,,AB12CD34,XX,USD,2918.34,0.00,-145.70,0.00,0.00,-507.81,2264.83,0.00,,
RD,Record ID,Merchant Account ID,Record Type,Record Subtype,...      ← RD header row (60 columns)
RD,<uuid>,,Sale,,Acme Store Inc.,...,410.86,...
RD,<uuid>,,Fees,Processing Fee,...,-23.96,...
RD,<uuid>,,Dispute,Chargeback,...,-45.70,...
RF,Page number,Total records,Total pages                             ← RF header row
RF,1,30,1

The RS row above ties out per the formula: Sales 2918.34 + Refunds 0.00 + Disputes -145.70 + Other 0.00 + Net Fees -507.81 = Net Disbursed 2264.83.

When parsing, branch on the first column to route each row to the correct section schema, and skip each prefix's header row. Note the footer carries record/page counts only — the dispute-detail footer is File number, Total Records, Total Files and the disbursement-fee footer is Page number, Total records, Total pages; validate the total-record count against the number of RD data rows actually read.