CCAvenue Payment Gateway for WooCommerce does not add its own primary tables. Tracking and bank data live as order metadata: ccavenue_tracking_id, ccavenue_bank_ref_no, ccavenue_payment_mode, and refund status are written via the WooCommerce meta API to wp_wc_orders_meta on HPOS or wp_postmeta on legacy. The default orders list shows none of it because the screen renders core fields, not gateway meta.

SleekView reads the right storage automatically and pivots the ccavenue_* meta keys into named columns. A payment-method filter scopes the view to CCAvenue-paid orders. Tracking IDs and bank reference numbers become inline columns, which means matching CCAvenue settlements against WooCommerce orders happens row by row instead of tab by tab.

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

WooCommerce's orders list shows core fields and ignores gateway-specific meta. That works for stores with one gateway and a clean checkout. It breaks for Indian merchants running CCAvenue across card, netbanking, UPI, and wallets in parallel.

Finance reconciling CCAvenue settlement reports needs tracking ID and bank reference numbers as columns to match payout lines, not as meta buried inside the order edit screen. Support fielding refund tickets needs refund IDs inline. Conversion analysts comparing payment modes need ccavenue_payment_mode as a filter chip.

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