A shopper selects gift wrapping, changes a delivery method and then removes an item. If an optional charge does not recalculate consistently, the order total becomes hard to explain. Magento extra-fee extensions address this problem by connecting additional services to cart conditions, customer selections and sales documents.
This comparison covers Amasty Extra Fee, Mageplaza Extra Fee and Mageworx Multi Fees, three extensions for configuring additional order charges. The research uses official product pages, manuals and licensing material checked on October 23, 2026. It does not claim hands-on payment testing, benchmark results or an increase in revenue.
Define the fee before choosing the extension
Separate an optional service, such as wrapping, from a required business charge and from a normal shipping rate. Decide what causes the charge, whether customers can remove it, which items contribute to the calculation and what should happen after a partial refund. A fee’s name should describe what the customer receives.
This is a software workflow comparison, not advice on whether a payment surcharge or tax treatment is permitted in your jurisdiction. Have the business validate its policy separately. The implementation must then reproduce that approved policy across storefront, administration, payment capture, invoice and credit memo.
| Product | Rules and service model | Commercial/integration checkpoint |
|---|---|---|
| Amasty Extra Fee | Conditional fixed/percentage fees with tax and refund settings | Hyvä, multishipping and Adobe Payment Services companions |
| Mageplaza Extra Fee | Automatic/manual services with product and checkout placement | $199 Community or $399 Enterprise/Cloud first year observed |
| Mageworx Multi Fees | Separate product, cart, shipping and payment fee workflows | $199 Open Source; Commerce selection adds $199 |
Amasty Extra Fee
Amasty Extra Fee supports conditional additional charges, fixed or percentage calculations and configurable tax/refund behavior. Its guide explains how discounts, shipping costs and fee tax classes influence calculations. Those controls matter when the same service is offered to customers with different tax presentation settings.
The design question is which amount should remain stable. A gift-wrap charge might apply once per order, whereas special packaging could depend on qualifying items. Write that distinction before configuring rules. Otherwise a setting that looks reasonable in an empty cart may produce a different commercial policy once discounts or mixed product types appear.
Current version 1.8.4 adds an Adobe Payment Services companion, and earlier notes cover PHP 8.4/Magento 2.4.8, multishipping and Hyvä Checkout CSP work. The storefront advertises maintained Magento branches including 2.4.9; ask for the exact Open Source or Adobe Commerce patch and PHP constraints. The retrieved notes do not establish PHP 8.5 support for every installed package.
The manual names separate Hyvä Theme and Hyvä Checkout packages, with active product/support subscriptions governing availability. Multishipping and Adobe Payment Services integrations also have suggested packages. Read/write GraphQL is documented, with another compatibility package for GraphQL Application Server. A PWA implementation still needs to expose choices and recalculate totals at the right moments.
Strength: explicit settings and integration paths for complex calculation environments. Limitation: package entitlement and checkout combinations need a complete quote. A reliable selected edition price and exact renewal amount were not confirmed, so do not use a cached promotion as a budget. The license uses one copy per Magento installation; confirm registration and support coverage for the actual production/staging topology.
Mageplaza Extra Fee
Mageplaza Extra Fee presents optional and automatic fees with fixed-per-product, fixed-per-order and percentage calculations. Product and cart conditions determine applicability; store-view/customer-group settings and scheduling control the audience. Services can appear around product and checkout areas, and the extension includes fee-refund controls.
That model suits a team that wants services to be discoverable before checkout. For example, showing wrapping beside a product may make the offer easier to understand, but it creates a requirement to keep the product-page selection consistent with the cart. Ask what happens when a buyer changes quantity, removes the qualifying item or returns from an external payment page.
The manual is useful for mapping rule conditions to calculation settings. Decide whether the calculation base includes discounts, shipping or tax, then document a worked example using the business’s own sample values. Avoid relying on a demonstration order whose totals happen to agree because there is only one item and no discount.
Version 4.5.4 adds Magento 2.4.9; version 4.5.3 explicitly supports PHP 8.4. The page advertises Hyvä Theme, Hyvä Checkout and API/GraphQL. Older notes said Hyvä without Hyvä Checkout, so package age matters: later checkout support should not be projected backwards onto an older installation. Confirm Luma/custom checkout and headless integration against the selected release.
Strength: a service-selection workflow spanning product pages and totals. Limitation: payment, refund and rule interactions still require staging acceptance. Observed prices are $199 Community and $399 Enterprise/Cloud for the first year, including one year of support and updates. Exact renewal prices need confirmation. One live Magento installation is licensed, with unlimited test installations; independent production instances need additional licenses.
Mageworx Multi Fees
Mageworx Multi Fees organizes fees around product, shopping-cart, shipping and payment contexts. Its guide documents selectable options, required fees, product conditions, tax classes and per-quantity/weight/spend settings. That separation helps a team explain which part of the buying process owns each charge.
For a mixed basket, this can make a difference between a service attached to one item and a charge attached to the entire order. Keep those meanings distinct when building rules. A required packaging service for one fragile product should not quietly become a cart-wide charge for unrelated items unless that is the intended policy.
The current page displays version 2.7.0; 2.6.0 release notes add Magento 2.4.9 and PHP 8.5. Open Source and Commerce 2.4.x are listed, with separate Commerce/Cloud selectors. The manual documents free Hyvä Theme and Hyvä Checkout compatibility add-ons. GraphQL support also has an add-on path, so list those dependencies explicitly for a PWA or API-driven checkout.
Observed pricing is $199 Open Source and an additional $199 for Commerce or Commerce Cloud. One year of updates/support is included, followed by optional annual coverage at 40% off the edition list price, without recurring payments. Installation and priority support are priced separately. A future list-price change can alter renewal cost even when the discount rule remains the same.
Strength: distinct fee contexts and detailed integration documentation. Limitation: more configurable contexts require disciplined rule ownership. The licensing model is per Magento production installation; multiple websites inside one installation are different from several independent installations. Confirm the proposed deployment rather than estimating license count from the number of storefront languages.
Use a totals acceptance matrix
Ask the implementation team to demonstrate an optional service, a required fee, two qualifying items, a non-qualifying item and a discount. Change shipping and payment methods, then verify totals after navigating back from checkout. Include the payment provider’s authorization/capture path and one partial credit memo. These are proposed checks, not results from testing the three extensions.
Review rounding, currency conversion, invoices, refunds and exports to accounting. The displayed total, captured amount and recorded credit memo must tell the same story. For multiple shipping addresses, confirm whether the fee is per shipment, item or order and whether the selected companion module is required.
Choose Amasty when its calculation settings and named payment integrations match the requirements. Choose Mageplaza for services presented across product and checkout steps. Choose Mageworx when the distinction between product/cart/shipping/payment charges fits the team’s rule model. Obtain a package-level quote for the actual Magento edition, PHP runtime and checkout before deciding on initial price alone.
Our checkout comparison and table-rate shipping comparison cover adjacent choices. Keep shipping-rate ownership and additional-service ownership clear so the same business charge is not introduced twice.