shadcn.io is not affiliated with official shadcn/ui
Breadcrumb Checkout Block for Svelte
A picture-frame shop's checkout led by a breadcrumb: Cart, Shipping and Payment with an item count, steps you can go back to, and a Total changed badge on Payment when a quantity or the delivery method moves the total.
Installation
Overview
Tell people what going back changed, with this breadcrumb checkout for Svelte with Ark UI. A header from Elderflower Mews, a picture-frame shop, sits over a hairline frame with a plus mark on each corner. A trail of Cart, Shipping and Payment runs along the top: the item count sits in a Badge on Cart, steps you have reached are buttons you can go back to, and steps you have not reached are plain text. Each step has its own checks: quantities with a minus and a plus; a name, street, ZIP and a delivery choice from a Radio Group; an email and a card as one joined control. The feature is the consequence line. Reach Payment, go back to Shipping, change Standard to Express, and the Payment crumb gets a "Total changed" badge while the polite status line says "Shipping is now $9.90; your total is $73.90". Going to Payment again clears the badge. Pay is the only Shine Button, its label carrying the total. On a phone the trail scrolls sideways and the foot stays pinned to the bottom of the screen. For checkouts where an early choice moves a late price.
FAQ
When does the Total changed badge appear?
When Payment has been shown at least once and the total is no longer the one it showed. The block remembers the total on the last visit to Payment; changing a quantity in Cart or the delivery method in Shipping makes the current total differ, so the badge appears on the Payment crumb and the status line says what moved. Opening Payment again stores the new total and removes the badge. Every figure is in whole cents.
Which crumbs can I press?
Those up to the furthest step you have reached, except the one you are on. The current step is plain text marked as the current step for assistive technology; steps beyond the furthest reached are plain text and cannot be pressed. Forward moves still go through the foot button so each step's checks run. After the order is placed the trail is read-only.
What does each step check?
Cart needs at least one item. Shipping needs a delivery choice, and for Standard and Express a name of two letters or more, a street and a five-digit ZIP; Collect needs no address. Payment needs an email and a card whose number passes the Luhn sum, whose expiry is not before October 2026 and whose CVC has the right length for the brand. A press with problems names each one under its field and moves focus to the first; the button is never disabled.
Can I use this to take real card payments?
No, and the code says so. 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, with this layout, labels and error wording around them and the real autocomplete tokens (cc-number, cc-exp, cc-csc, cc-name) that those fields set themselves. Autocomplete is off in the demo so a browser never offers a real saved card to it. Test card 4242 4242 4242 4242 passes with any future expiry (checked against October 2026); a number that fails the Luhn sum, a past expiry or a CVC of the wrong length says so under the field.
What stays local, and how do I connect it for real?
Everything: quantities, the address and the order live in this block's state and Pay only says what would happen. To connect it, read the cart and the delivery rates from your commerce API, send the order with your provider's payment token, and reuse the consequence line wherever a change on an earlier step can alter the total.