Zip Checkout for WooCommerce processes Buy Now Pay Later payments through the Zip gateway. Orders come through with the standard WooCommerce statuses like wc-pending, wc-processing, wc-on-hold, wc-completed, and wc-refunded, plus Zip-specific metadata in wp_postmeta for the zip_order_id, the zip_charge_id, the consumer_id, and the Zip payment status. The native WooCommerce orders screen shows them mixed with all other orders, which makes Zip reconciliation impractical for finance.

SleekView Kanban reads the same WooCommerce orders you would query with WC_Order, filtered to orders that used the Zip gateway. Pick post_status as the group column and every order becomes a card slotted under Pending, Approved, Completed, or Refunded. Card fronts show the customer name, the order total in store currency, the zip_order_id, the consumer_id, the date placed, and the Zip installment plan summary, so finance has every Zip-specific detail right on the card for reconciliation against the Zip dashboard.

Dragging a card between columns calls the standard WooCommerce status transition the admin uses, which fires woocommerce_order_status_changed. Zip's refund flow fires for refund transitions when configured, the customer notification email goes out through WooCommerce's email module, the Zip merchant dashboard reflects the change, and any extension subscribed to the WooCommerce hooks reacts, exactly as it would after a manual admin status change.

Stores running Zip Checkout for WooCommerce process hundreds of BNPL transactions every day through the Zip gateway. Some clear instantly after Zip approves the installment plan, some take a few minutes for additional review, some get declined when the customer fails the credit check. The default WooCommerce orders screen mixes Zip transactions with COD, prepaid, and other gateway orders, which makes Zip-specific reconciliation a CSV export exercise every single day for finance teams.

The disconnect between what the Zip merchant dashboard shows and what WooCommerce shows is the source of most accounting headaches for Zip merchants. A successful BNPL approval lands in Zip but the WooCommerce order stays Pending because the webhook failed. A refund shows in WooCommerce but never appears in the Zip dashboard because the integration was misconfigured.

A daily payout from Zip shows revenue that does not match WooCommerce. A kanban view that reads and writes the same WooCommerce orders the gateway processed, filtered to Zip specifically, keeps the team and the books honest. Every drag is a real status change, every column count reflects the real Zip pipeline health, and the cards themselves carry enough context for a new finance analyst to handle reconciliation on day one of the job.