Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Recovery Queue Table Integration Block for React

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.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

An integration list section for React with Base 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.

Does a row grow when its state changes?

No. The next-retry and reason cells keep a line for "Email queued" and swap text only, so the table never moves when you act on a row.

How does it behave on a phone and in right-to-left layouts?

On a phone each row shows the customer with plan, amount and attempt under the name, the next retry with the reason under it, and the menu. In a right-to-left layout the table mirrors; amounts, counts and the tally keep their own direction.

  • Pro

    An integration detail section for a failed-payment recovery tool connecting to Stripe: the dunning schedule as four hairline cells, a None, Read and Write table of what a restricted key allows, three steps and a Connect Stripe Shine Button.

  • Pro

    An integration setup section for a failed-payment recovery tool connecting to Stripe: three numbered bands (a copyable webhook endpoint, a signing secret in a password field, four event checkboxes) and a foot band with a test event and a Finish setup Shine Button.

  • Pro

    An integration grid section for a failed-payment recovery tool connecting to Stripe: three radio cards in shared hairlines, each drawing its retry schedule on a 14-day line, with a check and an inset rule on the chosen one.

  • Pro

    An integration list section for a stock sync tool connected to Shopify: seven variants waiting for a match as rail-to-rail rows, each with a Select to pick one of your items, a Skip button and a state, under a progress bar and a count worked out from the rows.

  • Pro

    An integration list section for a spend approvals tool posting to Slack: underline tabs with counts (Waiting, Approved, Expired) over rail-to-rail request rows, with a channel in code, a state line, a reminder count and a Nudge button on waiting rows.

  • Pro

    Invoice History Billing

    Payment and invoices

    An account's invoices: a table filtered by status (paid, due, failed) with amounts, dates and PDF links, and a retry on the failed payment. On a phone each invoice is a card.