Anything that stores transaction state in postmeta on the nf_sub post. That includes Ninja Forms' first-party PayPal Express add-on and the PayPal Checkout add-on, plus several third-party PayPal connectors that follow the same convention. The column picker lists whatever meta keys are actually present, so the right ones surface automatically.

No. Refunds, captures, and dispute responses are PayPal-side actions and stay there. SleekView is the WordPress-side reporting and annotation layer. The transaction ID column is the bridge: copy from the table, paste into PayPal, complete the refund there, and the next IPN updates _paypal_status back to refunded.

SleekView reads what's in postmeta at query time. If your add-on hasn't received the IPN or webhook yet, the row stays pending in SleekView too. Refreshing the view picks up the latest state. This is identical to how the default admin would reflect the data, just exposed in a more useful list format.

Yes. _paypal_amount is stored as a numeric meta and SleekView's numeric filter UI supports greater-than, less-than, and ranges. Useful for finding all donations over a threshold, or for auditing the long tail of small failed payments that often hide gateway-config bugs.

If your add-on writes the subscription ID and renewal status to postmeta on the original submission (e.g. _paypal_subscr_id, _paypal_subscr_status), SleekView surfaces them as columns. Renewals that come through as new submissions are visible as new rows; group them on payer email or subscription ID to see the customer lifetime view.

PayPal records currency on the transaction. If the add-on stores it as _paypal_currency, SleekView surfaces it as a column. For multi-currency sites, finance views typically group by currency first, then sum amounts within each group, avoiding the mix-currency mistakes that single-amount columns can cause.

Test-mode transactions still create nf_sub rows. The default behaviour is to show them in the same view. If you want to exclude them, filter by a meta key the add-on writes for test mode (commonly _paypal_test) or filter by date to the production cutover window onwards.

SleekView shows whatever the add-on already stored in WP's database; it doesn't reach out to PayPal for additional personal data. For GDPR, the data subject can be located via SleekView's email filter and their nf_sub rows handed to the standard WP personal-data export and erase tools, which will include the postmeta rows in the export.