Paytm Payment Gateway for WooCommerce stores its identifiers as order metadata. paytm_txn_id, paytm_order_id, bank reference numbers, refund IDs, and the chosen payment mode (UPI, card, netbanking, Paytm wallet) live on wp_wc_orders_meta for HPOS stores or wp_postmeta on legacy. The default WooCommerce orders list ignores all of it because the screen shows core fields, not gateway-specific meta keys.

SleekView reads the right storage automatically and pivots the paytm_* meta keys into named columns. A payment-method filter scopes the view to Paytm-paid orders, and the chosen payment mode becomes its own column for UPI-versus-wallet cohort analysis. Bank reference numbers and refund IDs sit alongside transaction IDs so finance reconciliation against the Paytm merchant dashboard happens row by row.

Edits stay in the WooCommerce CRUD layer; refunds still go through Paytm's admin action that calls its API. SleekView never duplicates Paytm's API authentication and never replaces the gateway's refund flow.

WooCommerce's orders list is built around core order fields and treats gateway metadata as out-of-scope. That works for stores with one gateway and a simple flow. It fails for Indian merchants running Paytm across UPI, wallet, card, and netbanking, where the conversion question "which mode actually drives AOV" has a real answer in paytm_payment_mode that nobody can see without opening every order.

Finance teams reconciling Paytm settlements need paytm_txn_id and bank reference numbers as columns to match payout lines. Support fielding refund tickets needs refund IDs inline. The default workflow forces a tab-flip between the Paytm merchant dashboard and WooCommerce admin.

SleekView pivots paytm_* 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 flow through Paytm, but the data Paytm writes into your orders becomes queryable in the way the schema was always meant to allow.