Gumroad for WordPress connects a WordPress site to the Gumroad creator commerce platform through the Gumroad API. Sale data lives on Gumroad's servers and is accessible through endpoints like GET /v2/sales. Each sale carries fields for the product name, the price, the customer email, plus flags for refunded, disputed, and chargebacked. Gumroad does not expose a single status field, so SleekView derives one from those flags to slot each sale into Pending, Successful, Refunded, or Disputed.

SleekView Kanban talks to the same Gumroad API the plugin uses, with the connection details pulled from the plugin's settings. Pick the derived status as the group column and every sale becomes a card slotted under Pending, Successful, Refunded, or Disputed. Card fronts show the buyer email, the product name, the sale price in store currency, the date sold, the variants purchased, and the affiliate if applicable, so finance has every Gumroad sale's context right on the card without opening Gumroad.

Dragging a card between columns calls the Gumroad API with the appropriate action endpoint, such as POST /v2/sales/{id}/refund for refunds. The Gumroad hosted record updates immediately, the customer notification email goes out through Gumroad's notification system, the Gumroad creator dashboard reflects the change, and any webhook subscriber receives the event, exactly as it would after a manual action through the Gumroad creator dashboard.

Creators running Gumroad for WordPress sell digital products to thousands of customers every quarter. Some sales are clean, some end up refunded for various reasons, and a small but stubborn slice get disputed by the card issuer or chargebacked. The default Gumroad creator dashboard treats all of them the same and offers no visual distinction between successful sales that are quietly working and disputes that need immediate attention from the support team.

The disconnect between the Gumroad backend and the WordPress side shows up in the worst places. A dispute notification sits unread for a week because the creator does not log in to Gumroad daily. A refund that should have been issued sits unprocessed because the support team did not see it in the dashboard.

A finance reconciliation shows hundreds of dollars in unexplained refunds because the creator never noticed when they happened. A kanban view that reads and writes the same Gumroad sales the dashboard reads, embedded in the WordPress admin where the creator already works, keeps the creator and the books honest. Every drag is a real API call, every column count reflects the real Gumroad state, and the cards themselves carry enough context for a new finance analyst to handle reconciliation on day one of the job without learning the Gumroad creator dashboard.