No. WooPayments still processes payments, handles disputes through its API and writes the gateway tables. SleekView Charts only reads them. Disable the dashboard and WooPayments keeps running unchanged.

WooPayments ships fixed reports. SleekView Charts is configurable: any column becomes a group-by axis, any field becomes a value column, and dashboards save per role. Use both side by side, the WooPayments overview for canonical metrics and the SleekView dashboard for the questions WooPayments did not anticipate.

The reconciliation editing itself happens in the SleekView grid where notes and tags are inline-editable. The dashboard surfaces the payout-by-day cards that frame the reconciliation. Clicking any card opens the matching filtered grid.

Each card reads live from the WordPress database on dashboard open. There is no separate sync layer. The only freshness lag is whatever delay exists between Stripe's event and WooPayments writing to the database, which is the same lag the native overview has.

Yes. Dashboards configure per site or, with the right setup, network-wide. Multi-store finance functions can aggregate across sites using the same processor, useful when one team reconciles for several stores.

Yes. Card layouts save per user and can be shared by capability. A common pattern is a shared finance reconciliation dashboard and a separate shared risk dispute dashboard, scoped to the right capabilities.

No. Charts only render when an admin opens the dashboard. Checkout flows, customer pages and gateway webhooks never trigger chart queries. Aggregations cache briefly so reopening the dashboard stays fast even on stores with hundreds of thousands of transactions.

Yes. Connected account ID becomes a first-class group-by axis. Marketplace setups can chart per-subaccount settled revenue and platform fees on the same dashboard, useful for marketplace finance reconciling across subaccounts.