The Ninja Forms Stripe add-on takes a payment as part of the form submit flow and writes the Stripe charge state into the entry meta of the Ninja Forms entry. Under Ninja Forms > Submissions you see the entry list with a small column for the payment total. The actual Stripe payment status, the charge ID, and the customer ID all sit inside the entry meta where they are invisible without clicking into every row.

SleekView reads from wp_nf3_submissions and the postmeta keys the Stripe add-on writes for each entry, including _payment_status, _stripe_charge_id, _payment_total, and _payment_currency. The payment status field is the natural grouping axis since it tracks the Stripe state machine: pending, authorized, captured, refunded, and failed. Each card shows submitter name, total amount with currency, the last four digits of the card when available, and the relative time since charge.

Dragging a card writes the new payment status back to the entry meta and fires the standard Ninja Forms entry update hook so any downstream actions, like accounting exports or success email sequences, stay in sync with the operational state shown on the board. Failed and refunded payments stay in their own columns instead of mixing with active charges, which keeps the finance review surface clean.

The Ninja Forms Stripe add-on does the right thing on submit. It charges the card, writes the result back to entry meta, and fires the success or failure hook. The problem is the admin surface afterwards.

The Ninja Forms submissions screen treats every entry as just one more row in a list, the same way every form submission shows up, even though the entries that went through Stripe carry a totally different lifecycle: pending, authorized, captured, refunded, failed. A flat list buries that lifecycle in meta keys you only see when you click into an individual entry, which means finance ends up exporting CSVs to reconcile with the Stripe dashboard or scrolling through entry after entry to find refund candidates. A kanban board fixes the visibility gap by treating payment status as the primary axis and totals per column as first-class information.

The captured column shows today's revenue, the refunded column shows refund volume, the failed column lets the team chase recoverable revenue, and the authorized column shows what is still sitting waiting on capture. Status changes happen with a single drag instead of three clicks per entry, and because everything writes back to the same Ninja Forms entry meta, accounting exports, success emails, and downstream automations keep working exactly as they did. The result is a Ninja Forms admin that finally lets finance run a real payment surface.