No. WooPayments still processes payments, settles payouts and handles dispute responses through its API. SleekView reads the data WooPayments has already written into your database and presents it as a workable table UI. Disabling SleekView changes nothing about how payments flow — it just removes the alternative admin view. The gateway integration, webhooks and Stripe-side state are completely untouched.

You can edit allowed merchant fields like internal notes, custom tags and any meta keys you have explicitly marked editable. Refunds themselves still flow through the WooPayments API because they need to update Stripe-side state, not just the local database. The grid surfaces the refund state inline so finance can see what is pending without leaving the row, but the actual capture goes through the gateway.

SleekView reads live from the WordPress database on every load. The rows match exactly what WooPayments wrote on its last webhook sync, with no caching layer in between. If WooPayments processed a webhook five seconds ago, the grid reflects it on the next load. 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 admin has.

No. SleekView only queries when an admin opens a view in the back office. Storefront pages, checkout flows and customer-facing API calls never trigger SleekView queries. The grid uses indexed columns and pagination, so even on stores with hundreds of thousands of transactions the response stays fast. Heavy compound filters can take longer; saving them as views with appropriate indexes keeps everything under a second.

Yes, with per-site or network-wide views depending on how you scope the query. Single-store networks usually want per-site grids so each store's finance team sees only their own transactions. Multi-store finance functions can configure a network-wide view that aggregates across stores using the same payment processor, which is helpful when one team reconciles for several sites.

Yes. Saved views can be private to one user or shared across capabilities you define. A common pattern is shared views for the recurring finance tasks ("Yesterday's payout reconciliation", "Open disputes") and private views for individual analysts working on one-off questions. Sharing respects the same per-role row scoping so a shared view does not bypass anyone's read permissions.

Yes. Refund state surfaces as its own column with filterable values (pending, succeeded, failed). Chargeback workflow state appears alongside dispute reason and response deadline. The chargeback evidence itself still lives in WooPayments — SleekView just gives you a sortable queue of which disputes need attention, when they are due and what category they fall into so the response team works the right ones first.

WooPayments writes processing fees per transaction, and SleekView promotes that fee field to a sortable column with currency formatting. Group by country, card brand or fee bracket to spot where fees concentrate. Stores running internationally find this useful for deciding when a regional acquirer or local payment method would lower their effective fee rate compared to the WooPayments default.