The Zip Pay WooCommerce gateway persists each transaction's Zip charge ID, authorize/capture state, and refund references on the order row via WooCommerce order meta. With HPOS enabled, that data lives in wc_orders_meta against wc_orders; on legacy stores it sits in wp_postmeta against shop_order posts.

The default WooCommerce orders screen treats Zip Pay orders the same as any other gateway. There's no column for the Zip charge ID, no filter for authorized-not-yet-captured Zip loans, and reconciling against Zip's merchant portal currently means CSV exports plus spreadsheet joins.

SleekView reads wc_orders joined with wc_orders_meta and surfaces the Zip charge ID, capture state, and refund references as first-class columns. Sort by charge ID to match Zip's portal row-for-row, filter for the capture queue, and inline-edit status with the gateway's hooks fully intact.

Zip Pay is one of the dominant BNPL gateways for Australian and New Zealand WooCommerce stores, and its lifecycle follows the same authorize-then-capture pattern as Affirm and Afterpay. Orders sit in authorized state waiting for merchant capture, and capture windows expire if not actioned. The default WooCommerce orders screen does not surface the Zip charge ID or capture state on the row, so finance teams reconcile by exporting CSVs and joining against Zip's merchant portal in a spreadsheet.

SleekView reads wc_orders joined with wc_orders_meta and puts the Zip charge ID, capture state, and refund references on the row. Authorized-not-captured becomes one saved filter that runs the daily capture sweep. Reconciliation becomes a sort by charge ID.

Inline edits route through the gateway's CRUD so capture, void, and refund hooks fire exactly as they would from the per-order screen. The merchant still has the standard Orders screen if they prefer it; the BNPL audit surface is what changes for finance, fulfilment, and support.