No. SleekView reads from wp_postmeta on the nf_sub post, which is where Ninja Forms Stripe stores the charge ID, amount, and status when a webhook fires or a checkout completes. Refunds, captures, and dispute responses still happen in Stripe itself. SleekView is the WP-side reporting and annotation layer.

Whatever the add-on writes, automatically. Typically _stripe_charge_id, _stripe_amount, _stripe_currency, _stripe_status, and any custom-named keys the site has added. The column picker lists every meta key actually present on nf_sub posts, so add-on updates that introduce new keys surface without configuration changes.

Refund state isn't always written back to postmeta by the add-on. If your installation does sync refund webhooks to a meta key (e.g. _stripe_refund_id), SleekView will surface it as a column. If not, the cleanest pattern is a SleekView-managed annotation column where finance records the refund decision and date alongside the original charge.

No. Editing a SleekView cell writes to wp_postmeta only. Stripe's side of the world is unaffected by any annotation you add. This is deliberate, the connection from WP to Stripe stays one-way (webhooks in), so accidental edits in WP Admin cannot create reconciliation bugs.

Ninja Forms Stripe supports subscription products via the same nf_sub + postmeta pattern, with extra keys like _stripe_subscription_id. SleekView surfaces those as additional columns so you can filter by subscription status, sort by next-billing date if the meta is present, and group renewals by amount band.

Yes. SleekView's saved views are per-role scoped: finance can see the payments-joined view with charge IDs and amounts, support sees customer-centric views with masked payment data, and admins see everything. Views are config artefacts, so they can live in your codebase if you prefer them under version control.

SleekView queries posts + postmeta with indexed joins on post_id and pivots in SQL, not PHP. Tested through six-figure submission counts without pagination slowness. If your postmeta table is large for unrelated reasons, scoping the view to post_type = nf_sub keeps the working set small.

SleekView reads posts and postmeta, both of which are core WordPress tables. So long as Ninja Forms continues storing submissions as nf_sub posts (the documented and current model), SleekView views keep working. If a future major version moves to a custom table, SleekView would add a separate source adapter for it.