shadcn.io is not affiliated with official shadcn/ui
Payment Gateway Settings Block for React
A payment gateway panel with a Test and Live mode, processor radio cards, prefix-checked API keys with masked secrets and a three-step go-live checklist that refuses Live until every step is done.
Installation
Overview
Gate the switch to real money behind a checklist with this payment gateway panel for React with Base UI. Inside a hairline frame with a plus mark on each corner, a Segment Group sets the mode, Test or Live, and one sentence says what that means for customers. Three radio cards pick the processor (Stripe, PayPal or Adyen, named in text with a two-letter tile). A second Segment Group shows the keys of one set at a time: the publishable key, the secret key and the webhook signing secret in Password Input fields that mask the secrets, each checked against its prefix, plus the webhook endpoint. The go-live checklist derives its three steps from what you typed (live keys entered, an https webhook endpoint, business details confirmed), and choosing Live before all three tick is refused: the status line says how many steps remain and focus moves to the first one that is missing. The last band counts unsaved changes in a status line beside a Shine Button to save them and an outline Button to discard them, pinned to the bottom of the screen. It's built from Segment Group, Password Input, Input, Field, Button, Shine Button and Guides, with a CSS entrance only. For a checkout, billing or marketplace product, or any setting where a mistake costs real money.
FAQ
How do I fill it with my own processors and key formats?
Edit the constants at the top. CHOICES lists the processors with their two-letter tiles, PREFIX holds what each key starts with in test and live, and SAVED is what the account has stored when the page opens. The sample keys are made up for the demo. In your app, load the real values from your server and never put a secret key in client code.
How does the Live gate work?
The checklist is derived from the draft, not stored: live keys are entered when all three start with their live prefix, the webhook endpoint is set when it is a full https address, and the business step is a checkbox. Choosing Live while any step is open does nothing but explain: the status line reads "Live needs 2 more steps." and focus moves to the first missing field (the live keys switch the key view to Live first). Saving is also refused if the draft is in Live with a step open.
What does the prefix check do?
It runs when you press Save: a key that is not empty and does not start with its prefix, or is too short after it, is marked invalid with a line that names the prefix, the key view switches to the set it belongs to, and focus lands on it. While you type, a quiet line under each field shows the prefix it expects. Replace the check with your processor's own key format; a prefix is a typo guard, not verification.
What happens when I press Save, and what stays local?
Nothing leaves the page and no processor is contacted. The block keeps the saved gateway and the one being edited, and counts how many settings differ, so the status line can say "3 changes not saved yet." Save makes the edited copy the saved one and says it was saved in this demo; Discard puts the saved copy back. To make it real, send the draft to your server in the save handler, store the secrets there, and return only masked values to the page. Save and Discard are marked aria-disabled rather than disabled while nothing changed, so they keep their place and focus.
Are the secret fields really hidden?
They are password inputs with a show button, so the value is masked on screen until you press it, but the page still holds the text in memory, as any form does, and they ask the browser not to offer saved passwords. For real secrets, show only the last four characters after saving and ask for a new value to change it.