The WooCommerce Worldpay extension writes transaction ids, auth codes, AVS and CVV results, and capture status into order meta on every checkout. On HPOS stores those land in wc_orders_meta under keys like _wc_worldpay_transaction_id, _wc_worldpay_auth_code, _wc_worldpay_avs_response, and _wc_worldpay_capture_status. None of those appear on the default Orders screen. Reconciling Worldpay's batch report against WordPress means opening every authorised order to confirm capture.

SleekView reads these keys as first-class columns alongside the order status, amount, and customer email. Authorised-but-uncaptured orders become a saved view sorted by date. Declined transactions filtered by AVS result become a fraud audit table. Refunds from shop_order_refund (legacy) or refund rows in wc_orders (HPOS) join in so a single row shows the original capture and any reversals.

Inline edits route through the WooCommerce CRUD layer, so woocommerce_order_status_changed fires and the plugin's own capture and refund actions can still be triggered from the order context. SleekView does not bypass the gateway; it gives ops a row-level view of the data the plugin already records.

Worldpay is one of the older, more configurable card gateways still in heavy use across UK and European stores. It exposes auth, capture, settle, and refund as separate operations, and the WooCommerce extension records all of that into order meta. The default WooCommerce Orders screen does not know any of those fields exist.

A merchant looking at the Orders page sees Processing or Completed and a total, not whether the auth has been captured yet, not whether AVS matched, not whether the order is approaching the auth-expiry window. Finance teams reconcile Worldpay batches by hand, risk teams spot fraud patterns only retrospectively, and support teams answer chargeback questions by opening each order in turn. SleekView reads the meta the plugin already writes and exposes it as columns ops can sort, filter, and update.

Same database, same plugin handlers, same webhook flow. The capability gained is row-level visibility into a payment lifecycle the default admin treats as opaque.