Many Magento 2 stores sell products where the price depends on the customer's required size or measurements. Blinds, curtains, tarps, glass, carpets, wallpaper, banners, fabric, and other made-to-measure products often cannot be sold with a single fixed price.
For these products, the store needs to determine the price based on measurements such as width, height, or length. Depending on the business, the price may come from a mathematical formula, a predefined pricing table, a CSV file, or a combination of product options and measurements.
This guide explains the different ways to implement size-based pricing in Magento 2, when each approach makes sense, and what we have seen in real ecommerce projects involving tarps, blinds, curtains, and glass.
What Is Size-Based Pricing in Magento 2?
Size-based pricing means that the final product price changes according to the dimensions entered or selected by the customer.
A simple example is:
Width × Height × Price per Unit = Product Price
For example, if a product is 10 feet wide, 20 feet long, and costs $2 per square foot:
10 × 20 × $2 = $400
That is only the simplest scenario. Real ecommerce pricing can involve several additional factors.
- Width
- Height
- Length
- Area
- Material
- Product type
- Finish
- Color
- Additional product options
- Minimum and maximum measurements
- Predefined price tables
The right Magento 2 implementation depends on how the business actually calculates and maintains its prices.
When Do You Need Size-Based Pricing?
Size-based pricing is particularly useful when a product is manufactured, cut, configured, or priced according to the customer's measurements.
Common examples include:
- Blinds and shades
- Curtains
- Tarps and covers
- Glass
- Carpets and floor coverings
- Wallpaper
- Fabric
- Banners and signage
- Canvas and artwork
- Custom furniture
- Sheets and other cut-to-size products
In these businesses, the customer may not know the final price until they provide the required measurements and product configuration.
How Magento 2 Handles Product Pricing by Default
Magento 2 provides standard pricing features for common ecommerce requirements, including product prices, configurable products, custom options, tier pricing, and catalog price rules.
These features can work well when the number of product configurations is limited.
The challenge becomes greater when a product has hundreds or thousands of possible size combinations.
For example, a blinds store may offer many width and height combinations. Creating separate product configurations for every possible size can make the catalog difficult to maintain.
A better approach can be to let the customer enter the required measurements and have Magento determine the appropriate price from a formula or predefined pricing data.
Ways to Implement Size-Based Pricing in Magento 2
1. Custom Magento 2 Development
Custom development gives you the greatest flexibility when the pricing rules are specific to the business.
A custom solution can be designed around requirements such as:
- Complex pricing rules
- Multiple dependent options
- Custom validation
- Minimum and maximum dimensions
- Product-specific pricing rules
- Custom frontend behavior
- Third-party integrations
- Business-specific workflows
The disadvantage is that the pricing logic may require developer involvement whenever the business needs to make significant changes.
If the business already has a clear pricing structure that can be handled by an existing solution, using an extension and adding targeted customization can often be a more practical approach.
2. Magento Product Options
Magento product options can work for relatively simple pricing requirements.
For example, a product could have:
- Small: +$10
- Medium: +$20
- Large: +$30
This approach becomes harder to manage when there are hundreds or thousands of possible measurement combinations.
3. Formula-Based Pricing
Formula-based pricing is useful when the final price can be calculated using a mathematical rule.
For example:
Width × Height × Base Price
A more complex formula could use several measurements, product attributes, or option values.
MageArray's Formula Based Custom Pricing extension for Magento 2 is designed for products where pricing depends on mathematical formulas. The extension supports formulas using measurements such as width, height, length, and radius, as well as product options and attributes. It currently supports simple products.
This approach works well when the business can express its pricing rules as a repeatable calculation rather than maintaining a separate price for every possible size.
4. Matrix Pricing
Matrix pricing is useful when the business has predefined prices for combinations of measurements.
For example:
- 5 ft × 10 ft = $120
- 5 ft × 15 ft = $160
- 10 ft × 10 ft = $200
- 10 ft × 15 ft = $280
In this situation, a simple formula may not reproduce the actual pricing used by the business.
Instead, the system can look up the customer's measurements in a predefined pricing matrix.
5. CSV-Based Pricing
CSV pricing is useful when a business already maintains its pricing information in spreadsheets or CSV files.
For example, the business may maintain prices for different width and height combinations in a CSV file and update that file whenever its pricing changes.
MageArray's CSV Table Matrix Pricing extension is designed for Magento 2 products where prices vary according to size. It supports measurement-based pricing, product-level and global pricing CSV configuration, custom options, and measurement units such as millimeters, centimeters, inches, feet, and meters. The extension currently supports simple products.
The extension is particularly suited to products such as blinds, floor coverings, wallpaper, banners, artwork, sheeting, tarps, windows, and other products where price varies according to size.
Example: Width × Height Pricing
Consider a product where the price depends directly on width and height.
The customer enters:
- Width: 10 ft
- Height: 20 ft
- Price per square foot: $2.50
The calculation is:
10 × 20 × $2.50 = $500
If the customer selects additional options, those options can also affect the final price depending on the pricing setup.
For example:
- Base calculated price: $500
- Additional finish: +$25
- Additional material option: +$50
Final price: $575
This type of requirement is generally a good candidate for formula-based pricing.
Example: Width × Height × Price Per Unit
Blinds, curtains, glass, carpets, and similar products may use area-based pricing.
For example:
- Width: 5 ft
- Height: 6 ft
- Price: $15 per square foot
The calculation would be:
5 × 6 × $15 = $450
Additional selections may then affect the final price depending on the business rules.
However, not every business uses a mathematical calculation. Some businesses maintain predefined prices for specific size combinations. In those cases, CSV or matrix pricing can be more appropriate.
Example: Matrix Pricing
Suppose a blinds business maintains pricing according to width and height ranges:
- 20-30 inch width and 30-40 inch height: $150
- 20-30 inch width and 41-50 inch height: $175
- 31-40 inch width and 30-40 inch height: $185
- 31-40 inch width and 41-50 inch height: $220
The system needs to identify the appropriate price from the pricing data rather than simply multiplying the measurements by one fixed rate.
This is a typical use case for matrix or CSV-based pricing.
Real-World Magento 2 Pricing Scenarios
Real ecommerce projects often demonstrate why there is no single pricing model that works for every business.
Tarps and Custom Covers
For one tarp business, pricing was maintained using CSV data. The business had predefined prices based on product measurements and needed additional functionality around the pricing workflow.
The CSV pricing approach was used as the foundation, while additional customization was implemented for the client's specific requirements.
This allowed the store to follow the business's existing pricing process instead of requiring the merchant to manually create a large number of individual product configurations.
Blinds and Curtains
Another project involved a blinds and curtains business where pricing was based on customer measurements.
The business used CSV-based pricing because the price depended on the selected dimensions and configuration.
There was also a requirement for the product image to change based on the selected options.
For example, selecting a particular combination of blind type, fabric, or configuration could display a corresponding product image.
MageArray's Blinds & Curtains Solution includes measurement-based CSV pricing and custom options with images. It is designed specifically for businesses selling blinds and curtains online.
For this type of project, the pricing system and frontend product configuration need to work together. Additional customization can be used when the standard functionality does not cover the complete business requirement.
Glass Products With Different Pricing Models
Another glass business had multiple pricing requirements within the same store.
Some products used CSV-based pricing, while other products used formula-based pricing.
This is an important consideration when planning a Magento pricing solution. A store does not necessarily have one pricing model for its entire catalog.
One product may need predefined pricing data, while another may be better represented by a formula such as width × height × price per unit.
Additional business-specific requirements can then be handled through Magento customization.
CSV Pricing vs. Formula Pricing
The right approach depends on how the business creates and maintains its prices.
- Formula pricing: Best when the price follows a consistent mathematical calculation.
- CSV pricing: Best when the business has predefined prices stored in a table.
- Matrix pricing: Useful when the price depends on combinations of measurements.
- Custom development: Appropriate when the business has requirements that go beyond the available pricing functionality.
In some projects, the best solution is a combination of these approaches. Different products can use different pricing methods according to their individual business rules.
How to Choose the Right Approach
Start With the Existing Pricing Process
Before selecting a Magento extension or starting custom development, understand how the business calculates prices today.
Does the pricing team use:
- A spreadsheet?
- A mathematical formula?
- A price matrix?
- A combination of options and measurements?
- Different rules for different products?
The Magento implementation should reproduce the actual business pricing process as closely as practical.
Consider How Often Prices Change
If prices are maintained in a spreadsheet and updated frequently, CSV-based pricing can make administration easier than hardcoding a large pricing table into custom code.
Consider the Number of Combinations
A small number of fixed sizes can often be handled with standard Magento functionality.
When the number of combinations becomes very large, a calculation or pricing-table approach can reduce catalog complexity.
Look Beyond the Price
Pricing may only be one part of the product configuration.
The business may also need:
- Option-dependent images
- Measurement validation
- Custom error messages
- Different options for different products
- Additional option pricing
- Custom frontend behavior
- Integration with other Magento functionality
These requirements may require customization even when the core pricing calculation is already handled by an extension.
If the requirement goes beyond a standard extension configuration, MageArray's Magento 2 custom extension development and customization services can be considered for the additional functionality.
Common Problems With Size-Based Pricing
Too Many Product Combinations
Creating separate products or configurations for every possible size can make the catalog difficult to manage.
Manual Price Maintenance
Hardcoding hundreds or thousands of prices makes updates time-consuming and can increase the risk of pricing errors.
Unsupported Measurements
The store should validate the measurements customers enter and clearly communicate the acceptable values.
Dependent Options
Some product options may depend on other selections. For example, a particular material or finish may only be available for certain product configurations.
Pricing Is Correct but the Product Experience Is Not
A pricing system may calculate the correct amount while the product image, available options, or other product information does not change with the customer's selections.
For made-to-measure products, the complete configuration experience matters just as much as the price calculation.
Frequently Asked Questions
Can Magento 2 calculate product prices based on width and height?
Yes. Magento 2 can be extended to calculate or retrieve prices based on customer-entered dimensions. The best implementation depends on whether the pricing is formula-based or stored as predefined pricing data.
Can I use CSV data for Magento 2 product pricing?
Yes. CSV-based pricing can be used when a business maintains predefined pricing data for different measurements or product configurations.
Is formula pricing better than CSV pricing?
Neither approach is universally better. Formula pricing is a good fit when the price follows a mathematical rule. CSV pricing is a better fit when the business has predefined prices for many combinations.
Can different Magento 2 products use different pricing methods?
Yes. A store can have different pricing requirements across its catalog. For example, one product may use CSV pricing while another uses formula-based pricing, depending on the business rules.
Can product images change when customers select options?
Yes. This can be implemented through Magento customization when the standard product configuration behavior does not meet the business requirement.
Do I need custom Magento 2 development?
Not necessarily. A pricing extension may handle the main pricing requirement. Custom development becomes useful when the business needs additional rules, frontend behavior, integrations, or workflows that are not covered by the standard pricing functionality.
Conclusion
Adding size-based pricing to Magento 2 is not simply a matter of changing the product price when a customer enters a width or height.
The right solution depends on how the business actually prices its products.
A tarp business may need CSV-based pricing. A blinds business may need CSV pricing combined with option-dependent image changes. A glass business may need CSV pricing for some products and formula pricing for others.
For simple mathematical calculations, formula pricing can be a practical approach. For large predefined price tables, CSV or matrix pricing can make pricing data easier to manage. When additional business rules are involved, custom Magento development can connect the pricing functionality with the rest of the store.
The goal should be to reproduce the merchant's real pricing process in Magento while keeping product management manageable and the customer buying experience clear.
If your Magento 2 store sells products priced by width, height, length, or other measurements, start by mapping your existing pricing rules. From there, you can determine whether CSV pricing, formula pricing, matrix pricing, or a customized solution is the right fit.
Have a Magento 2 product with complex size-based pricing? Contact MageArray to discuss your pricing requirements and find the right implementation approach.
