Transaction Reports

Use the Reports API to retrieve your tenant’s daily report of card transactions from the network. You can use this report to reconcile user balances and verify collateral liquidations, and the monthly report to reconcile your invoice.

The daily and monthly report endpoints are currently functional only in production. Requests in sandbox do not return report data.

When Reports Are Available

The settlement cutoff is 12:00 PM UTC each day. Daily reports are generated between approximately 3:00 PM – 3:30 PM EST and include all transactions posted since the previous day’s cutoff. For example, a report generated in the afternoon today contains transactions posted from 12:00 PM UTC yesterday through 12:00 PM UTC today.

What the Report Includes

The report contains spend transactions — both settled and not-yet-settled — plus late_settlement_adjustment rows (settlement adjustments that post after the original transaction’s billing period). Other transaction types such as fees or collateral deposits are not included. A transaction that hasn’t settled yet appears with ledgerSettlementAmount and interchangeAmount of 0. Once it settles, those fields populate and its transactionDate moves from the posting date to the settlement date.

Field Descriptions

Column	Description
`transactionId`	Transaction ID
`transactionDate`	Settlement-grain timestamp (ISO format) — the ledger book-entry time, falling back to the posting time. Use this column when reconciling volume figures.
`transactionType`	`spend` for card spend, or `late_settlement_adjustment` for a settlement adjustment posted after the original transaction’s billing period
`status`	Authorization status
`merchantName`	Merchant name
`merchantCategoryCode`	MCC (defaults to `“0000”` if empty)
`authorizationAmount`	Original authorization amount (in minor units)
`authorizationCurrency`	Currency of the authorization
`settlementAmount`	Final settled amount (in minor units)
`settlementCurrency`	Currency of the settlement (falls back to auth currency)
`interchangeAmount`	Raw interchange fee amount for this transaction, scaled by 10^6 (divide by 1,000,000 to get the actual value). This is the per-transaction interchange only. A separate process aggregates all interchange amounts, deducts Rain’s share, adds applicable FX fees, and calculates the total amount owed to the tenant — that aggregated data is not available at the per-transaction level in this report.
`cardId`	Card ID
`cardLast4`	Last 4 digits of the card
`cardholder`	Full name (from cardholder user or fallback user)
`isThreeDSecureTransaction`	Whether 3DS was used
`isATMTransaction`	Whether the MCC indicates an ATM withdrawal
`isATMPremiumTransaction`	Whether the ATM amount exceeds the tenant’s premium threshold
`visaProductType`	Card product type name (from BIN range)
`tokenRequestorId`	Raw token requestor ID
`walletName`	Resolved wallet name (`ApplePay`, `GooglePay`, `SamsungPay`, `GarminPay`, `FitbitPay`, `FidesmoPay`, or `null`)
`isNetworkChipAuthentication`	Whether it was a physical chip-authenticated transaction
`isInternationalTransaction`	Whether it was an international transaction
`foreignExchangeFees`	The international fee amount charged when `sourceCurrencyCode` is not USD. Only one of `foreignExchangeFees` or `crossBorderFees` can be non-zero per transaction. Defaults to `“0”`.
`crossBorderFees`	The international fee amount charged when `merchantCountryCode` is not US or PR. Only one of `foreignExchangeFees` or `crossBorderFees` can be non-zero per transaction. Defaults to `“0”`.
`merchantCountryCode`	The merchant’s country code (may be empty if not available)
`ledgerSettlementAmount`	Ledger-net settled volume for this transaction (in minor units) — the amount that actually moved in the ledger. `0` when no posted ledger entry matches (for example, auth-only rows or dispute reimbursements). Sum this column to reconcile invoice volume.
`postedAt`	Timestamp the transaction posted to the network (ISO format). Equals `transactionDate` for nearly all rows; the two diverge only when a settlement’s ledger entry lands in a different period than the posting (for example, delayed dispute resolutions). Use this column when reconciling transaction counts.
`tenantId`	The tenant the transaction is stamped to. Use this column when reconciling transaction counts.
`billingTenantId`	The tenant whose invoice this transaction’s volume rolls up to. Empty when the volume is not billed to any tenant. Use this column when reconciling volume figures.

Daily vs. Monthly Reports

Daily and the monthly report are produced the same way: a report includes every row whose transactionDate or postedAt falls in the report’s window. The windows differ: a daily report covers a single day (ending at the settlement cutoff above), while the monthly report covers the full calendar month — 00:00 UTC on the 1st through 00:00 UTC on the 1st of the next month — to align with your invoice period. Reports are not deduplicated by transaction, so the same transaction can appear more than once. Across daily files it shows up on its posting day (unsettled, ledgerSettlementAmount of 0) and again on its settlement day, because transactionDate moves to the settlement date once it settles. Within a single report it can also span more than one row when a settlement straddles a period boundary. Because the daily and monthly windows use different cutoffs, the monthly report is not the sum of that month’s daily reports. Reconcile against the monthly report using the aggregations below — SUM(...) and COUNT(DISTINCT transactionId) both handle repeated rows correctly.

Reconciling Your Invoice

Run these queries against the monthly report (a single full-month window). Reports are not deduplicated by transaction, so always use COUNT(DISTINCT transactionId) for counts and SUM(...) for volume — both handle transactions that appear in more than one row.

Your invoice is derived from the same settlement data as this report, so every figure on it can be reproduced from the report rows. Reconciliation splits into two grains — volume and counts — and each uses a different tenant column and a different date column. Your report contains every row where either tenantId or billingTenantId matches your tenant, so filter to the column that applies to each grain. The examples below assume the report (CSV or JSON) is loaded into a table named report.

Volume figures

Filter rows to billingTenantId = <your tenant id> and transactionDate within the invoice period, then sum:

Invoice figure	Report calculation
`totalTransactionVolume`	`SUM(ledgerSettlementAmount)`
`totalInterchange`	`SUM(interchangeAmount)`

SELECT SUM(CAST(ledgerSettlementAmount AS INT64)) AS totalTransactionVolume,
       SUM(CAST(interchangeAmount      AS INT64)) AS totalInterchange
FROM report
WHERE billingTenantId = '<TENANT>'
  AND transactionDate >= '2026-05-01' AND transactionDate < '2026-06-01';

Amounts are strings in minor units, so cast before summing. interchangeAmount is additionally scaled by 10^6 (divide by 1,000,000 for the dollar value), so totalInterchange carries that same scale.

Transaction counts

Filter rows to tenantId = <your tenant id> and postedAt within the invoice period, then count distinct transactions:

Invoice figure	Counts rows where
`totalTransactions`	`transactionType = 'spend'`
`threeDS`	`isThreeDSecureTransaction` is `true`
`international`	`isInternationalTransaction` is `true`
`applePay`	`walletName = 'ApplePay'`
`googlePay`	`walletName = 'GooglePay'`

SELECT COUNT(DISTINCT IF(transactionType = 'spend', transactionId, NULL))   AS totalTransactions,
       COUNT(DISTINCT IF(isThreeDSecureTransaction, transactionId, NULL))   AS threeDS,
       COUNT(DISTINCT IF(isInternationalTransaction, transactionId, NULL))  AS international,
       COUNT(DISTINCT IF(walletName = 'ApplePay', transactionId, NULL))     AS applePay,
       COUNT(DISTINCT IF(walletName = 'GooglePay', transactionId, NULL))    AS googlePay
FROM report
WHERE tenantId = '<TENANT>'
  AND postedAt >= '2026-05-01' AND postedAt < '2026-06-01';

Boolean columns are encoded as the strings true/false in the CSV; compare to 'true' (a quoted string literal) if your warehouse loads them as text rather than booleans.

Why volume and counts use different columns

Volume is attributed to the tenant your settlement is billed to (billingTenantId) on the settlement-grain date (transactionDate), matching how the invoice rolls up charges. Counts use the raw tenant stamp (tenantId) on the posting date (postedAt), matching how the invoice tallies activity. Using the wrong column pair for a grain will not tie out. A row can have tenantId set but billingTenantId empty — “settled, but not billed.” These rows count toward transaction totals but not toward billed volume.

Introduction

Plan & Set Up Your Program

Build Your Program

Run Your Program

Rewards

Embedded Wallets

Transaction Reports

When Reports Are Available

What the Report Includes

Field Descriptions

Daily vs. Monthly Reports

Reconciling Your Invoice

Volume figures

Transaction counts

Why volume and counts use different columns

​When Reports Are Available

​What the Report Includes

​Field Descriptions

​Daily vs. Monthly Reports

​Reconciling Your Invoice

​Volume figures

​Transaction counts

​Why volume and counts use different columns

When Reports Are Available

What the Report Includes

Field Descriptions

Daily vs. Monthly Reports

Reconciling Your Invoice

Volume figures

Transaction counts

Why volume and counts use different columns