How to show prices in leva and euro in PrestaShop

To show prices in leva and euro on a PrestaShop product page, keep one price per product in your default currency, activate both currencies in the shop, and display the second amount by converting it with the exchange rate PrestaShop already stores. Attach that display to a theme hook so the theme keeps control of the layout. A second, manually maintained price field looks simpler at first, but it drifts out of step with the rates and multiplies the work on every price change.

This article explains why, walks through the ways to add a second currency to the price block, and lists what to check before you go live. It applies to any pair of currencies. Leva and euro are simply the pair most Bulgarian shops need during the switch from leva to euro.

#Why shops need both currencies on the product page

PrestaShop can already hold several currencies, and a visitor can pick one from the currency selector. The catch is that the selector shows one currency at a time. A shopper who browses in leva sees leva; switch to euro and the leva amount disappears. When customers expect to see both figures side by side, switching is no answer, because they want to compare the two at a glance on the same product card.

So the task is narrow: keep the shop's pricing, checkout and base currency exactly as they are, and add a second line under the main price that shows the same amount in the other currency.

#Why a second price field is a bad idea

The first idea many teams have is to add a custom field to each product, type in the euro price by hand, and print it in the template. It works on day one. After that the costs pile up:

• Two prices to maintain. Every price change, sale or bulk import now has to update two fields. Sooner or later one of them is forgotten, and the product page shows two amounts that do not match.
• No link to the exchange rate. A typed-in number ignores the rate stored in the shop. If the rate changes, hundreds of products are wrong until someone edits them one by one.
• Combinations and specific prices. Products with combinations, price impacts, customer group discounts or catalog price rules produce a final price that PrestaShop calculates at runtime. A static field cannot follow that calculation.
• Imports and integrations. If prices come from an ERP, a supplier feed or a CSV import, the extra field needs its own mapping and its own checks.

The rule that avoids all of this: store one price and derive the other. The second currency should always be a calculation, never a second source of truth.

#Use the conversion rates the shop already stores

Every currency you add to PrestaShop has a conversion rate relative to the shop's default currency, kept in the conversion_rate value of that currency. PrestaShop uses the same rate when a visitor switches currency, so building on it keeps the second line consistent with what the shop shows everywhere else.

Before you rely on it, check three things in the back office:

1. Both currencies are active. An inactive currency should not appear anywhere on the storefront, including in a second price line.
2. The rate is correct. Confirm the rate against the official figure you are required or choose to use. If you update rates automatically, know where the feed comes from and when it runs.
3. The default currency is the one you price in. The conversion always starts from the price as the shop calculates it for the visitor, including tax, discounts and the selected combination.

Rounding deserves a word. The converted figure is a display value. Decide how many decimals to show and make sure the second line uses the currency's own format and sign, so "лв." and "€" appear where shoppers expect them.

#Where the second price goes: theme hooks

You have three realistic ways to put the extra line on the page.

Approach	How it works	Main risk
Edit the theme template	Change product-prices.tpl or a child theme to print the converted amount	Theme updates overwrite or conflict with the change
Convert in the browser	JavaScript reads the price and multiplies it by a hard-coded rate	The rate lives in code, and the line can flicker or break when the price updates
Module on a hook	A module registers on a price hook and renders its own template	Depends on the theme calling the hook, which standard themes do

The hook approach is the cleanest. PrestaShop themes call displayProductPriceBlock at several points in the price block, and pass a type that tells modules where they are, for example before_price, old_price or after_price. A module that listens for after_price can add its lines directly under the main price, while the theme keeps its own markup and styling. When you change or update the theme, the module keeps working as long as the new theme still calls the hook.

If you build this yourself, keep the module small: read the product's final price as the theme shows it, loop over the other active currencies, convert with each currency's rate, and format each amount with that currency's settings. Skip the currency the visitor is already browsing in, because showing the same amount twice is noise.

#Dual Price: a free module that does this

PN Scripts publishes Dual Price, a free PrestaShop module under the MIT license, with the source on GitHub. It follows the approach described above:

• It runs on PrestaShop 8 and 9, on PHP 8.1 or newer.
• It attaches to displayProductPriceBlock with after_price, so the converted prices appear under the main price and the theme keeps its own price block.
• Amounts come from PrestaShop's conversion_rate, so there is no second price field to maintain.
• It lists every other active currency and leaves out the currency the visitor is already browsing in, as well as any currency that is switched off.
• It is a display module. It does not change prices, the base currency or checkout.

The shop needs at least two active currencies. You clone the repository, copy the module into the shop's modules folder and install it from the back office. For shops on OpenCart, there is a separate Dual Price for OpenCart, an OCMOD extension for OpenCart 3 that lists the other active currencies under the main price using OpenCart's own rates.

If your theme is heavily customized, the same principles apply to a module you write or adapt yourself.

#What to check before going live

• Open products with combinations and switch between them. The second line should follow the selected combination.
• Check a product on sale and a product with a customer group discount, logged in and logged out.
• Switch the storefront currency and confirm the visitor's own currency is not repeated in the second line.
• Deactivate a test currency and confirm it disappears from the product page.
• Check the page on mobile, where the price block has the least room.
• Clear the PrestaShop cache after installing or changing the module, then check again.
• Confirm with whoever handles your compliance which amounts, rate and wording the shop has to show. This article covers the technical side only.

If prices also flow to an ERP or a marketplace, keep one stored price there too. Our guide to what a reliable API integration needs covers the checks that keep those systems in step.

#How PN Scripts can help

Dual Price is free to use and change under MIT, and PN Scripts can adapt it for a specific theme or catalog setup. The Dual Price page lists the requirements, the install steps and answers to common questions.