Razorpay for WooCommerce doesn't add primary tables. Payment data lives entirely as WooCommerce order metadata: razorpay_payment_id, razorpay_signature, refund IDs, and the is_magic_checkout_order flag are written via get_meta or update_post_meta depending on whether the store runs HPOS or legacy storage. The default WooCommerce orders list ignores all of it because the orders list shows core fields, not gateway-specific meta keys.

SleekView reads the right storage automatically: wc_orders_meta on HPOS, postmeta on legacy. The Razorpay meta keys get pivoted into named columns so payment ID and Magic Checkout flag are visible inline. A payment-method filter chip scopes the view to Razorpay-paid orders only, which decouples gateway analysis from sites with multiple gateways. Refund IDs surface as a column for fast reconciliation against the Razorpay dashboard.

The Magic Checkout flag is particularly useful because the alternative checkout flow is a deliberate conversion experiment for many Indian D2C stores. Surface it as a column and segment by it: AOV with Magic Checkout, AOV without, conversion lift visible in the orders view rather than in a custom analytics integration. SleekView doesn't replace the gateway, refunds still flow through Razorpay's API via the WooCommerce admin, but it makes the data Razorpay already writes into orders queryable as it should be.

WooCommerce's orders list is built to show core order fields and leaves gateway-specific metadata in the meta panel. That works when stores have one gateway and a simple flow. It breaks for Indian D2C stores running Razorpay with Magic Checkout side-by-side with COD, where the conversion question 'does Magic Checkout actually move AOV' has a real answer in the order metadata that nobody can see without opening every order.

Finance teams reconciling Razorpay payouts against WooCommerce orders need payment_id as a column to match settlement files, not as a buried meta entry. Customer support fielding 'where's my refund' tickets needs refund_id inline. The default workflow is custom code, custom reports, or a multi-tab dance between Razorpay's dashboard and WooCommerce admin.

SleekView pivots the razorpay_* meta keys into proper columns and detects HPOS automatically, which collapses each of those workflows into a single saved view. The gateway still owns the API operations, refunds still go through Razorpay, but the data Razorpay writes into your orders becomes queryable in the way the gateway's persistence pattern was always intended to enable.