Yes. The PayPal Express action writes its result to postmeta on each nf_sub entry, using keys like _payment_total, _payment_status, _transaction_id, and _payer_email. SleekView discovers those keys and exposes them as group-by and aggregation options without per-action setup.

Numeric aggregation treats _payment_total as a number regardless of currency, so a naive sum mixes EUR, USD, and GBP into one figure. Group or filter by the currency meta to keep per-currency sums separate, which is the usual finance reconciliation pattern.

Aggregations run as SELECT ... GROUP BY against indexed columns on nf3_submissions and the related postmeta. Card render time scales with the cardinality of the group-by, not raw row count, so hundreds of thousands of entries stay responsive when grouping by _form_id or _payment_status.

Yes. _payment_status tracks completed, pending, failed, refunded, and reversed states. Build a Pie or a Bar grouped by status to see the mix, or filter to pending and put a Number card on the count so the team chases the right entries.

Cards re-query on view load and on filter change. Set a refresh interval per view if a finance dashboard needs near-live counts. Idle dashboards don't poll, so a closed view doesn't add database load.

Yes. Save views and scope them per WordPress role or capability. Finance sees a payment_total dashboard, form admins see entry volume per form, and editors see only the forms relevant to their team. Each user keeps their personal filters.

SleekView only counts entries that actually have the PayPal meta keys, so older submissions without the gateway data don't pollute the totals. Filter to the start date when PayPal Express went live to keep the comparison clean.

Each card exports its aggregated rows as CSV with the group-by labels and the aggregate values. Useful for sending finance the raw payment_status counts behind a Pie or archiving the campaign-end snapshot of a donation form.