No. It reads what the Instamojo plugin already stored against each WooCommerce order: the payment id and the payment request id. Live calls to Instamojo for settlement or refund status would need an additional integration that the plugin itself does not provide. Most reconciliation work is the side-by-side match between what the order shows and what the Instamojo dashboard shows, which is exactly what the table view enables.

Yes. On HPOS the gateway meta lives in wc_orders_meta; on legacy stores it lives in postmeta. SleekView detects the schema and reads from whichever the store uses. Joins to addresses, customer lookup, and operational data work identically.

Yes. Status changes route through WooCommerce's CRUD layer so any gateway-side hooks the Instamojo plugin or your custom code listens to fire as expected. Bulk status changes iterate per row through CRUD so the side effects are identical to manual edits.

WooCommerce-side refunds are visible (the order status, the refund total, the refund line items). Whether the gateway-side refund completed at Instamojo is not stored in WooCommerce by default, so that confirmation still comes from the Instamojo dashboard. A reconciliation view that flags WooCommerce-side refunded orders against Instamojo-side refunded payments becomes the actionable workflow.

Failed Instamojo attempts are typically not promoted to WooCommerce orders unless the plugin records a pending order first. Where the plugin does record them, the failure response is visible on the order's note history and can be exposed as a column. For full failed-attempt logging, server-side log files are the source of record.

Yes. The order's payment_method field stores the Instamojo slug. A saved view filtered to that value scopes any join, sort, or bulk action to Instamojo-paid orders only, useful when finance owns reconciliation across multiple gateways and wants one tab per gateway.

Yes. Each gateway stores its own meta against the order. SleekView can show a single mixed view with conditional columns (payment id from whichever gateway the order used) or scope cleanly per-gateway with a saved view per payment method. The choice depends on whether finance wants one cross-gateway feed or a per-gateway tab.

Order queries hit indexed columns on wc_orders and join meta through indexed lookups. Pagination is keyset where the schema allows. Aggregate columns (lifetime Instamojo spend per customer, for example) are heavier and stay opt-in per view to keep the day-to-day reconciliation queue fast.