Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Currency Select Pricing Block for Vue

Prices in the visitor's currency for a travel planner: five large currency chips in the header and three plan cells whose prices roll at display size between dollars, euros, pounds, yen and rupees, each currency with its own local price points.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Show every visitor a price they recognise with this currency pricing section, built here for Waymark Trips, a travel planner. A Segment Group of five large chips (USD, EUR, GBP, JPY and INR, each with its symbol over its code) sits in the header row beside a monthly and yearly switch, and three plan cells in one hairline band, with + marks on its corners, follow the choice: each price is set at display size and rolls to its amount with Sliding Number, whole yen and rupees included. The amounts are local price points, $6.99, €6.49, £5.99, ¥990 and ₹549, not a conversion. Below md a plan switch shows one plan at a time, Voyager first. Voyager is tinted, carries an outline Best value Badge and the only filled Shine Button. Built with Segment Group, Sliding Number, Badge, Guides, Shine Button and Lucide icons, with CSS transitions only. For consumer apps, international SaaS and any product that sells in more than one currency.

FAQ

How do I add a currency or change a price?

Add the currency to CURRENCIES with its ISO code, a name, its symbol and the number of decimals its prices show (0 for yen and rupees, 2 for dollars), and add the code to the CurrencyCode type. Every plan keeps one price per currency in monthly and annual (the monthly amount when billed yearly), so TypeScript flags a plan that is missing one. They are local price points set on purpose, such as €6.49 rather than $6.99 converted, so you choose what each market pays. A free plan uses the shared FREE prices.

How do I charge in the currency the visitor picked?

Each call to action is a real link to its plan's href. It's a ShineButton with asChild around an a element. Add the plan, the period and the currency to it, such as /checkout?plan=voyager&billing=yearly&currency=EUR, and have your server pick the matching price at your payment provider, where each plan has a price per currency. The amounts on the page are only a preview.

Are the chips and the switches accessible?

Yes. The currency chips are a Segment Group, a radio group named "Currency": Tab reaches the selected chip and the arrow keys move and select. Each chip is read with its code and its full name, such as "EUR Euros", and the symbol is decorative. The billing switch is a radio group named "Billing period". Prices aren't live regions, so switching doesn't interrupt a screen reader, each price reads as "per month", and every call to action names its plan, as in "Try 14 days free, Voyager plan".

How does it look on a phone?

The chips fill the width, five equal segments, so each stays easy to tap, and the billing switch sits under them. Below the md breakpoint a second switch named "Plan" shows one plan at a time, starting on the popular one, so the price and the filled button come within the first screen and a half. From md the three plans sit side by side in the band and the plan switch is gone.

Why don't the cells jump when the currency or period changes?

The digits are tabular, so a price only grows sideways when it gains a digit, and the cells keep their height. The line under each price keeps the room of the longer of its two texts, the monthly one and the yearly one, so switching never pushes the button down. On wide screens the three cells share their rows through CSS subgrid, so names, prices, buttons and feature lists line up whatever the descriptions' lengths.

Should the block start on the visitor's currency?

Yes, where you can tell. Pass the currency worked out on your server, from the request's country or the account, to useState<CurrencyCode> instead of "USD", so the first render is already right and nothing changes after loading. Keep the chips: travellers and teams paying from another country need to choose for themselves.