PagSeguro for WooCommerce does not add its own primary tables. Transaction data lives as WooCommerce order metadata: pagseguro_transaction_id, pagseguro_payment_method, boleto barcodes, PIX QR references, and installment count are written through the WooCommerce meta API to wp_wc_orders_meta on HPOS or wp_postmeta on legacy. The default orders list ignores them because the screen renders core fields only.

SleekView reads the right storage automatically and pivots the pagseguro_* meta keys into named columns. A payment-method filter scopes the view to PagSeguro orders. Boleto barcodes, PIX expiry, and installment count become inline columns, which means Brazilian finance and support teams resolve reconciliation and customer queries in one screen instead of multiple tabs.

Edits route through the WooCommerce CRUD layer for the columns the plugin marks editable. Refunds still flow through PagSeguro's admin action that calls its API; SleekView never duplicates that path.

WooCommerce's orders list shows core fields and treats gateway metadata as out-of-scope. That works for stores with one gateway. It fails for Brazilian stores running PagSeguro across card, boleto, PIX, and account-money in parallel, where boleto share alone can decide whether a month closes profitably.

Finance reconciling PagSeguro settlements needs pagseguro_transaction_id as a column to match payout lines. Support fielding pending-boleto queries needs expiry timestamps inline so they can chase customers before the boleto lapses. Conversion analysts comparing parcelas need installment count as a filter chip.

The default workflow forces a tab-flip between the PagSeguro merchant dashboard and WooCommerce admin. SleekView pivots pagseguro_* meta into proper columns and detects HPOS automatically, which collapses each workflow into one saved view. The gateway still owns API operations, refunds still flow through PagSeguro, but the data PagSeguro writes into your orders finally becomes queryable as plain WooCommerce data.