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. The pickers offer your whole catalogue, newest first — deactivated entries included and labelled (inactive), since historical payments still reference them; when several entries share a name, each also shows its creation date. |
| 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, Last four, Expiry | Read from the payment method. |
| BIN | Read from the payment method. Choose is to match one BIN exactly, or is between to select a range: each bound stands for every card number that starts with it, so 4688 to 4688 selects every BIN beginning with 4688. A payment whose BIN has fewer digits than your bounds is left out when it could fall on both sides of a bound — see Filtering by a range of card BINs. |
| 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 or not_attempted) and Retry attempts. Every parameter the route publishes is listed in the API reference.
What counts as a payment
A payment enters the counts once it can be classified: it was approved, it failed, or — for a first-charge payment — it is incomplete, meaning the customer is still with their bank or wallet approving it. Every counted payment falls into exactly one outcome column, so:
- FC Payments Count = FC Successful + FC Incomplete + FC Failed
- Recurring Payments Count = Recurring Successful + Recurring Declined
A renewal is charged without the customer present, so the recurring bucket has no incomplete column, and a renewal counts as declined whenever its latest attempt came back with a declineType — whatever that type says. That covers a refusal, an outcome the processor never resolved, and a payment that was never authorized against the payment method at all. A renewal attempt that failed without producing a declineType is not classified and is counted nowhere; the same first-charge attempt counts as failed.
Two more kinds of payment cannot be classified and are counted nowhere: a checkout that was opened but never submitted (display status unattempted), and a payment cancelled without ever being declined — withdrawn by you, or blocked by one of your customer restrictions before it reached the gateway. The second kind is left out of the report entirely, so it cannot produce a row of its own either. A payment that was declined and cancelled afterwards is still a decline, and is counted as one.
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 | Non-recurring payments classified as approved, failed or incomplete: the sum of FC Successful, FC Incomplete and FC Failed. |
| 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 still awaiting the customer, who was sent to their bank or wallet to approve the payment and has not yet returned (displayStatus incomplete). |
| FC Failed Count | FC payments whose latest attempt came back with a declineType, whatever it says (one you cancelled afterwards still counts), plus those that ended in a failed state without one — sent to a redirect the customer did not complete within a day, or ended before the gateway answered. Most carry displayStatus failed. |
| FC Revenue | Gross revenue from successful FC payments. |
| FC Approval Rate | FC Approved / (FC Approved + FC Failed) × 100, where approved excludes chargebacks. Incomplete payments are on neither side until they resolve. |
Recurring metrics
| Metric | Definition |
|---|---|
| Recurring Payments Count | Recurring payments classified as approved or declined: the sum of Recurring Successful and Recurring Declined. |
| 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 whose latest attempt came back with a declineType, whatever it says. Counted whether a retry is scheduled, or the payment was cancelled because the failure was final or its retries ran out. A payment recovered by a later retry moves to Recurring Successful. |
| Recurring Revenue | Gross revenue from successful recurring payments. |
| Recurring Approval Rate | Recurring Successful / (Recurring Successful + Recurring Declined) × 100; chargebacks are included in both values. |
A renewal that is being retried counts as declined until a retry is approved, so the Recurring Approval Rate for a recent period rises as retries land.
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 | Declined |
| #3 | Checkout | $80 | Succeeded |
| #4 | Checkout | $80 | Refunded ($80) |
| #5 | Rebill | $30 | Succeeded |
| #6 | Rebill | $30 | Declined, retry scheduled |
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. #6 counts as declined while its retry is pending; if the retry is approved, it moves to Recurring Successful and the rate becomes 100%.
- 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 /v2/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, ilike) its type accepts. String filters are case-sensitive except ilike. paymentMethod.card.bin also takes a range with gte and lte, compared as the card numbers each BIN starts rather than as text — see Filtering by a range of card BINs.
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 /v2/reports/payment-summary?groupBy=product.name&createdAt[gte]=2026-01-01T00:00:00Z&createdAt[lte]=2026-01-31T23:59:59Z&displayStatus[ne]=unattempted
displayStatus[ne]=unattempted is optional: an unsubmitted checkout is already left out of every metric (see What counts as a payment), so the filter changes no number. It does keep a group whose only payments were never submitted — a product with no other activity in the window — out of the response, where it would otherwise appear with every metric at zero. Do not exclude cancelled: a rebill that was declined and then cancelled once its retries ran out is a decline, and filtering it out removes it from Recurring Declined and inflates the approval rate.
Narrowed to one product, paid in EUR, acquired from a single campaign:
GET /v2/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.