Checkout & Sales

Industry data suggests that simplifying the checkout process can reduce abandonment by 10-35%, but your actual results will depend on your current checkout friction, your audience, and your product type. If your current checkout has 5 steps and requires account creation, switching to a one-page checkout will likely show a significant improvement. If you are already running a clean two-step checkout, the gains will be more modest.

Learn more in our checkout optimization guide.

Yes. Checkout Revolution works with any payment module that uses standard PrestaShop payment hooks. This includes Stripe, PayPal, Mollie, Adyen, and virtually every major payment provider. The checkout module handles the layout and flow — payment processing is handled by your payment module as usual. If a specific payment module does something unusual (like redirecting mid-checkout), let us know and we will check compatibility.

Read more about payment integration in our checkout guide.

Yes, Checkout Revolution supports adding custom fields to the checkout form — things like delivery instructions, company registration numbers, or custom notes. You configure them in the module's back office. However, custom fields that require complex validation logic or that need to interact with external systems may require custom development beyond what the module offers out of the box.

See our checkout customization guide for more tips.

Yes, Checkout Revolution fully supports guest checkout. You can configure whether to require account creation, offer it as optional, or allow pure guest checkout. Guest checkout typically increases conversion rates because many first-time buyers do not want to create an account just to make a purchase.

Learn why guest checkout matters in our one-page checkout guide.

Yes, our Digital Revolution module handles digital product delivery — secure downloads, license key distribution, download limits, and expiration dates. It works alongside standard PrestaShop products, so you can sell both physical and digital products in the same store.

Checkout Revolution supports B2B-relevant features like requiring a VAT number, displaying net prices, and custom company fields. However, it does not have a purchase order workflow (approve → submit → invoice). For full B2B purchase order handling, you would need a dedicated B2B module or custom development.

For VAT handling, check out our Automatic EU VAT Checker module.

The checkout layout is the same for all customers, but you can show or hide specific fields based on customer groups. For example, you can require a company VAT number only for B2B customers, or skip the delivery step for digital-only orders. Full per-group layout customisation would require custom development.

Explore all checkout features on the Checkout Revolution product page.

It might, depending on the cause. If the slowness is caused by your current checkout module loading unnecessary JavaScript or making too many AJAX calls, switching to Checkout Revolution will likely improve things — our module is optimised for performance. However, if the slowness is server-side (slow database, slow hosting), a checkout module change will not fix that. Use your browser's developer tools (Network tab) to identify what exactly is slow.

See our checkout optimization guide for performance tips.

Our sales and promotions modules let you add countdown timers to product pages and category listings to create urgency. You set the end date of the promotion, and the timer counts down in real time. This is a legitimate marketing technique when used with real promotions — do not use it with fake deadlines that reset, as this destroys customer trust and may violate consumer protection laws in the EU.

See also: Sales Revolution — advanced promotions with countdown timers

This depends on the specific module. Some of our promotion modules allow scheduling start and end dates. PrestaShop itself also supports catalog price rules with date ranges. For complex promotion scheduling (flash sales, time-limited discount codes), you may need a combination of PrestaShop's built-in features and a module. Check the specific product page or ask us about your scenario.

Read more: Black Friday Preparation Checklist for Your Store

Address auto-complete (using Google Places API or similar) is not built into Checkout Revolution. This is a separate functionality that requires a Google Maps API key with billing configured. We can point you in the right direction for a module that adds this feature, which would work alongside our checkout module.

Learn more about checkout features in our complete checkout guide.

Yes. The module's appearance is controlled by CSS and Smarty templates that you can override in your theme. For basic colour and spacing changes, you can use the module's configuration options. For deeper customisation, create a template override in your theme folder at /themes/your-theme/modules/mprcheckoutrevolution/. If you need help with specific design changes, contact us.

For more customization ideas, read our checkout process guide.

PrestaShop handles this natively — carts are saved for logged-in customers and for guests via cookies. Our checkout module does not override this behaviour. If a customer adds items to cart and comes back later (within the cookie lifetime), their cart will still be there. For more advanced abandoned cart recovery (emails, reminders), you would need a dedicated abandoned cart module.

Read our checkout optimization guide for abandonment recovery tips.

Checkout Revolution does not have built-in A/B testing. To A/B test checkout layouts, you would need an external tool like Google Optimize (discontinued, but alternatives exist) or a dedicated A/B testing module. You could also test sequentially — run one layout for a period, switch to another, and compare conversion rates. True A/B testing with simultaneous random assignment requires dedicated tooling.

Learn more about conversion optimization in our checkout optimization guide.

If the customer is logged in and has saved addresses and a previous order, the checkout process is significantly faster — their details are pre-filled. However, true "one-click" ordering (like Amazon's patent) requires storing payment methods, which Checkout Revolution does not do for security and PCI compliance reasons. The payment step always requires the customer to confirm or enter payment details.

For faster checkout, explore our Express Checkout guide.

The module validates that required fields are filled in and that the format is correct (e.g., valid email, valid postal code format). However, it does not verify that an address physically exists. For actual address verification (checking against postal databases), you would need a dedicated address validation service integrated via a separate module or custom code.

Explore all checkout features on the Checkout Revolution product page.

Checkout Revolution displays the shipping options provided by your carrier modules, including any delivery time information they provide. If your carrier module includes estimated delivery dates, they will appear. The checkout module itself does not calculate delivery dates — that logic belongs to the shipping/carrier modules.

Learn more in our one-page checkout guide.

Two Discount Engines, Two Different Philosophies

PrestaShop offers two fundamentally different mechanisms for applying discounts: specific prices and cart rules. They look similar from a customer's perspective because both reduce the amount paid, but they work in completely different ways under the hood, target different stages of the purchase process, and have distinct performance characteristics. Choosing the wrong one for your use case does not just create confusion. It can cause incorrect pricing, slow down your store, or make your discount strategy impossible to manage at scale.

Specific prices modify the displayed price of a product before it enters the cart. They are attached directly to products and are evaluated during catalog browsing. Cart rules, on the other hand, apply discounts after products are in the cart, usually requiring a voucher code or meeting certain conditions. Understanding this distinction is the foundation of choosing the right tool for every discount scenario.

How Specific Prices Work Internally

Specific prices are stored in the ps_specific_price table in your PrestaShop database. Each row in this table represents a single price rule that can override the base price of a product under certain conditions. The table structure includes columns for the product ID, combination (attribute) ID, shop ID, currency, country, group, customer, price override, reduction amount, reduction type (amount or percentage), date range, and minimum quantity.

When PrestaShop calculates the price of a product, it queries this table to find all specific price rules that match the current context: the product being viewed, the customer's group, the shop, the currency, the country, and the current date. If multiple rules match, PrestaShop uses a priority system to determine which one applies. This priority is configured in the back office under Catalog > Discounts > Specific Prices > Priorities.

The Priority System

The priority system determines which specific price rule wins when multiple rules match. The default priority order is: shop, currency, country, group. You can reorder these four criteria in the back office. PrestaShop evaluates rules from most specific to least specific. A rule targeting a specific customer always beats a rule targeting a customer group. A rule targeting a specific combination always beats a rule targeting the product as a whole.

This priority system is powerful but can be confusing when you have many overlapping rules. For example, if you have a rule giving 10% off to the Wholesale group and another rule giving 15% off for orders of 10 or more units, PrestaShop must decide which one applies when a wholesale customer orders 10 units. The priority configuration determines the answer.

Quantity Discounts

One of the most useful features of specific prices is quantity-based pricing. By setting the from_quantity field, you can create tiered pricing: buy 1 at full price, buy 5 at 10% off, buy 20 at 20% off. These quantity breaks are displayed on the product page in a pricing table, which serves as a strong incentive for customers to order larger quantities.

Quantity discounts through specific prices are evaluated per product. If a customer adds 5 units of Product A and 5 units of Product B, only the per-product quantity counts toward the threshold. If you need cross-product quantity discounts (buy any 10 items for a discount), you need cart rules instead.

Customer Group Pricing

Specific prices are the correct tool for customer group pricing. If you have a Wholesale group that should see 30% lower prices on all products, you create specific price rules for that group. These prices appear on the catalog pages and product pages when a wholesale customer is logged in, which is the expected behavior. The customer sees their price, not the retail price with a discount applied at checkout.

Group pricing through specific prices also affects price display in category listings, search results, and comparison features. This is important for B2B stores where wholesale customers need to see their real prices while browsing, not just at checkout.

How Cart Rules Work Internally

Cart rules are stored across several tables, with ps_cart_rule as the main table. Related tables include ps_cart_rule_lang for multilingual names and descriptions, ps_cart_rule_country for country restrictions, ps_cart_rule_group for group restrictions, ps_cart_rule_carrier for carrier restrictions, ps_cart_rule_combination for rules about which cart rules can be combined, and ps_cart_rule_product_rule plus ps_cart_rule_product_rule_group and ps_cart_rule_product_rule_value for product-level conditions.

Cart rules are evaluated when the cart contents change or when a voucher code is entered. They operate on the cart total or on specific products within the cart, and they can provide three types of reductions: a percentage off the order, a fixed amount off the order, or free shipping.

Condition System

Cart rules have an extensive condition system that goes far beyond what specific prices can do. A single cart rule can require all of the following conditions to be met simultaneously:

A minimum order total (before or after tax). A specific date range. A limited number of total uses. A limited number of uses per customer. A specific customer. Restriction to certain customer groups. Restriction to certain countries. Restriction to certain carriers. A requirement that certain products, categories, manufacturers, or suppliers are in the cart. A requirement that other specific cart rules are or are not present.

The product restriction conditions are particularly powerful. You can create rules like: 10% off when the cart contains at least one product from Category X and at least one product from Manufacturer Y. This kind of cross-product, cross-category logic is impossible with specific prices.

Voucher Codes

Cart rules can optionally have a voucher code. When a code is assigned, the rule only activates when the customer enters that code. When no code is assigned, the rule applies automatically if all conditions are met. Automatic cart rules appear in the cart without customer action, which is useful for promotions like free shipping on orders over a certain amount.

Combining and Stacking Cart Rules

Cart rules have a compatibility system that controls which rules can be used together. Each cart rule has a setting for whether it can be combined with other cart rules. If a rule is marked as non-combinable, it cannot be used alongside any other cart rule. If it is combinable, you can further specify which specific other cart rules it is compatible with.

This gives you precise control over discount stacking. For example, you might allow a 10% newsletter signup discount to combine with a free shipping promotion, but prevent it from combining with a 20% seasonal sale voucher.

Combining Specific Prices and Cart Rules

Specific prices and cart rules can operate simultaneously on the same order. A product can have a specific price (say, 20% off for the Wholesale group) and a cart rule can apply an additional discount on top (say, another 5% off with a voucher code). PrestaShop calculates the specific price first, reducing the product price, and then applies the cart rule to the already-reduced price.

This stacking behavior is intentional and usually desirable, but it can lead to deeper discounts than intended if not carefully managed. A product with a 30% specific price discount plus a 20% cart rule discount does not give 50% off. It gives 30% off first, then 20% off the reduced price, resulting in a 44% total discount. But this can still exceed your margin if you are not calculating carefully.

To prevent specific prices and cart rules from stacking, you have limited options. Cart rules do not have a condition that checks for specific prices, and specific prices do not know about cart rules. The most practical approach is to exclude products that have active specific prices from the cart rule's product restrictions, though this requires manual maintenance.

Date Ranges and Scheduling

Both specific prices and cart rules support date ranges, but they handle them differently.

Specific prices have from and to datetime fields. When both are set to 0000-00-00 00:00:00, the rule has no time limit. When set to actual dates, the rule only applies within that window. This is perfect for timed promotions on individual products.

Cart rules also have date_from and date_to fields with the same behavior. The advantage of cart rules for timed promotions is that a single cart rule can apply to many products through its condition system, whereas you would need individual specific price entries for each product.

For flash sales with many products, cart rules are more manageable. For permanent pricing adjustments or long-running per-product discounts, specific prices are more appropriate.

Performance Considerations

Performance differences between the two systems become significant as your store scales.

Specific Price Performance

Every time PrestaShop displays a product price, it queries the ps_specific_price table. On a category page showing 20 products, that means 20 separate lookups. On a search results page, even more. The query filters by product ID, shop, currency, country, group, customer, date, and quantity, so proper indexing is critical.

PrestaShop includes indexes on the most commonly queried columns, but stores with tens of thousands of specific price entries can still experience slowdowns, especially when combined with multiple shops, currencies, and customer groups. The number of rows in ps_specific_price directly impacts catalog browsing performance.

A common performance problem occurs when store owners create specific prices in bulk using imports but never clean up expired entries. Over time, the table fills with thousands of expired rules that PrestaShop still queries against. Periodically deleting expired specific prices can noticeably improve catalog page load times.

Cart Rule Performance

Cart rules are evaluated less frequently than specific prices because they only matter when the cart is active. However, the evaluation can be more complex because of the rich condition system. A cart rule with product restrictions requires joining across multiple tables to check whether the cart contents match the conditions.

Stores with hundreds of active automatic cart rules (rules without codes that apply automatically) can experience slow cart page loads because PrestaShop must evaluate every automatic rule to determine which ones apply. Voucher-based cart rules are cheaper because they are only evaluated when a code is entered.

The ps_cart_rule table itself is usually small compared to ps_specific_price, but the condition tables can grow large if you use complex product restrictions across many rules.

Use Case Matrix

Knowing which tool to use for each scenario eliminates guesswork and prevents implementation mistakes.

Use Specific Prices When

You need to change the displayed price on the product page and in catalog listings. This is the primary use case. Specific prices affect how prices appear throughout the catalog, which matters for customer perception and for Google Shopping feeds.

You need quantity-based pricing tiers. The built-in quantity discount display on the product page is driven by specific prices and cannot be replicated with cart rules.

You need permanent or long-running price adjustments for customer groups. B2B pricing, VIP customer pricing, and employee pricing are all best handled through specific prices.

You need to set a fixed price for a product under certain conditions. Specific prices can override the base price entirely (not just apply a reduction), which is useful when the adjusted price cannot be expressed as a percentage of the base price.

You need per-combination pricing. Specific prices can target individual product combinations (attributes), allowing you to set different prices for different sizes, colors, or other variants.

Use Cart Rules When

You need voucher codes. Specific prices cannot be activated by a code. Any promotion that requires a customer to enter a code must use a cart rule.

You need minimum order value conditions. Cart rules can require a minimum cart total before the discount applies. Specific prices have no concept of cart total.

You need cross-product conditions. If the discount should apply only when certain combinations of products are in the cart, only cart rules can express this logic.

You need free shipping as the discount. Cart rules can offer free shipping. Specific prices cannot affect shipping costs.

You need to limit total usage. Cart rules track how many times they have been used in total and per customer. Specific prices have no usage limits.

You need carrier or country restrictions at the cart level. While specific prices can target countries, they do so for pricing purposes. Cart rules can restrict discounts based on the selected carrier, which specific prices cannot.

Use Both Together When

You have base group pricing (specific prices for the Wholesale group) and also run promotional campaigns (cart rules for seasonal sales or voucher codes). The group pricing establishes the baseline, and the cart rules provide additional incentives.

You sell products with quantity tiers (specific prices) but also want to offer free shipping above a threshold (cart rule). These two discount types do not conflict because they affect different aspects of the order.

Database Management and Cleanup

Both discount mechanisms create database entries that accumulate over time. Active management prevents performance degradation and data confusion.

Cleaning Up Specific Prices

Expired specific prices serve no purpose and slow down price calculations. You can identify and remove them with a SQL query targeting entries where the to date is in the past and not zero. Before deleting, export the data as a backup.

Also look for duplicate or conflicting specific prices. When importing products or using bulk editing tools, it is easy to create multiple specific price rules for the same product, group, and date range. PrestaShop will use the priority system to pick one, but the extras waste database space and query time.

Cleaning Up Cart Rules

Expired cart rules are less of a performance issue because they are filtered by date during evaluation. However, they clutter the back office and make management harder. Periodically archive or delete cart rules whose end dates have passed.

One-time voucher codes that have been fully used can also be cleaned up. Check the quantity and quantity_per_user fields against actual usage before deleting.

Import and Export Considerations

Specific prices can be managed through PrestaShop's product import CSV. The import file supports columns for reduction amount, reduction type, group, date range, and quantity. This makes it practical to set up thousands of specific prices programmatically, which is essential for B2B stores with complex pricing matrices.

Cart rules do not have a built-in import mechanism. Creating cart rules in bulk requires either a module, direct database manipulation, or the PrestaShop web service API. For stores that need to generate many unique voucher codes (for influencer campaigns, for example), a module that generates cart rules programmatically is usually necessary.

How Discounts Appear in the Front Office

The way discounts are presented to customers differs significantly between the two methods, and this presentation affects conversion rates.

Specific prices show the original price crossed out and the new price next to it on the product page and in catalog listings. The discount percentage or amount badge appears on the product thumbnail. This visual treatment is handled by the theme and is highly visible. Customers see the discount before adding the product to the cart, which increases the likelihood of adding it.

Cart rules do not change the displayed product price. The product appears at full price in the catalog and on the product page. The discount only becomes visible in the cart or during checkout. For voucher-based rules, the customer must actively enter the code to see any reduction. For automatic rules, the discount line appears in the cart summary.

This presentation difference matters for marketing. If you want a product to look like it is on sale in the catalog, you need specific prices. If you want to surprise and delight customers with a discount at checkout, or if the discount depends on the overall cart composition, cart rules are appropriate.

Tax Handling

Specific prices apply their reduction to the base price before tax calculation. The reduction is specified as either a percentage or a fixed amount, and the reduction_tax field determines whether the fixed amount is before or after tax. This is straightforward because each product has a known tax rate.

Cart rules that apply a fixed amount discount to the cart total must specify whether the amount is tax-included or tax-excluded. When a cart contains products with different tax rates, this distinction affects which products absorb the discount and can lead to rounding differences. PrestaShop distributes the discount proportionally across cart items, but the calculation can produce unexpected results when tax rates vary.

For simplicity and predictability in multi-tax-rate stores, percentage-based discounts (both specific prices and cart rules) are more reliable than fixed-amount discounts.

Multistore Considerations

In a PrestaShop multistore setup, specific prices can be assigned to specific shops or shared across all shops. Each specific price entry has a id_shop field. A value of 0 means the rule applies to all shops. This allows you to have different pricing for different shops, which is common in multistore setups that serve different markets or customer segments.

Cart rules also have a shop restriction through the ps_cart_rule_shop table. You can create a cart rule that is only valid in certain shops. This is useful for store-specific promotions or region-specific voucher campaigns.

Third-Party Module Interactions

Many third-party modules interact with PrestaShop's pricing system, and their behavior depends on whether you use specific prices or cart rules.

Google Shopping feed modules typically read specific prices to determine the sale price submitted to Google Merchant Center. If you run promotions through cart rules instead, the Google Shopping feed will show the full price because it cannot account for cart-level discounts. This means your product listings in Google Shopping will not show the promotional price, potentially reducing click-through rates.

Price comparison modules and marketplace integrations have the same limitation. They read product prices, which include specific prices, but cannot predict cart rule discounts. If you want your discounted prices to appear on external channels, specific prices are the way to go.

Analytics modules that track average order value and discount impact may or may not capture cart rule discounts depending on their implementation. Specific price discounts are reflected in the product price at the order level, making them easier to track.

Practical Guidelines for Store Owners

Start with these principles and adjust based on your store's specific needs:

Use specific prices for anything that should change how a product appears in the catalog. Sale prices, group prices, quantity breaks, and time-limited product promotions all belong here.

Use cart rules for anything that depends on the overall order or requires customer action. Voucher codes, minimum order thresholds, cross-product promotions, and free shipping offers all belong here.

Avoid creating both a specific price and a cart rule that target the same products in the same time frame unless you have explicitly calculated the combined discount and confirmed it does not erode your margins below acceptable levels.

Clean up expired rules quarterly. Set a calendar reminder to review and delete expired specific prices and cart rules. Your store's performance will thank you.

Document your discount strategy. When multiple people manage your store, a document explaining which discount method is used for which purpose prevents conflicting or duplicate rules. This is especially important during peak season when multiple promotions may be running simultaneously.

For more details, read our guides: Running a Sale in PrestaShop: Cart Rules, Specific Prices and Discount Strategies and Scheduled Discounts: Setting Up Promotions That Start and Stop Automatically.