Razorpay for WooCommerce attaches a Razorpay payment to every WooCommerce order it handles. The Razorpay payment ID lands in wc_orders_meta under a key such as _razorpay_payment_id, the linked Razorpay order ID under _razorpay_order_id, and the gateway's signature for verification under _razorpay_signature. The Razorpay payment lifecycle (created, authorized, captured, failed, refunded) maps to the WooCommerce order status the plugin sets on each transition.

SleekView reads wc_orders and joins on wc_orders_meta so each row carries both the WooCommerce status and the Razorpay payment ID. The natural column to group by is the WooCommerce status, which is what Razorpay drives on capture and refund: Pending payment for created, Processing for captured, Refunded for refunded, and Failed for failed. Cards show the order number, the customer name from billing_first_name plus billing_last_name, the total_amount, and the Razorpay payment ID for support lookups.

Dragging a card from Pending payment to Processing writes wc-processing to wc_orders.status, which is the same value the Razorpay capture webhook writes when the gateway captures the payment. Refunded orders stay visible as their own column so finance can reconcile against Razorpay's dashboard, and failed orders sit on the board too instead of being hidden behind a status filter, which matters in markets where card decline rates spike during peak hours.

Razorpay for WooCommerce ships a clean payment flow but reuses the WooCommerce orders screen for everything that happens after capture. That screen does not know Razorpay from any other gateway, so the team scrolls through a single mixed list with a filter dropdown to find their decline rate. A kanban grouped by status puts every Razorpay order on one screen with counts on each column and the Razorpay payment ID on each card for support lookups.

Pending payment, Processing, Completed, Refunded, and Failed become columns the team works during the day. Dragging a card writes the same wc_orders.status value the Razorpay capture or refund webhook would write, so any code listening on transitions behaves identically. Refunded and failed orders stay visible as their own columns, which is what reconciliation against the Razorpay dashboard needs at the end of the month.

The team reads the same data the orders screen reads, just with position and counts doing the heavy lifting.