A store is four screens - listing, product, cart, checkout - and the components for the first two are everywhere while the ones that decide revenue are not. That is worth knowing before you go shopping for a product card: the card is the easy half, and the money is lost between the cart and the confirmation.
215 components on 21st carry the ecommerce and product-card tags. Here is what they cover.
The product card
Product Card by Ravi Katiyar, ProductCard by youcefbnm and Product Card by beratberkay are the standard shapes. Product Image Card by Ruixen UI leads with the photograph, and Product Reveal Card by Isaiah adds a hover reveal.
Spatial Product Showcase by Daiwiik Harihar is the hero-scale version for a single item.
What a card needs, in the order shoppers read it: the image at a fixed aspect ratio, the name at two lines maximum, the price with any discount shown as both numbers, and one action. The card guide covers why the aspect ratio and the line clamp matter more than the styling.
Two ecommerce-specific rules. Show availability on the card, because a shopper who reaches a product page to find it out has been wasted. And make the whole card a link to the product with a real <a href>, using the stretched-link pattern, so the "add to cart" button inside it still works.
The checkout
Interactive Checkout by kokonutd is the assembled flow. This is where the components thin out and the rules matter most.
Guest checkout, first. Forcing account creation before purchase is the single most cited cause of cart abandonment, and it is a decision rather than a technical constraint.
Show the full total before the payment step. Shipping, tax and fees revealed on the last screen are the second most cited cause. If you cannot compute them earlier, say so earlier.
One page or a stepper, not both. Whichever you pick, show progress and keep every earlier step editable without losing what came after.
Autofill, seriously. autocomplete="cc-number", cc-exp, cc-csc, postal-code, address-line1, country. A checkout without them is a manual retype on a phone, and it is four attributes.
Do not touch card fields yourself. Use the payment provider's hosted fields or elements. Rendering your own card input pulls your whole application into PCI scope, which is a compliance problem rather than a UI decision.
The markup that gets the listing found
Ecommerce is the one area where structured data is uncontroversially worth the effort, because Product markup with Offer drives price, availability and review snippets in search results.
Three things make it work. The price and currency in the markup must match what is on the page and in the cart. availability has to reflect the real stock state rather than being hardcoded to in-stock. And the markup belongs on the product page, not on the listing, where it describes a page that is not a product.
The same data is what an answer engine reads when someone asks what something costs, which is now a meaningful share of the queries that used to arrive as a search.
The cart, which is where the details hide
The cart is not a list, it is a set of small stateful problems: quantity changes that update a total without a page load, a removal that offers an undo rather than a confirmation, a stock check that happens again before payment because the item may have sold in the meantime, and a persisted state that survives a closed tab.
None of that is visual, and it is the part no component gives you.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| A commerce platform's components | Cart, checkout and payments, wired and compliant | Their look, and their data model |
| shadcn/ui | Every primitive underneath the four screens | Nothing commerce-shaped |
| A payment provider's elements | Card fields you are allowed to ship | Styling is constrained by design |
| 21st | Product cards, showcases and checkout layouts | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a product card, get the previews inline, and let the agent write the file.
Frequently asked
- What belongs on a product card?
- The image at a fixed aspect ratio, the name clamped to two lines, the price with any discount shown as both numbers, availability, and one action. Make the whole card a real link to the product using the stretched-link pattern, so the add-to-cart button inside it still works.
- What causes cart abandonment?
- Two things dominate: forcing account creation before purchase, and revealing shipping, tax and fees only at the final step. Both are decisions rather than technical constraints. Offer guest checkout, and show the full total as early as you can compute it, or say early that you cannot.
- Which autocomplete attributes does a checkout need?
- cc-number, cc-exp, cc-csc, postal-code, address-line1 and country at minimum. A checkout without them is a manual retype on a phone at the most abandonment-prone moment in the flow, and adding them is four attributes.
- Should I build my own card input?
- No. Use the payment provider's hosted fields or elements. Rendering your own card input pulls your whole application into PCI scope, which turns a UI decision into a compliance problem. Style what the provider exposes and accept the constraint.