Start with the promotion the business intended
A Magento coupon can be valid yet fail to discount the basket a customer expects. The code, eligible audience, qualifying conditions and discount action are separate parts of the promotion. Before editing rules, write down the intended offer in plain English: who qualifies, what they must buy, when the offer applies and which items should receive the discount.
Midoriweb uses that description as the acceptance test. “Ten per cent off selected products for registered customers” is materially different from “ten per cent off the whole basket when it contains a selected product”. Both can sound similar in a marketing brief but require different logic. A technical change is not successful if it implements the wrong commercial interpretation.
For an urgent campaign issue, include the code, affected website, a redacted example basket and the advertised offer in your enquiry. Do not send customer account credentials. Our Magento support service can scope the configuration and custom-code checks needed to explain the discrepancy.
Reproduce the exact qualifying context
Record the website, customer group, guest or account state, product variants, quantities and basket totals. Include the date and time in the store’s relevant context. Compare a case that should qualify with one that should not. This provides both a positive test and a boundary that must remain protected after a fix.
Use the actual child products and options selected in the basket. A rule based on an attribute can behave differently when the relevant value belongs to a parent product, a child variant or another product type. Check the configured rule and submitted items rather than assuming every catalogue relationship is evaluated identically.
If the code is rejected immediately, investigate code validity and eligibility first. If it is accepted but the amount is unexpected, focus on the qualifying items, action and totals calculation. These are different failure paths and should not be collapsed into one generic “coupon broken” incident.
Check effective dates, scope and usage limits
Review whether the rule is active in the intended website and customer group, and whether its effective period matches the campaign. Check coupon-specific limits and relevant customer usage restrictions. A code tested repeatedly by one account may reach a limit that a new customer has not reached.
Do not remove limits simply to make a test pass. First determine whether the restriction is intentional and whether recorded usage matches the expected order history. If there is a genuine data or implementation issue, preserve the evidence and agree a targeted correction.
Time boundaries deserve a controlled test. A promotion intended to end at midnight needs a clearly understood time zone and business interpretation. Marketing messages, application configuration and operational expectations should agree. Record those assumptions so the next campaign does not recreate the same ambiguity.
Distinguish conditions from discount actions
Rule conditions establish when an offer qualifies; actions determine what receives the benefit and how it is calculated. Adobe’s cart price rule guide documents the configuration. Refer to the installed edition and version when reviewing available options.
Consider an illustrative basket containing one qualifying item and one excluded item. The intended result might discount only the qualifying line, or it might unlock a basket-wide offer. The test should calculate the expected amounts explicitly rather than treating any visible discount as success.
Review quantity limits, discount steps and product restrictions where used. A promotion that works for one unit may behave differently for a mixed or larger basket. Midoriweb would turn those commercial conditions into a small repeatable test matrix before recommending changes.
Investigate competing rules and total calculations
More than one promotion may apply to a basket. Compare rule priorities, whether later rules are prevented from applying and how the intended offers should combine. The answer should come from the campaign specification, not from whichever combination produces the largest discount during testing.
Shipping, tax and currency presentation can make the displayed saving look different from a simple percentage of the visible basket total. Establish which amount the offer is meant to affect and compare the relevant calculation inputs. If shipping disappears or changes unexpectedly, use the shipping-method troubleshooting guide.
Custom totals collectors, loyalty modules and checkout extensions can alter the result. Record their involvement and compare behaviour on a representative environment. Disabling several modules at once may reveal an interaction but does not identify a safe production fix or prove which component owns the defect.
Check the customer journey after applying the code
The promotion needs to remain correct when the customer changes quantity, removes an item, signs in or changes delivery details. A discount that appears initially but becomes stale after a basket update can create confusion or an incorrect order total. Test recalculation at the actual point where the customer reports the failure.
Compare the browser display with the backend quote and final order values in an authorised test. If the backend is correct and the frontend is stale, the problem belongs in the presentation or update sequence. Rewriting the promotion rule would treat the wrong layer.
Where payment has already been attempted, do not repeatedly submit a live checkout to investigate a coupon. Use a suitable test arrangement and inspect existing records. Our checkout error guide explains how to isolate the failed stage without confusing payment completion with frontend feedback.
Make a narrow correction and protect the campaign
Record the original rule values and the reason for each change. If the campaign is live, agree how existing customers, already-created orders and advertised terms will be handled operationally. A rule edit changes future evaluation; it should not be assumed to repair historical orders automatically.
Verify the intended qualifying basket and at least one excluded basket after the change. Then test the relevant boundaries: date, quantity, customer group, website and usage limit. This prevents a repair from accidentally opening the offer to a wider audience or product range.
For custom-code corrections, include an automated or repeatable regression case that captures the actual defect. A test that merely confirms the rule can be saved is not enough. The evidence should demonstrate the correct totals and eligibility at checkout.
What a useful Midoriweb investigation delivers
The outcome should explain which condition or calculation caused the discrepancy, show the expected result for representative baskets and document the approved correction. It should also identify any unresolved interaction that needs separate development. This makes the result useful to marketing and customer service as well as developers.
Our role is to connect the commercial offer with Magento’s execution. That can involve configuration review, custom extension diagnosis or checkout testing. The scope is agreed around the problem, and any broader promotion redesign should be treated as a separate decision rather than introduced during an urgent repair.
Coupon questions
Why does a code work for one customer but not another?
Compare website, customer group, account state and usage history. A difference may be intentional eligibility rather than a platform defect.
Should we delete and recreate the rule?
Not before preserving its configuration and understanding the failure. Recreating it can remove useful history and reproduce the same incorrect conditions.
Is testing the cart enough?
No. Verify recalculation through the relevant checkout steps and the resulting order totals in an authorised test environment, especially when shipping or customer context changes.