shadcn.io is not affiliated with official shadcn/ui
Recovery Queue Table Integration Block for Radix UI
An integration list section for a failed-payment recovery tool connecting to Stripe: a real table of six failing subscriptions with plan, amount, attempts, next retry and decline reason, a row menu (Retry now, Email customer, Pause dunning) and a tally worked out from the rows.
Installation
Overview
An integration list section for React with Radix UI, written for Dunlark, a fictional failed-payment recovery tool, and its Stripe connection. A compact header carries the mark pair at its end. Under a band rule, a tally worked out from the rows ("6 failing, $1,004 at risk") sits beside a polite status line that says every action stays on the page. Then the recovery queue as a real table, rail to rail: each failing subscription with its initials plate and name, plan, amount, attempts, next retry and the decline reason in words, and a menu with Retry now, Email customer and Pause dunning. Each choice sets that row's state ("Retry queued", "Email queued", "Dunning paused") and the tally follows; paused rows drop out of the tally and Resume dunning brings them back. On a narrower screen the plan, amount and attempts fold under the name and the reason under the next retry. Every row keeps its height in every state. It's built from Guides, Button and DropdownMenu, with a native table and your theme's tokens for every colour. Stripe is named in text only: no Stripe logo, colour or wordmark ships with the block. The customers and amounts are example data.
FAQ
How do I change the queue?
ACCOUNTS holds each row: the customer, a two-letter plate, plan, amount, attempts made, when the next retry runs and the decline reason. The tally adds up the amounts of rows that are not paused. The decline reasons are written in words, like "Insufficient funds" or "Expired card", rather than raw codes.
Do the menu items do anything real?
They change the row on this page and say so in the status line; nothing is retried, emailed or paused in Stripe, and no customer is contacted. Wire your own handlers where each action would call your API.
Why a native table?
It gives a caption, row and column headers and a sticky-free layout that behaves the same on every base. The region scrolls sideways with a focus ring if it is ever too narrow, and below the large breakpoint secondary columns fold into the first cells instead.
How do keyboard and screen reader users work it?
Each row's menu button is named with the customer ("Actions for Anya Lindgren"); arrow keys move through the menu and Escape closes it with focus back on the button. The status line is a polite live region present from load and announces each action.