Instamojo Payments for WooCommerce writes its identifiers as order metadata. instamojo_payment_id, mojo_payment_request_id, transaction status, and refund IDs live on wp_wc_orders_meta on HPOS stores or wp_postmeta on legacy. The default WooCommerce orders list never shows them because the screen renders core fields, not gateway meta keys.

SleekView reads the right storage automatically and pivots the Instamojo meta keys into named columns. A gateway filter chip scopes the view to Instamojo-paid orders. Payment request IDs sit alongside transaction IDs so support tickets resolve in one screen, and refund state becomes a queryable column instead of a manual click into each order.

Edits route through the WooCommerce CRUD layer for the columns the plugin marks editable. Refunds still flow through Instamojo's admin action that calls its API; SleekView never re-authenticates against Instamojo or duplicates that call.

WooCommerce's orders list shows core order fields and ignores gateway-specific meta. That trade-off works for stores with one gateway and a simple flow. It fails for Instamojo-first Indian D2C stores where every payment carries a request ID, a transaction ID, and a status that finance and support both need to see.

Reconciling Instamojo settlement files becomes a tab-flip between the Instamojo dashboard and the WooCommerce admin, with finance copy-pasting payment IDs row by row. Support fielding failed-payment tickets opens each order to find the failure reason. The default workflow is custom code or custom reports.

SleekView pivots Instamojo's mojo_* and instamojo_* meta into proper columns and detects HPOS automatically, which collapses both workflows into one saved view. The gateway still owns the API operations, refunds still go through Instamojo, but the data Instamojo writes into your orders becomes queryable as plain WooCommerce data.