#39655: Preserve decimal precision for percentage-based custom option prices

[sydor-dev]

Description (*)

This PR fixes precision loss for percentage-based custom option prices when editing products in admin panel.

Problem:
When custom option prices with price_type="percent" are set via REST API with high precision (e.g., 2.334%), the values are correctly stored in the database with up to 6 decimal places. However, when the product is
opened in admin panel and saved (even without changes), these values are truncated to 2 decimal places, causing:

• Loss of calculation accuracy for percentage-based pricing
• Data inconsistency between API-created and admin-edited products
• Financial impact on merchants using precise percentage discounts

Solution:

• Introduced PERCENTAGE_PRECISION constant (value: 4) in PriceCurrencyInterface to support higher precision for percentage prices
• Updated AbstractModifier::formatPrice() to accept precision parameter with automatic trailing zero removal while preserving minimum 2 decimal places
• Modified CustomOptions::formatPriceByPath() to detect price_type and apply appropriate precision:
  • Percentage prices: up to 4 decimal places (e.g., 2.3346%)
  • Fixed prices: standard 2 decimal places (e.g., $15.00)

Technical Details:

• Database already supports decimal(20,6) for custom option prices
• Changes are backwards compatible - fixed prices continue to display with 2 decimals

Related Pull Requests

Fixed Issues (if relevant)

1. Fixes Editing A Product in the backend Removes extra decimal places from product option pricing #39655

Manual testing scenarios (*)

Scenario: Percentage-based custom option (API → Admin → Save)

1. Create a product with custom option via REST API:

   POST /rest/V1/products
   {
     "product": {
       "sku": "test-product",
       "name": "Test Product",
       "price": 100.00,
       "type_id": "simple",
       "attribute_set_id": 4,
       "options": [{
         "title": "Size Options",
         "type": "radio",
         "is_require": false,
         "values": [{
           "title": "Premium",
           "price": 2.334,
           "price_type": "percent",
           "sku": "premium"
         }]
       }]
     }
   }

2. Verify in database: SELECT price, price_type FROM catalog_product_option_type_price shows 2.334000
3. Open product in admin panel (Catalog > Products > Edit)
4. Navigate to "Customizable Options" section
5. Expected: Price field displays 2.3340 (not 2.33)
6. Make any trivial change (e.g., change product description)
7. Click "Save"
8. Verify in database: price still shows 2.334000 (not truncated to 2.330000)

Questions or comments

After analyzing the use case, 4 decimal places provide a balanced trade-off between calculation accuracy and admin UI readability. For percentage-based pricing, this level of precision is sufficient even for high-value products. For example, for a product priced at 150,000, a percentage option of 2.3346% results in a price adjustment of 3,501.90, while rounding the percentage to 2.33% would produce 3,495.00—a noticeable difference of 6.90 per item. This demonstrates that precision beyond two decimals is financially significant, while four decimals already capture the meaningful variance in real-world pricing scenarios. At the same time, keeping the UI limited to four decimals avoids unnecessary visual noise compared to exposing the full six-decimal database precision. The database schema remains unchanged and continues to support up to six decimal places, preserving flexibility for future extensions if higher precision becomes necessary.

This change intentionally focuses on Custom Options as the most critical and currently inconsistent case. However, Magento uses percentage-based pricing in several other areas (e.g., Tier Prices, Bundle Options, Sales Rules, Catalog Rules, Shipping Handling), each with different database precision and UI handling. This PR may serve as a foundation for a broader, future effort to standardize percentage precision handling across the platform. A potential next step could be defining a unified strategy or configurable precision policy for percentage values, ensuring consistent behavior between API, database storage, and admin UI while respecting existing schema constraints and backward compatibility.

Backwards compatibility:
This change is fully backwards compatible:

• Fixed price options continue to display with 2 decimals
• Existing products are not affected
• No database schema changes required
• All existing admin UI modifiers (General.php, Eav.php) continue to use default precision

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any https://github.com/magento/devdocs/wiki/Magento-module-README.md require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @sydor-dev. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[sydor-dev]

@magento run all tests

[engcom-Bravo]

Hello,

As I can see this issue got fixed in the scope of the internal Jira ticket AC-14050 by the internal team
Related commits:https://github.com/search?q=repo%3Amagento%2Fmagento2+AC-14050&type=commits

Based on the Jira ticket, the target version is 2.4.9-beta1.

Thanks