Skip to main content
One row per transaction attempt. Unlike transactions succeeded, this report also includes failed and declined attempts.
Bounded on event_processed_at.

Columns

event_amount is unsigned in this report — a refund of 97.00 appears as 97.00, not -97.00. Use event_type to determine direction. The settlement report signs the same amount negative, because there the column feeds an arithmetic total.
Failed attempts (event_status = FAILED) do not appear in settlement. Only successful attempts join to settlement paid out on event_id.

Refunds

Refunds need care, because two different identifiers are in play.
  • payment_id is the original payment being refunded, prefixed PAYM_. It is the same value that appears on the corresponding SALE or CAPTURE row.
  • event_id identifies the refund itself, prefixed REFN_.
Do not join refunds to sales on payment_id alone and assume a one-to-one result. A single payment can be refunded more than once, and both refund rows will carry the same payment_id. Always carry event_id through as the row identity.
The prefix tells you what a row is without reading event_type, but it is not a substitute for it — match on event_type in your logic and treat the identifier itself as opaque.

Example

report_transactions_attempted-my_merchant-20261001_to_20261031.csv