Affirm's WooCommerce gateway persists each transaction's Affirm charge ID, capture timestamp, 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 Affirm-paid orders no differently from Stripe orders. There's no Affirm-only filter, no column for charge ID, and no built-in view for authorized-but-not-yet-captured loans waiting on settlement. Reconciliation against Affirm's merchant dashboard means CSV export plus spreadsheet joins, one row at a time.

SleekView reads wc_orders joined with wc_orders_meta and surfaces the Affirm charge ID, capture state, and refund references as first-class columns. Inline status edits route through WooCommerce's CRUD layer so Affirm's capture and refund hooks fire as expected. Finance reconciles by sorting on charge ID; ops captures authorized loans from one filtered view.

BNPL gateways like Affirm record their own external charge IDs against each WooCommerce order, and the operational question for every store running one is which loans are authorized, which are captured, and which slipped through the authorization window without being captured. The default WooCommerce orders screen does not surface that distinction as a row-level column, so finance teams reconcile by exporting CSVs and joining them against the Affirm merchant dashboard in a spreadsheet. SleekView reads wc_orders joined with wc_orders_meta and puts the Affirm charge ID, capture state, and refund references on the row.

Authorized-not-captured becomes one saved filter. 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.