No. It reads what the PayU Money plugin already stored against each WooCommerce order: the gateway transaction id, the mihpayid, and the payment mode. Live calls to PayU 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 PayU's 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 PayU 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 PayU is not stored in WooCommerce by default, so that confirmation still comes from the PayU dashboard. A reconciliation view that flags WooCommerce-side refunded orders against PayU-side refunded txns becomes the actionable workflow.

Failed PayU 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 PayU slug. A saved view filtered to that value scopes any join, sort, or bulk action to PayU-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 (txn 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 PayU spend per customer, for example) are heavier and stay opt-in per view to keep the day-to-day reconciliation queue fast.