>_ Coupon and Discount Testing Checklist

Short answer

A coupon and discount testing checklist verifies who can use an offer, which items receive it, how the saving is calculated, and whether the same discount is preserved when an order is placed. It covers promo codes, automatic discounts, combinations, minimum purchase rules, expiry, and redemption limits.

The result should establish that eligible purchases receive the agreed saving, ineligible purchases do not, and every displayed amount can be reconciled with the saved order. Applying a code successfully is only one part of that check.

Use this guide when launching a promotion or changing discount rules. For the wider purchase journey, use the E-commerce QA Checklist. Gift card balances, refund processing, and payment gateway testing are outside this guide's scope.

Discount testing vs cart and checkout testing

Shopping cart testing checks selected items, quantities, persistence, and the transition to checkout. Checkout testing checks the order-placement flow, including customer information, delivery, payment, and confirmation.

Discount testing follows one set of pricing rules across those stages. Its questions are more specific: does an excluded item count toward the minimum spend, can two offers combine, which amount is discounted first, and when is the last available use consumed?

Review the configured business rules before choosing expected results. A platform's default behavior, an installed extension, and a merchant's custom promotion can produce different valid outcomes.

When to use this checklist

Run a focused discount check when:

• a campaign adds a new code, percentage, fixed amount, or free-shipping offer;
• eligible products, variants, customer groups, or minimum spend change;
• automatic offers or discount-combination settings change;
• a campaign introduces an expiry date or limited number of uses;
• cart, checkout, pricing, or promotion integrations are upgraded;
• a production issue involves an incorrect saving, rejected eligible code, or inconsistent order total.

For a single rule change, test its boundaries and its interactions with existing offers. For a new promotion engine or a large campaign, cover the full lifecycle from rule setup to the saved order and campaign deactivation.

Quick coupon and discount testing checklist

Before approving a promotion, check that:

• a valid code applies to a known eligible basket with the independently calculated saving;
• an invalid code reports failure without changing valid basket totals;
• an excluded product receives no discount, including in a mixed basket;
• customer eligibility is checked using the identity defined by the campaign;
• the minimum-spend boundary is tested below, at, and above the threshold;
• a fixed amount is applied once per order or per eligible item as configured;
• percentage discounts use the correct base and rounding rule;
• a prohibited combination cannot silently grant both offers;
• an allowed combination follows the agreed calculation order;
• a free-shipping offer affects only eligible delivery methods and destinations;
• start and expiry boundaries use the configured campaign time zone;
• total and customer usage limits reject the next use after the limit;
• changing quantity or removing an eligible item revalidates an applied code;
• removing a code restores the correct amount and preserves unrelated offers;
• the final discount and total match the saved order, confirmation, and receipt;
• repeated submission does not duplicate a saving or consume an extra use for the same redemption.

Full coupon and discount testing checklist

1. Define the rule and prepare test data

Write the expected rule before comparing it with the storefront. Include the calculation base, combination policy, active period, and event that consumes a use. An offer described only as "10% off" leaves important questions unanswered.

Check that:

• the configured type, amount, currency, and code match the approved campaign brief;
• eligible products, variants, categories, customer groups, and exclusions are identified;
• minimum spend, maximum saving, and item-count restrictions have explicit expected values when supported;
• the start time, end time, time zone, and treatment of an already applied offer at expiry are defined;
• total-use and per-customer limits identify when a use is reserved, consumed, and released;
• fixtures include eligible, excluded, sale-priced, and mixed baskets plus customers on both sides of an eligibility rule;
• test orders and usage counters can be reset or replaced between runs without changing the production campaign.

Record whether thresholds use the whole subtotal or eligible items, and whether tax or shipping contributes. Verify the agreed store configuration; do not infer these rules from another merchant's checkout.

2. Check code entry and application feedback

Test code entry with realistic customer input, including paste and corrections. The response should distinguish an accepted offer from an unsuccessful attempt.

Check that:

• entering a valid code produces a visible applied state and the expected saving;
• empty input does not apply a discount or create a misleading success message;
• leading and trailing spaces are handled according to the agreed normalization rule;
• upper- and lowercase variants are accepted or rejected consistently with the configured code-matching rule;
• an unknown or mistyped code reports failure while the basket remains usable;
• submitting a second code clearly shows whether it was added, replaced an offer, or was rejected;
• the applied code and its saving remain understandable on a narrow mobile viewport.

3. Check product and variant eligibility

Use baskets that separate the product-selection rule from the calculation rule. A correct percentage applied to the wrong items is still an incorrect discount.

Check that:

• an included product receives the offer and an excluded product does not;
• variant-specific eligibility distinguishes two variants of the same product;
• category, collection, or brand rules include the intended items and exclude unrelated ones;
• explicit exclusions take precedence when the campaign defines them as overrides;
• a mixed basket discounts only its eligible lines and leaves other line amounts unchanged;
• bundles or subscription items follow their documented eligibility when included in campaign scope;
• changing a product's campaign classification produces the expected eligibility on the next required price refresh.

4. Check customer eligibility

Identify the customer attribute the rule actually uses. An offer for a first purchase, an account segment, and a designated email address can require different data.

Check that:

• the intended customer group receives the offer and a customer outside it is rejected;
• a first-purchase offer distinguishes customers with and without the qualifying prior purchase;
• guest use follows the campaign rule rather than accidentally inheriting logged-in eligibility;
• email-specific offers evaluate the configured customer or billing email field;
• signing in or switching accounts reevaluates an applied customer-specific code;
• changes to the relevant email or customer details trigger revalidation at the agreed stage.

For example, WooCommerce's coupon settings provide product restrictions, spend limits, email restrictions, and usage limits. Those options describe WooCommerce behavior; use the actual platform settings and campaign brief to define expectations for your store.

5. Test minimum and maximum spend boundaries

Calculate the qualifying amount from known items. A basket can look large enough while its eligible subtotal is below the campaign threshold.

Check that:

• a basket just below the minimum is rejected;
• a basket exactly at an inclusive minimum is accepted;
• a basket just above the minimum is accepted when all other conditions hold;
• an excluded line contributes to the threshold only if the campaign explicitly counts it;
• any maximum-spend boundary is tested at and just above its limit;
• the threshold calculation uses the configured treatment of sale prices, prior discounts, tax, and shipping;
• the error explains the unmet purchase condition without displaying an applied saving.

For a two-decimal currency and an inclusive minimum of 100, use 99.99, 100.00, and 100.01. Keep product and customer eligibility constant so the result tests the threshold itself.

6. Verify amounts, caps, and rounding

Calculate expected results independently from the application. Distinguish a fixed amount off the order from a fixed amount off each eligible unit.

Check that:

• a percentage uses the eligible amount specified by the rule;
• a fixed order discount is deducted once from the qualifying basket;
• a fixed product discount follows the configured number of eligible units;
• a maximum-saving cap is applied below, at, and above the value where it takes effect;
• rounding follows the agreed currency precision and line-level or order-level policy;
• the sum of stored line discounts agrees with the displayed order discount under that rounding policy;
• an offer larger than its qualifying base follows the defined cap and does not create an unintended negative payable amount;
• a fixed-value offer is restricted or converted correctly when the customer changes currency, according to the supported currency rule.

Compare the calculated saving as well as the final total. Two errors can cancel each other out and produce a plausible total while individual order lines are wrong.

7. Check discount combinations and calculation order

Discount stacking means applying more than one offer to a purchase. Specify which combinations are allowed, which offer wins when they conflict, and the base used at each calculation step.

Check that:

• an allowed pair applies both savings using the documented calculation order;
• a prohibited pair rejects or replaces an offer according to the configured conflict policy;
• applying codes in reverse order produces the expected result for that policy;
• an offer restricted to individual use cannot remain combined through removal and reapplication;
• caps and minimum-spend conditions are evaluated at the correct stage of a combined calculation;
• removing one offer preserves the other and recalculates its saving from the correct base;
• the order summary identifies the offers that actually contributed to the saving.

Shopify's discount-combination documentation distinguishes product, order, and shipping discounts and describes combination settings on each offer. That is a platform-specific model, not a universal rule that every pair of discounts must combine or calculate sequentially.

8. Check sale prices and automatic offers

Automatic promotions can already be active before a customer enters a code. Test that starting state explicitly rather than treating the basket as undiscounted.

Check that:

• the configured exclusion or inclusion of sale-priced items is respected;
• a code calculates from the approved sale or regular price base;
• an automatic offer activates for the intended basket without requiring a manual code;
• entering a code combines with, replaces, or loses to the automatic offer according to the configured selection rule;
• removing a manual code restores an eligible automatic offer when the rule requires it;
• automatic offer messages disappear or change when their qualifying conditions no longer hold;
• a crossed-out regular price, sale price, and coupon saving communicate the actual charged amount consistently.

9. Check shipping discounts and total reconciliation

A free-shipping promotion may affect only particular delivery methods or destinations. Keep product savings separate from shipping savings when reconciling the total.

Check that:

• a qualifying address and delivery method receive the agreed shipping saving;
• excluded methods, destinations, or surcharges retain their required charge;
• changing the delivery selection recalculates the shipping offer before order confirmation;
• a product-only coupon leaves shipping unchanged unless the campaign includes a shipping benefit;
• a combined product and shipping offer shows both components without counting either saving twice;
• tax, shipping, and the final payable total match independently prepared expectations for the configured store rules.

Tax treatment depends on the store's applicable configuration and requirements. This checklist verifies implementation against those agreed rules; it does not choose a tax policy.

10. Test the campaign schedule and time zone

Record the exact boundary semantics. An expiry date interpreted as the start of a day and one interpreted as the end of a day produce different results.

Check that:

• a scheduled offer cannot be used before its configured start;
• the offer becomes available at the defined start boundary;
• use immediately before, at, and after the end boundary matches the documented inclusive or exclusive rule;
• the configured campaign time zone is used when interpreting the schedule;
• the promotion message and pricing decision agree when the active period changes;
• a code applied before expiry is revalidated or honored at order placement according to the agreed policy;
• a cached page or restored basket cannot retain an expired saving when the policy requires its removal.

Use controlled test times or short test campaigns in the agreed environment. Changing only a tester's device clock may not change the time used by the promotion system.

11. Check usage and item limits

Define whether the limit counts applications, reserved checkout attempts, created orders, or another event. Compare counters against that event instead of assuming that entering the code consumes a use.

Check that:

• a code with remaining total uses accepts a qualifying redemption;
• the next qualifying redemption is rejected after the total limit is reached;
• per-customer limits distinguish the same customer from another eligible customer;
• the configured identity used for guest usage limits remains consistent across repeat attempts;
• an item-count limit discounts only the allowed number of qualifying units;
• failed or abandoned attempts retain or release any reservation according to the defined policy;
• usage history and counters can be reconciled with the qualifying orders or events.

Treat abandoned-use release and actual refund processing as separate workflows. Confirm the reservation rule here; use the wider order and payment checks for post-purchase financial changes.

12. Test repeated actions and the last available use

Exercise retries and simultaneous customers with controlled test data. These cases expose mistakes that a single successful redemption cannot reveal.

Check that:

• repeated clicks on Apply do not add the same saving twice;
• removing and reapplying a code does not create an extra consumed use when application is not the consumption event;
• retrying the same checkout operation does not count one successful redemption twice;
• two attempts competing for one remaining use cannot both consume it when the rule permits only one;
• the unsuccessful competing attempt receives a clear result and can continue using an updated order summary;
• a failed attempt does not permanently exhaust the last use when the configured reservation-release rule should make it available again.

Agree how the test team will coordinate competing attempts and observe the resulting counters. Run this against test orders and campaign data, not an active customer campaign.

13. Revalidate after basket and session changes

Start with an accepted offer, then change the state that made it eligible. This tests whether an already applied discount can become stale.

Check that:

• removing the only eligible product removes or rejects its saving on the next required recalculation;
• reducing the qualifying subtotal below a threshold updates the offer and its explanation;
• increasing quantity recalculates the saving without exceeding item or maximum-saving limits;
• switching to an excluded variant updates the affected line and order totals;
• restoring a saved basket reevaluates changed prices, campaign status, and remaining uses;
• signing out or changing customer details updates customer-specific eligibility;
• the customer can identify any changed saving before confirming the purchase.

14. Verify the final order and downstream amounts

Follow a qualifying basket through the supported checkout paths. Compare the final pricing decision with the record saved by the order system.

Check that:

• cart and checkout carry the correct code, eligible lines, discount amounts, and currency;
• normal and accelerated checkout paths enforce the same campaign rules when both are supported;
• a rule change before submission is handled according to the defined revalidation policy;
• the saved order contains the offers and line allocations used in the accepted final summary;
• confirmation, receipt, and order-management views reconcile with that saved order;
• an integration receives the correct discount values rather than recalculating from incomplete campaign data;
• disabling or editing a campaign does not rewrite a completed order's recorded saving.

Record the campaign version and order ID for any mismatch. A storefront screenshot alone cannot establish what the order system saved.

15. Check application failures and recovery

A failed request should leave an understandable pricing state. Cover failures while applying, replacing, and removing offers.

Check that:

• a failed application reports the failure instead of displaying an unconfirmed saving;
• a failed replacement preserves the prior offer or clears it according to the defined recovery behavior;
• a removal timeout reconciles the displayed summary with the actual applied state;
• retrying after a timeout produces one applied offer and the correct usage state;
• responses arriving out of order cannot overwrite a newer basket with stale eligibility or amounts;
• the customer can recover without losing their selected products or unintentionally accepting a different total.

16. Verify activation, deactivation, and release evidence

Finish with the campaign state that customers will actually encounter. Keep production checks limited to the safe path approved by the store owner.

Check that:

• the released code, restrictions, dates, and combination settings match the approved campaign version;
• an agreed eligible test basket receives the intended saving on the live storefront when production testing is authorized;
• the offer is rejected for an agreed ineligible test basket while the basket remains usable;
• disabling the offer prevents new use at the stage defined by the campaign policy;
• published promotion copy matches the active offer and is removed or updated when it ends;
• the test report records expected amounts, actual amounts, campaign version, order references, and unresolved defects;
• the campaign owner reviews any remaining pricing or redemption risk before launch.

Worked discount and redemption examples

These examples use invented offers and a two-decimal currency. Amounts are before shipping and tax, and each example states its own rule. Recalculate using your store's actual policy and precision.

Example 1: Percentage discount on a mixed basket

• Rule: 15% off eligible products; excluded products receive no saving.
• Basket: Two eligible units at 60 each and one excluded item at 30.
• Calculation: Eligible amount is 120. The discount is 120 multiplied by 0.15, or 18.
• Expected result: The product subtotal is 150 before the offer and 132 after it. The excluded item's amount stays 30.
• Failure this catches: Calculating 15% from the whole basket would incorrectly give a discount of 22.50.

Example 2: Minimum spend based on eligible items

• Rule: 10% off when the eligible subtotal is at least 100; excluded items do not count toward that threshold.
• Basket: Eligible products total 99.99 and an excluded product costs 40.
• Expected result below the boundary: The code is rejected even though the full product subtotal is 139.99.
• Boundary change: Add 0.01 of eligible value in the controlled fixture, bringing the eligible subtotal to 100 and the full subtotal to 140.
• Expected result at the boundary: The code applies a discount of 10 and leaves a product subtotal of 130.

Example 3: Fixed amount and percentage in sequence

• Rule: A fixed order discount of 10 applies first, followed by 10% off the remaining eligible amount. Both offers are allowed to combine.
• Basket: Eligible products total 100.
• Calculation: The fixed discount leaves 90. Ten percent of 90 is 9, giving a combined saving of 19.
• Expected result: The product subtotal is 81 after both offers.
• Order comparison: Applying the percentage first would leave 90, then deducting 10 would produce 80. That is a different policy and fails this example's stated rule.

Example 4: Two customers competing for one remaining use

• Rule: One coupon has a total limit of 100 redemptions, with usage consumed when a qualifying order is created.
• Starting state: The counter is 99 and two eligible customers prepare independent test checkouts.
• Action: Coordinate submission so both attempts compete for the remaining use.
• Expected result: Exactly one order receives the coupon. The counter becomes 100, and the other customer receives the configured rejection or updated-summary response before proceeding under different terms.
• Evidence: Both attempt references, the saved order discount, the final usage counter, and the second customer's visible outcome.

Common mistakes

1. Checking only whether the code is accepted

A success message can hide an incorrect base, an excluded item receiving a saving, or a wrong line allocation. Compare independently calculated amounts and the saved order.

2. Treating the whole basket as eligible spend

An excluded item can push the displayed subtotal above a threshold without making the offer valid. Define the qualifying base and use a mixed basket that exposes the distinction.

3. Confusing fixed order and fixed product discounts

A saving of 10 once per order and 10 for each of three eligible units differ by 20. One-item baskets cannot reveal that mistake.

4. Guessing how offers combine

Adding percentages, calculating sequentially, and choosing the best single offer can produce different valid results under different configurations. Establish the expected policy before assigning a pass or fail.

5. Testing expiry on only one side of the boundary

An offer can work before its end date while remaining usable afterward. Test the exact boundary and the time zone, including an already applied code when checkout crosses the deadline.

6. Checking counters without defining the consumption event

A reserved attempt may appear as a used coupon even when the order is incomplete. Match the counter to the reservation and consumption rules, then verify recovery and repeat attempts.

7. Stopping at the cart total

The cart can show the right saving while checkout drops it or the order integration saves the wrong value. Keep the code and amount traceable through the final order.

FAQ

What is the difference between coupon and discount testing?

A coupon or promo code is one way to trigger an offer. Discount testing also covers automatic offers, eligible calculation bases, combinations, caps, and saved order amounts. Test code entry when it exists, then verify the underlying rules regardless of how the offer is activated.

What test data is needed for promo code testing?

Prepare eligible and excluded items, a mixed basket, sale-priced products, different customer states, and values near spend thresholds. Include inactive and expired offers, offers near their usage limit, and any pair whose combination is supported or prohibited. Use independent fixtures or reset counters so one run does not change another's expected result.

Should excluded products count toward minimum spend?

That depends on the configured campaign rule. Write down whether the threshold uses the whole basket or only qualifying lines, and whether prior discounts, tax, or shipping contribute. A mixed basket with qualifying spend just below the minimum makes the distinction observable.

Can two discount codes always be used together?

No. Combination support depends on the platform, offer types, extensions, and campaign settings. Define the allowed pair, calculation order, and conflict outcome. A rejected second code can be correct; an accepted pair can still fail if it uses the wrong amount or calculation base.

When should a coupon's usage counter increase?

At the event defined by the system's redemption policy, such as reservation or qualifying order creation. Document that event and any later release condition. Applying a code, starting checkout, creating an order, and completing payment are different events, so verify the one your implementation actually uses.

Why can a code work in the cart but fail at checkout?

Checkout may introduce a delivery address, customer identity, changed basket, updated price, expired offer, or exhausted usage limit. Check which condition changed and whether the customer receives an accurate explanation and updated total. A mismatch with unchanged qualifying data may indicate inconsistent rule enforcement between stages.

How do you decide whether a promotion is ready to launch?

Review evidence for eligibility, independently calculated savings, boundaries, combinations, usage limits, and final order values. Resolve defects that grant unauthorized savings, reject qualifying purchases, or misstate the total. Record remaining limitations and obtain the campaign owner's decision against the agreed launch criteria.