Razorpay Pro for WooCommerce does not add its own primary tables. Payment data lives entirely on the WooCommerce order: razorpay_payment_id, razorpay_order_id, razorpay_subscription_id, refund IDs, and EMI plan references are written as meta on wp_wc_orders_meta (HPOS) or wp_postmeta (legacy). The default orders list ignores all of it because the screen shows core fields, not gateway-specific meta keys.

SleekView reads whichever storage your install runs and pivots the razorpay_* keys into named columns. A payment-method filter chip scopes the view to Razorpay Pro orders only. Subscription IDs and EMI plan codes become inline columns, which means finance reconciliation against the Razorpay dashboard happens in one screen instead of three.

Edits route through the WooCommerce CRUD layer where it makes sense (internal notes, custom tags), and refund operations stay on the gateway side via Razorpay's existing admin actions. SleekView never re-authenticates against Razorpay's API; it only surfaces the data the plugin already wrote.

WooCommerce's orders list shows core order fields and leaves gateway-specific metadata in the meta panel. That works when stores run one gateway and a simple checkout. It breaks for Indian D2C stores running Razorpay Pro with EMI plans, subscriptions, and partial payments alongside COD.

Finance teams reconciling Razorpay settlement files need razorpay_payment_id as a column to match payout lines, not as a buried meta entry. Subscription managers investigating churn need renewals grouped by razorpay_subscription_id. Customer support fielding refund tickets needs the refund ID inline.

The default workflow is custom code, custom reports, or a multi-tab dance between the Razorpay dashboard and WooCommerce admin. SleekView pivots razorpay_* meta into proper columns and detects HPOS automatically, which collapses each of those workflows into one saved view. The gateway still owns the API operations, refunds still flow through Razorpay, but the data Razorpay writes into your orders becomes queryable the way the schema was always meant to allow.