Skip to main content
One row per event included in a payout, covering both money movement and fees. The sum of payout_amount across the file is the amount paid to your account on the payout date.
The single date in the filename is the payout date, not the period covered. A file named ...-20260912.csv contains events with event_effective_at falling in the settlement period that closed before 12 September.

​
Columns

​
Every row sums

The five component columns add up to payout_amount on every row, with no exceptions:
Debits are negative and credits positive, so the total is a plain sum — you never need to know which columns to subtract.
This means signs differ between reports by design. A refund of 97.00 appears as 97.00 in the transactions report, where the amount is unsigned and direction comes from event_type, and as -97.00 here, where the column feeds an arithmetic total.
Summing payout_amount across the whole file gives the amount credited to your bank account on the payout date.

​
What each event type contributes

ALERT and FRAUD_REPORT rows carry no amount because the event itself moves no money — they are notifications, and only the fee applies. Where an alert led you to refund the payment, that refund appears separately as its own REFUND row.

​
Delayed settlement

delayed_settlement_amount is a proportion of each capture withheld rather than paid out immediately. It is a hold, not a fee: the amount is returned on the agreed release schedule and appears as a separate release event in a later settlement report. Do not treat it as a cost when calculating your effective rate.

​
Adjustments and corrections

Occasionally we need to reverse or adjust an event after it has been settled, for example to correct an incorrect fee or amount. We follow standard accounting practice: finalised events are never edited or deleted. Instead, we post new events that correct the original, such as a reversal of the incorrect event followed by a corrected re-posting. Correcting events reuse the original event_id with a suffix: n counts how many times that event has been reversed or adjusted, starting at 1. A second reversal of the same event would be FRAD_xyz_REV_2. A reversal flips the sign of every amount on the original row: event_amount, each fee column, delayed_settlement_amount and payout_amount. The original and its reversal therefore sum to zero, and the usual row identity still holds on the reversal row.
This keeps every event_id unique across all report types, while letting you trace any correction back to the event it relates to by stripping the suffix.

​
Example

​
Settlement paid out

report_settlement_paid_out-my_merchant-20260912.csv

​
Delayed settlement paid out

report_settlement_paid_out-my_merchant-20260912.csv