Purpose and use of the Debug view

The Debug view is an additional view for administrators that shows background information about pricing, shipping methods, and shopping cart calculations directly in the store interface where the problem is occurring. It allows you to trace why a price or shipping method is behaving in a certain way.

Narrow down the problem in debug view

The Debug view is currently used on the product page and checkout. Admin Debug on the product page shows information related to product pricing. Admin Debug on the checkout shows shipping method rules and cart weight, size, and row information. Debug data is only displayed in the admin session; a regular customer does not receive a separate debug section with the page data.

Always replicate the same situation where the problem was observed. Price, shipping, and payment method calculations can change based on products, quantities, customer type, country, postal code, customer group, and cart value. Debug data obtained with a different cart does not explain the original case.

Find out the product price and discount

Admin Debug on the product page helps you understand the background behind the price and discount of a product. The Discount Types section shows the active discount types for the product, and the History section shows the price history of the product. Compare this information with the price that the customer sees for the same product and customer situation.

Discount Types tells you which discount sources are contributing to the price. History helps you differentiate the current price from past price changes. If the price seems wrong, record the product ID or SKU, the displayed price, the expected price, active discount types, and relevant price history lines. Don't change the price based solely on the debug view until you've identified the rule that's causing the price.

Find out the initial status of the delivery method

Shipment setEnable in the Checkout Admin Debug table shows which shipping method modules were initially enabled and which were initially disabled. The row shows the module name and module code, so you can identify the exact shipping method even when multiple methods have the same display name.

Check this line before the weight and size limits. If the module is already disabled setEnable phase, the reason may be, for example, the module's usage mode, region, or a delivery method blocked for the customer. In that case, the weight and size lines alone do not explain the absence. The code forms the initial state from the module's usage mode, geographical region, and customer's block list.

Check weight and size limits

In the checkout delivery methods debug data, the following lines describe the output of weight and size limits:

• Shipment shippingDetails.isUnderWeight : The weight of the shopping cart is below the minimum weight for the shipping method.
• Shipment shippingDetails.isOverWeight : The weight of the shopping cart exceeds the maximum weight of the shipping method.
• Shipment shippingDetails.isOverSized : The calculated package size exceeds the allowed limit for the shipping method.
• Shipment weightLimitSource : The weight basis used for the maximum weight comparison.

A value of true means that the delivery method is blocked by that limit. Check the module, the calculated value of the shopping cart, and the limit on the same row. The minimum weight comparison uses the largest weight base in the shopping cart, while the maximum weight uses weightLimitSource value specified for the delivery method.

Compare to cart calculation

The Checkout Admin Debug displays the cart calculation data in three groups. Cart weight contains the actual weight of the cart, the volumetric weight, and the maximum weight basis. Cart size contains the length, width, height, and calculated package size. It can also display the packaging calculation method and the packaging rules used.

Cart items shows the quantity, size, and calculated weight basis per line. If only a specific product or quantity removes the shipping method, open this group and compare the product line values to the Cart weight and Cart size values for the entire cart. This will help you distinguish between a product data error and a total cart calculation and a shipping method limit.

Use the checkout debug view step by step

Reliable use of the checkout debug view requires repeating the same purchase situation:

1. Log in to the store with admin rights and open the checkout.
2. Add the same products and quantities to the shopping cart as in the problem situation.
3. Use the same customer type, country, and postal code.
4. First, check Shipment setEnable .
5. Then check isUnderWeight , isOverWeight , and isOverSized .
6. Compare Cart weight and Cart size values to the delivery method limits.
7. Open Cart items if the issue is related to a single product.

The admin session checkout page data includes separate debug.shipment and debug.cart sections, from which the UI builds a table. They are not included in the regular customer checkout data.

Interpret payment method visibility

There is no separate Payment section in the checkout debug view that lists the reasons for payment method rejections with the same level of detail as for delivery methods. A payment method may be visible but blocked, or it may be missing altogether if the module is not in use, the geographical region does not match, the payment method is blocked from the customer, the customer type does not match, or the cart value is outside the payment method limits.

A payment method can also block a specific delivery method, in which case the checkout will show a separate error message for the combination. In addition, a payment method may have its own additional logic. If the general terms and conditions do not explain the case, record the payment method module code, delivery method, customer type, country, postal code, and shopping cart value. An equally detailed list of reasons requires a separate payment method debug plugin.

Collect information for further investigation

To further investigate the Debug view, take a screenshot of the entire Admin Debug section and record the items in the cart along with the quantities, customer type, country, and zip code. Name the missing or blocked shipping or payment method and add its module code if it is visible.

For a shipping method issue, record Cart weight , Cart size , relevant Cart items rows, and the module where debug shows the rule is blocking. For a product price issue, record the product ID or SKU, displayed and expected price, Discount Types , and relevant History rows. This information can be used to reproduce the issue without guesswork.

When to expand the debug view

The Debug view extension is useful when the same unexplained problem occurs repeatedly across different customers or different combinations of shipping and payment methods. On a product page, additional information can help open a single calculation decision for a price, discount, or price history. At checkout, additional information can name a reason for rejection of a missing shipping or payment method.

It is a good idea to show the new debug information to the administrator in the view where the decision is made, and keep it out of the regular customer's page data. The extension should name the rule, input value, comparison limit, result, and module code so that the same case can be verified later.