Skip to main content
The Dispute Risk Index shows the current month’s dispute rate for Subotiz Payments only. It is calculated as: current month dispute orders ÷ current month successful orders × 100%.The index uses three levels:
  • Normal — green, ≤ 0.8%
  • Monitor — yellow, between 0.8% and 1.0%
  • Risk — red, ≥ 1.0%
Importantly, this index does not update when you change the time range or payment provider filter on the dashboard — it always reflects Subotiz Payments data for the current calendar month only.
The Dispute Risk Index handles zero-order scenarios as follows:
  • If there are no successful orders and no disputes in the current month, the index displays Normal (green).
  • If there are no successful orders but disputes are present, the index displays Risk (red).
This means a single dispute with zero successful orders will immediately trigger a Risk status regardless of volume.
The disputed amount shown on the Dispute Overview dashboard is the total transaction amount related to disputes during the selected period. All amounts are uniformly converted into USD for accumulation purposes and are displayed in USD only. This figure is provided for statistical reference and does not reflect settlement currency or localized amounts. There is no option to switch the display currency on this dashboard.
A sudden spike in dispute rate typically indicates recent order anomalies. To interpret it accurately, consider three factors:
  1. Duration — a single-period spike is more likely an isolated incident, while a sustained upward trend usually signals a systemic issue requiring broader investigation.
  2. Volume vs. amount — if dispute count increases but the disputed amount stays low, this typically involves small-value disputes. If the amount rises significantly alongside volume, high-value order risk may be involved.
  3. Reason distribution — check the Dispute Reason distribution chart to identify whether a specific dispute type is driving the spike.
Use the payment provider filter to isolate whether the spike is concentrated in one channel.
The two donut charts on the Dispute Overview dashboard serve different analytical purposes:
  • Dispute Reason distribution chart (lower left) — shows why disputes occurred, breaking down all disputes by reason category such as unauthorized transaction, product not received, or product not as described. Use this to identify high-frequency problem areas and target process improvements.
  • Dispute Status distribution chart (lower right) — shows where disputes currently stand in the resolution process, such as Lost, Won, or Under review. Use this to assess overall case outcomes and identify backlogs.
A high proportion of Under review cases indicates unresolved disputes that need follow-up.
When a single payment provider shows a noticeably higher dispute rate, the recommended approach is:
  1. Use the payment provider filter on the Dispute Overview dashboard to isolate that provider’s data and review the trend over time.
  2. Check the Dispute Reason distribution for that provider to identify whether a specific reason type is concentrated there.
  3. Review the transaction quality and fraud control settings for that provider.
  4. If the dispute rate reaches Monitor or Risk level, prioritize investigating current-month disputes and consider adjusting the provider’s configuration or operational strategy.
No. The Dispute Overview dashboard is designed for aggregated trend and distribution analysis only. It shows dispute rate, total dispute count, total disputed amount, trend over time, reason distribution, and status distribution — all at a summary level. It does not show individual dispute case details, customer information, or specific transaction records. To view or manage individual dispute cases, go to the dispute orders section in the Subotiz admin.
These two metrics measure different stages of the payment journey:
  • Checkout customers — counts the number of unique customers who reached the checkout page during the selected period; each customer is counted once regardless of how many times they enter checkout.
  • Paid customers — counts the number of unique customers who successfully completed at least one payment during the same period; again, each customer is counted only once even if they made multiple successful transactions.
The gap between these two numbers reflects customers who started checkout but did not complete payment.
Revenue in Transaction Overview represents the total amount of successfully paid orders during the selected period, calculated based on the payment success timestamp. It reflects only completed payments and does not deduct refunds. Refunds are tracked as a separate metric — the Refunds field shows the total amount successfully refunded during the same period, based on the time refunds were processed. To understand net revenue, subtract the Refunds figure from Revenue manually. In charts, revenue displays as currency symbol and amount; in tables it shows as currency code, symbol, and amount (for example, USD $1,000.00).
The Checkout Conversion Funnel tracks how customers progress through four stages of the payment journey: Initiate Checkout, Submit Payment, Complete Payment, and Payment Success. Each customer is counted once within the selected time range to ensure accurate behavior tracking.Four conversion rate metrics are available:
  • Checkout Conversion Rate — Payment Success ÷ Initiate Checkout
  • Payment Submitted Rate — Submit Payment ÷ Initiate Checkout
  • Payment Completed Rate — Complete Payment ÷ Submit Payment
  • Payment Success Rate — Payment Success ÷ Complete Payment
Funnel data updates every 15 minutes based on the store’s timezone. To see the latest results, refresh the page manually.
If the same transaction fails multiple times during subscription renewal retries, only the final failed reason is displayed in the Payment Failure Reasons section. This means the failure count and percentage reflect the last recorded failure reason per transaction, not every individual retry attempt. This approach prevents retry attempts from inflating failure counts and ensures the data reflects the ultimate outcome of each failed transaction.
These two perspectives control how subscription metrics are counted:
  • Customer View — calculates metrics per unique customer; each customer is counted once regardless of how many subscriptions they hold. This is useful for understanding overall user scale, customer structure, and average revenue per customer.
  • Subscription View — calculates metrics per subscription contract; customers with multiple subscriptions are counted multiple times. This view is better suited for analyzing plan adoption, contract volume, and multi-subscription behavior.
The same customer holding three subscriptions would count as 1 in Customer View and 3 in Subscription View.
MRR (Monthly Recurring Revenue) in Subscription Overview represents the normalized monthly recurring revenue from all active subscriptions at the current point in time. It is calculated based on each subscription’s current billing cycle price, converted to a monthly equivalent value — regardless of whether the plan bills monthly, quarterly, or annually. For example, an annual plan priced at $120/year contributes $10 MRR. MRR reflects the current snapshot of active subscription revenue and is not a future projection or forecast. It updates based on the active subscription set at the time of viewing.
The All time option in Subscription Overview displays data for all subscriptions created since subscriptions were first enabled on the store — it is not filtered by date. This is best suited for long-term trend analysis and overall business health review. A custom time range limits the analysis to subscriptions created within a specific period and is used for short-term evaluation, such as measuring the impact of a campaign or pricing change. When a custom range is selected, only subscriptions created within that period are included, but their renewal and lifecycle activity continues to be tracked through the current date.
These two metrics measure authorization performance from different angles:
  • Payment Success Rate — calculated as successful orders ÷ total trade orders, including all failure types; it shows the overall end-to-end payment conversion.
  • Net Payment Success Rate — excludes customer-related failures from the denominator: successful orders ÷ (total trade orders − customer-related failed orders). This isolates provider-side or system-level authorization issues by removing failures caused by customer behavior such as insufficient funds or card declines.
Use Net Payment Success Rate to evaluate provider channel stability; use Payment Success Rate to assess overall checkout conversion.
Yes, this is the intended behavior. The payment method summary cards at the top of the page display total transaction amount and percentage share of total transactions for each payment method. These cards are fixed and only update when the selected time range is changed. They are not affected by switching the payment provider, changing the metric tab (such as Net Payment Success Rate or Trade Orders), or adjusting payment method checkboxes. The chart section below the cards updates dynamically based on provider, metric, and payment method selections.
The Payment Provider Misattribution Share report includes a toggle to include or exclude customer-related failures. When customer-related failures are included, the chart shows all failure reasons across the total failure pool. When they are excluded, the chart isolates failures caused by provider-side or system-level issues — removing declines driven by customer behavior such as insufficient funds, expired cards, or card rejections. To identify provider-caused issues: set the toggle to Exclude customer-related failures and filter by a specific payment provider. High-share failure reasons in this view indicate provider or system-level authorization problems that warrant follow-up with the payment provider.
When comparison is enabled, the percentage change for each metric is calculated as: (Current period value minus comparison period value) divided by comparison period value, multiplied by 100. The result is displayed to two decimal places. An increase is shown in green text with an upward arrow, a decrease in red text with a downward arrow, and no change in gray with a flat indicator.Three comparison options are available:
  • Yesterday
  • the same period in the previous cycle (such as last week versus the week before)
  • the same period last year
In Transaction Overview, the customer country or region is determined by their IP address at the moment checkout is initiated. This reflects where the customer was when they started the checkout process, not their billing address or shipping destination. The Order Source by Country/Region chart displays up to the top 8 countries by order volume, with any additional countries grouped into an Other category.
Data update frequency depends on the selected date range. For Today, transaction metrics update at a minute-level cadence throughout the day. For all other date ranges such as Yesterday, Last 7 Days, or Last 30 Days, data reflects completed aggregation cycles and updates on a scheduled basis rather than continuously. For all ranges, refresh the page manually to view the most recent data as there is no automatic page refresh.
Both metrics measure subscription cancellation but at different lifecycle points:
  • Total churn rate — calculated as canceled subscriptions divided by total subscriptions; it covers all cancellations regardless of when they occurred.
  • Pre-renewal churn rate — specifically measures subscriptions that were canceled before a renewal invoice was even generated, divided by total subscriptions. This helps identify customers who dropped off during the initial period or trial before any renewal attempt was made, which is a distinct signal from post-renewal cancellations.
LTV (Lifetime Value) in Subscription Overview represents the average total revenue generated per subscription over its lifecycle, including the initial payment and all successful renewals. For subscriptions that have ended, LTV covers the full period from creation to cancellation or expiration. For subscriptions that are still active, LTV is calculated up to the current observation date — meaning it reflects revenue generated so far, not a projected final value. LTV will continue to increase as active subscriptions renew successfully.
The Subscription Renewal and Churn chart breaks down renewal performance by renewal cycle for subscriptions created within the selected time range. It shows three data series:
  • the number of subscriptions entering each renewal cycle
  • the number of successful renewals in that cycle
  • the renewal success rate as a line chart
Use 12 cycles for monthly subscription products or shorter billing models where most lifecycle activity occurs within the first year. Use 24 cycles for long-term subscription offerings or products with extended retention periods where behavior patterns take longer to emerge.
ARPU (Average Revenue Per User) in Subscription Overview is calculated as: (Total subscription revenue minus total subscription refunds) divided by the number of unique subscribed customers. Unlike the Revenue metric which does not deduct refunds, ARPU uses net revenue after refunds are subtracted. Customer count is based on unique customers deduplicated by customer ID within the selected time range. This makes ARPU a net revenue per customer figure rather than a gross one.
The payment provider and payment method lists in the Reports module are dynamically generated based on two conditions:
  • the merchant’s configured and active payment providers or methods
  • whether there is transaction data for that provider or method within the selected time range
If a provider or payment method has no transaction data in the selected period, it will not appear in the dropdown. To find a missing provider, try expanding the time range to a period when that provider was actively processing transactions.
Trial conversion rate in Subscription Overview measures the percentage of subscriptions that entered a trial period during the selected time range and successfully converted to a paid plan after the trial ended. It is calculated as: subscriptions that successfully converted to paid after trial divided by total subscriptions that entered a trial during the selected period. A successful conversion means the subscription transitioned from the trial period into a paid billing cycle — the customer was charged at the standard subscription price for the first full billing cycle after the trial. Subscriptions where the customer canceled during the trial or did not complete payment after the trial ends are not counted as conversions.
Average lifecycle duration in Subscription Overview measures the average actual service duration from the effective date to expiration across all subscriptions created within the selected time range. This includes both the trial period and the paid billing period. For subscriptions that were canceled early before the natural expiration, the duration is calculated up to the service expiration date rather than the cancellation request date — meaning the remaining service period after cancellation is still included. This reflects the actual time a customer had access to the service rather than just the billing activity.
When multiple products are selected in the Product filter in Transaction Overview, the system aggregates metrics across all selected products. This means customer counts, order counts, revenue, and conversion trend data are combined and calculated as a single unified result for the selected product set — not shown separately per product. All other filters such as date range, payment method, country, and transaction type continue to apply together with the product filter. If you want to compare individual product performance, apply the product filter one product at a time.
The X-axis granularity in the Transaction Overview chart changes automatically based on the selected date range:
  • For date ranges of 3 days or fewer — the chart displays data at an hourly level; same-day data uses HH:mm format, while cross-day data uses MM-DD HH:mm.
  • For date ranges longer than 3 days within the same year — the chart switches to daily granularity using MM-DD format.
  • For date ranges that span across years — the format changes to YYYY-MM-DD.
This automatic adjustment ensures the chart remains readable regardless of the time range selected.