shadcn.io is not affiliated with official shadcn/ui
Trust Badges Checkout Block for Vue
A small card payment form beside three folding rows that each open to one honest paragraph on returns, card handling and contact hours, with the accepted cards as plain words and no seals.
Installation
Overview
Reassure without pretending, with this trust-badges checkout for Vue with Ark UI. A compact header from Amberleigh, a mattress maker, sits over a hairline frame with a plus mark on each corner. The first band is the order in one line, a double mattress at $899.00, and under it a payment form built from Field and Input: card number, expiry and code, with the brand worked out from the first digits, the Luhn check, the expiry checked against a fixed month and a complete part moving focus to the next. Beside it, or under it on a phone, three Collapsible rows each open to one paragraph that says what the reassurance means: the 30-day returns policy, how card details are handled in this demo and in a real shop, and when and how to reach the shop. Below them the cards the shop accepts are three words in outline Badges. There is no seal, no padlock, no certifier logo and no review count: every line is a true statement about this page or a policy the shop would type itself. Pay is the only Shine Button. For any shop that wants to answer the doubts people have at the payment step.
FAQ
Why are there no security seals or review counts?
A seal or a star count that nobody can check is a claim, not a fact, and this block is about facts. Each line here is either true of the page in front of you (the digits stay in this tab and are cleared when you press Pay) or a policy the shop would write itself (30-day returns, opening hours). Replace the three paragraphs with your real ones; if you hold a certification, link to the issuer's own page for it instead of drawing its badge.
Can I use this to take real card payments?
No. It checks a card in the tab's memory (brand by the first digits, the Luhn sum, the expiry against a fixed month) so you can see the pattern. A real page never lets card digits reach its own code: it uses the fields your payment provider hosts, an iframe of theirs, inside this layout, with the real autocomplete tokens those fields set. Autocomplete is off here so a browser never offers a real saved card to a demo.
Which cards work in the demo?
4242 4242 4242 4242 with any future expiry (checked against October 2026) and any three digits passes. A number that fails the Luhn sum, an expiry in the past, a month above 12 or a code of the wrong length each says so under its field and marks it invalid. A press with problems names each, moves focus to the first and never disables the button.
How do the folding rows behave?
Each row is a button inside a heading, so a screen reader can list them; the content is inert while closed and one row opening does not close the others. The chevron turns with CSS only and not at all under reduced motion, and the panel keeps its height on the form side because the rows sit beside the form on wide screens.
What does a successful payment keep?
Only the brand and the last four digits. The number, expiry and code are cleared from state when the demo answers, and the fields are replaced in the same space by the result with a Pay again button, so the panel does not change height. The status line says that nothing was charged.
What stays local, and how do I connect it for real?
All of it: the wait is a timer and the answer comes from the card number typed. To connect it, mount your provider's hosted fields in the form's place, keep this layout and the three paragraphs, and have Pay confirm the payment with the provider's token on your server, showing its error in the same reserved line the field problems use.