shadcn.io is not affiliated with official shadcn/ui
Dunning Schedule Detail Integration Block for React
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.
Installation
Overview
An integration detail section for React with Base UI, written for Dunlark, a fictional failed-payment recovery tool, and its Stripe connection. A compact header carries the title and one sentence, with the mark pair above a "Connect Stripe" Shine Button and a "View docs" link at its end. Under a band rule, the dunning schedule as four cells in shared hairlines whose outer lines run past the rails: Day 0 the payment fails and the first email goes, Day 3 a retry and the second email, Day 7 the last retry and a final notice, Day 14 cancel unless paid. Under the next rule, what a restricted Stripe key must allow, as a real table: one row per resource, None, Read and Write as three columns with a check in the granted one, and a count worked out from the rows. A closing band of three numbered steps ends the block. It's built from Guides, Button and ShineButton, with your theme's tokens for every colour. Stripe is named in text only: no Stripe logo, colour or wordmark ships with the block.
FAQ
Is the None, Read, Write table how Stripe keys work?
Yes. A restricted API key is created in the Stripe Dashboard by choosing, for each resource, None, Read or Write. The rows here (Customers, Invoices, Subscriptions, Charges) are the resources Dunlark's example behaviour needs; everything else stays at None. Check the resource names against your own Dashboard before you ship.
Is the schedule fixed?
The four cells are an example of a typical schedule, written in SCHEDULE. The grid section lets the buyer pick a pace and the setup section the events that drive it. Nothing here charges or retries anything.
Does the button connect to Stripe?
No. The Shine Button and "View docs" are plain links; point them at your own connect flow and documentation. This section has no state.
How do screen readers read the table?
It is a real table with a caption, column headers and row headers. Each cell says whether the level is granted or not in text for screen readers; the check and the dash are decorative. On a narrow screen the reason for each row moves under the resource name and the table scrolls in a focusable region if it must.
Related
- Pro
Slack Detail Integration
Scopes and stepsAn integration detail section for a spend tool connecting to Slack: a header with the mark pair and Add to Slack, then what it does, the Slack scopes it reads and writes, three steps to install and the listing's facts.
- Pro
Stock Table Detail Integration
With a product drawingAn integration detail section for a stock sync tool connecting to Shopify: a framed before-and-after table of three variants with a hatched reserve, beside the four access scopes, three steps and a Connect Shopify button.
- Pro
Webhook Endpoint Setup Integration
Keys and codeAn 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
Retry Schedule Cards Integration
Cards and previewsAn 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
Recovery Queue Table Integration
Synced tablesAn 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.
- Pro
Usage Alerts Billing
Plan and usageUsage alert settings: percentage thresholds as switches with number inputs, recipients as email chips, and a choice between email and a webhook, with a save that checks them.