The Laybuy WooCommerce gateway persists each transaction's Laybuy token, instalment plan reference, and capture/refund state 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 shows none of those identifiers on the row. Finance teams reconcile against Laybuy's merchant portal by exporting CSVs and joining against the settlement file by hand, and there's no native filter for Laybuy-specific states like "instalment failed" or "awaiting merchant action".

SleekView reads wc_orders joined with wc_orders_meta and surfaces the Laybuy token, instalment plan reference, and capture state as first-class columns. Sort by token to match the merchant portal, filter for the capture queue, and edit status inline with the gateway hooks fully intact.

Laybuy serves Australia, New Zealand, and the UK with a six-week instalment BNPL product, and its lifecycle puts capture decisions in the merchant's hands within a fixed authorization window. The default WooCommerce orders screen does not surface the Laybuy token, instalment plan, or capture state on the row, so finance teams reconcile by exporting CSVs and joining against Laybuy's merchant portal in a spreadsheet. SleekView reads wc_orders joined with wc_orders_meta and puts the token, plan reference, and capture state on the row.

Authorized-not-captured becomes one saved filter that runs the daily capture sweep before authorizations expire. Multi-currency split becomes a group-by on the currency column. 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 instalment audit surface is what changes for finance, fulfilment, and support.