Payment Summary Report
The Payment Summary Report aggregates transaction outcomes across your business and splits them into two payment buckets — first-charge (FC) and recurring — alongside refund, chargeback, gross and net revenue metrics.
Use it to monitor approval rates, track refunds and chargebacks, and compare gateway, product, or campaign performance.
Open the report
In the Odus Dashboard, navigate to Insights → Payments. The page shows a summary chart of revenue, refunds, and chargebacks, with a detailed breakdown table below.
Date range and timezone
The date range selector filters payments by their createdAt timestamp. Switch between UTC and your merchant timezone to align daily boundaries with your business hours. The merchant timezone is configured in Settings → Merchant Configuration; if unset, the report falls back to UTC.
Unlike the Customer Value Report, every payment is evaluated independently — there is no cohort anchoring. A payment is included whenever its creation time falls inside the window.
Grouping
Use the Group by tabs to organize rows by product, currency, calendar day, gateway profile, UTM source, or UTM campaign. Switching grouping updates the chart and table immediately.
Filtering
Open the Filters panel from the top-right of the report to narrow it to a segment of your book. Filters apply to the chart, the table and the CSV export alike, and they are written into the page URL — so a filtered view can be bookmarked, reloaded, or shared with a colleague. The filters you apply are also remembered per report in this browser, so returning to it later reopens the slice you left it on — unless you arrive on a link that already carries filters, which always win. Clear all forgets them. Nothing is refetched until you press Apply.
Filtering never changes how a payment's revenue is attributed. A row that survives a filter carries exactly the number it carried before — filtering selects rows, it does not recalculate them.
When you filter by product or price and group by product, only the filtered product's row is shown. A payment whose cart also held other products still counts in full towards that row, but its cart-mates do not appear as rows of their own.
| Filter | Notes |
|---|---|
| Product, Price | Selects payments whose cart contains a line item for that product or price. A cart with several line items still counts once, at its full amount. Excluding a product (nin) removes every payment carrying it, even alongside others. |
| Payment type | initial or recurring. Prefer this over offSessionType, which is unset on an initial charge and therefore skips them all under a "not recurring" filter. |
| Gateway profile | The profile the payment was actually processed on, read from its latest transaction — which a cascade may have changed. The requested profile (paymentMethodOptions.card.gatewayProfile) is filterable on the API but not offered in the panel. |
| Currency, Status, Amount | Payment-level fields. |
| Card brand, BIN, Last four, Expiry | Read from the payment method. |
| Billing country | The country on the customer's billing address, chosen by name from the country list. Pick several to report on a whole market. Note this is the address they gave you, not the country that issued the card. |
| Shipping country | The customer's shipping-address country — where the order goes. Chosen the same way. A customer with no shipping address on file has no country to match, so those payments drop out of the report whenever this filter is set. |
| UTM source / medium / campaign / term / content / id | Attribution captured at checkout. |
Filterable on the API but not offered in the panel: Cascade, Payment method type, Card mode, Card expiry, the requested gateway profile (paymentMethodOptions.card.gatewayProfile, as opposed to the used one above), Decline type (soft_decline / hard_decline) and Retry attempts. Every parameter the route publishes is listed in the API reference.
What counts as a payment
The report excludes payments with display status unattempted or cancelled. Every other status — succeeded, reversed, partially_reversed, uncaptured, chargeback, failed, and incomplete — is eligible to appear in at least one metric below.
Each payment is classified as either first-charge (FC) or recurring based on its offSessionType:
- Recurring — payments generated by the subscription billing engine to renew an active subscription (
offSessionType = recurring). - First-charge (FC) — every other payment. This includes on-session checkout payments and unscheduled merchant-initiated charges. The "FC" label is a bucket name for "non-recurring" — it does not mean the customer's first-ever payment.
"FC" in this report has a different meaning than in the Customer Value Report. There, FC strictly means a customer's lifetime first charge. Here, it is shorthand for any non-subscription-renewal payment, regardless of whether the customer has paid before.
Both buckets are reported side-by-side so you can compare new payment activity against subscription renewal performance.
Metrics
First-charge metrics
| Metric | Definition |
|---|---|
| FC Payments Count | All non-recurring payment attempts. |
| FC Successful Count | FC payments with status succeeded, reversed, partially_reversed, uncaptured, or chargeback. |
| FC Successful Items | Total line items across all successful FC payments (a multi-item cart contributes one row per line item). |
| FC Incomplete Count | FC payments that started but never completed (status incomplete). |
| FC Failed Count | FC payments that were declined (status failed). |
| FC Revenue | Gross revenue from successful FC payments. |
| FC Approval Rate | FC Approved / (FC Approved + FC Failed) × 100, where approved excludes chargebacks. |
Recurring metrics
| Metric | Definition |
|---|---|
| Recurring Payments Count | All recurring (subscription) payment attempts. |
| Recurring Successful Count | Recurring payments with status succeeded, reversed, partially_reversed, uncaptured, or chargeback. |
| Recurring Successful Items | Total line items across all successful recurring payments. |
| Recurring Declined Count | Recurring payments declined by the gateway (status failed). |
| Recurring Revenue | Gross revenue from successful recurring payments. |
| Recurring Approval Rate | Recurring Successful / (All Recurring with a terminal outcome) × 100; chargebacks are included in both values. |
Refunds, chargebacks, and totals
| Metric | Definition |
|---|---|
| Refunded Payments Count | Payments with status reversed or partially_reversed. |
| Refund Amount | Total refunded amount (full and partial). |
| Refund Percentage | Refund Amount / Gross Successful Revenue × 100. |
| Chargebacks Count | Payments with status chargeback. |
| Chargeback Amount | Total amount of chargebacked payments. |
| Chargeback Percentage | Chargeback Amount / Gross Successful Revenue × 100. |
| Total Gross Revenue | All successful revenue across FC and recurring, before deductions. |
| Total Net Revenue | Total Gross Revenue − Refund Amount − Chargeback Amount. |
The Total row aggregates each metric across all groups.
All monetary metrics are converted to your display currency (set in Settings → Merchant Configuration) using the exchange rate effective at the time of each payment, so historical totals remain stable.
Multi-item carts
When grouped by Product, a payment whose cart contains multiple line items is split across rows proportionally to each line item's share of the payment amount. Counts use a distinct-payment formula so a multi-item cart still counts as one payment. Other groupings assign each payment to exactly one row.
Example
Say your store processed the following six payments on 2026-06-01, all in your display currency:
| Payment | Type | Amount | Outcome |
|---|---|---|---|
| #1 | Checkout | $50 | Succeeded |
| #2 | Checkout | $50 | Failed (declined) |
| #3 | Checkout | $80 | Succeeded |
| #4 | Checkout | $80 | Refunded ($80) |
| #5 | Rebill | $30 | Succeeded |
| #6 | Rebill | $30 | Failed (declined) |
Grouped by Day, the report row for 2026-06-01 looks like this:
| FC Count | FC Successful | FC Failed | FC Revenue | FC Approval | Recurring Count | Recurring Successful | Recurring Revenue | Recurring Approval | Refund Amount | Total Gross | Total Net |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 4 | 3 | 1 | $210 | 75% | 2 | 1 | $30 | 50% | $80 | $240 | $160 |
How each number is derived:
- FC Count = 4 — payments #1–#4 are all non-recurring (checkout).
- FC Successful = 3 — #1, #3, #4 (a refunded payment was originally successful).
- FC Revenue = $210 — gross of the three successful FC payments ($50 + $80 + $80), before subtracting refunds.
- FC Approval = 75% —
3 approved / (3 approved + 1 failed) × 100. - Recurring Successful = 1 and Approval = 50% — one of the two rebills (#5, #6) succeeded.
- Refund Amount = $80 — payment #4 was fully refunded.
- Total Gross = $240 —
$210 FC + $30 recurring. - Total Net = $160 —
$240 − $80 refund − $0 chargebacks.
Export to CSV
Click Export CSV in the top-right of the table to download the current view. The file contains one row per group plus a Total row, with monetary values in your display currency. The selected date range is included in the filename.
API access
The same data is available via GET /reports/payment-summary. The endpoint supports all grouping options, metric selection via measures, and every filter listed above — each published as a query parameter in the API reference, with the operators (eq, ne, in, nin, gt, gte, lt, lte, like) its type accepts.
The API additionally accepts a secondaryGroupBy parameter to split each group along a second dimension (e.g. groupBy=displayStatus&secondaryGroupBy=currency). When supplied, each response row carries a secondaryGroupBy field with the value of that second dimension.
Example
GET /reports/payment-summary?groupBy=product.name&createdAt[gte]=2026-01-01T00:00:00Z&createdAt[lte]=2026-01-31T23:59:59Z&displayStatus[nin]=unattempted,cancelled
Narrowed to one product, paid in EUR, acquired from a single campaign:
GET /reports/payment-summary?groupBy=createdAt&granularity=day&createdAt[gte]=2026-01-01T00:00:00Z&createdAt[lte]=2026-01-31T23:59:59Z&product[eq]=prod_2ABc¤cy[eq]=eur&attribution.utmSource[eq]=fb
The response contains a data array (one entry per group) and a total object with the aggregate across all groups.