No. PayPal Payments appends meta to the standard WooCommerce order tables — no separate plugin tables. Every _ppcp_-prefixed key (order ID, funding source, payer email, seller protection flag) lives in wc_orders_meta. SleekView reads those keys as columns, which is the cleanest path because there is no extra schema to track. Modern WooCommerce HPOS storage is fully supported.

It is treated as personal data. SleekView lets you mask the column or restrict it by capability, so support staff who do not need email visibility do not see it in the grid or in CSV exports. Per-role row scoping pairs with column-level masking — for example, marketing might see counts but not addresses, while finance sees both. The default configuration leans conservative and masks PII unless explicitly granted.

Refunds still go through the PayPal Payments plugin because they need to update PayPal-side state, not just local meta. SleekView shows refund state inline next to the order row so finance can see which orders are refunded, partially refunded or pending without leaving the grid. The refund action itself runs through PPCP's existing order action, which keeps PayPal and WooCommerce consistent.

Yes. The grid reads from the High-Performance Order Storage tables that PayPal Payments writes to in modern WooCommerce. Sites still on legacy CPT order storage are also supported — SleekView checks which layer is active and reads accordingly. Migrating from CPT to HPOS happens transparently from SleekView's perspective; saved views and column promotions carry over.

Yes. Subscription renewals from PayPal flow through the same _ppcp_-prefixed meta keys, which means renewal orders show up in the grid alongside one-off purchases. Filtering to renewals only, or to a specific subscription's renewal history, becomes a saved view. Reference Transactions and Vault tokens used for subscription renewals also surface as filterable columns when present.

Yes. Filter to PayPal-funded rows and export the slice as CSV with the columns finance needs. A common pattern is monthly Pay Later exports for risk review, weekly seller-protection-ineligible exports for the support queue, and daily PayPal payout reconciliation exports for finance. Exports honor column-level masking so PII fields stay hidden where they should.

Seller protection eligibility, dispute state and refund state all appear as their own columns. Stores can build a saved view of seller-protection-ineligible orders that have shipped within the last 30 days, which is the cohort most likely to produce buyer-protection chargebacks. Pre-flagging that cohort gives the support team a window to gather shipping evidence before any dispute is filed.

Yes. The funding_source meta key carries canonical values (paypal, card, paylater, venmo, paylater_short_term for Pay in 4 in supported markets). Each value becomes its own filter target, so Pay in 4 analyses do not get lumped in with longer-term Pay Later financing. The split matters because Pay in 4 has different conversion economics and a different risk profile than 6/12/24-month installments.