Discount stacking: test the basket before a retail promotion

The promotion banner promises 15% off a category. A customer also enters a ₹300 coupon. The website accepts both, a store applies only the larger discount, and finance had approved a different minimum basket value. Each result may follow a system setting; the promotion still lacks a single commercial rule.

Before launch, specify eligibility, combination and calculation order. A discount engine should execute that approved rule, and a basket test pack should prove the customer will be charged the intended amount.

One basket, four possible totals

Use an illustrative ₹2,400 basket in one eligible category. Ignore tax and shipping in this exercise; production tests must use the retailer's approved tax and rounding configuration. The category reduction is 15%, or ₹2,400 × 0.15 = ₹360.

The last two totals differ by ₹45. Neither is a mathematical error. They apply the percentage to different bases. The title of a promotion or a checkbox labelled “combine” does not establish the intended sequence.

Suppose the coupon requires a basket of at least ₹2,000. The team must specify whether eligibility is checked before discounts, after the category reduction, or on eligible lines only. This basket clears the first two tests, but a ₹2,200 basket gives ₹1,870 after 15% off. It passes a pre-discount threshold and fails a post-discount one.

Microsoft Commerce's discount documentation distinguishes concurrency modes and pricing priority. Shopify's combination rules describe a different platform contract. Use the rules for the actual engine and plan; do not assume one platform's processing order applies to another.

Add a contribution boundary without hiding assumptions

For the ₹1,740 outcome, assume merchandise cost of ₹1,200 and incremental fulfilment/payment costs of ₹140. The illustrative contribution is ₹1,740 − ₹1,200 − ₹140 = ₹400 before fixed overhead and any excluded tax effects. It is not the discount amount and not a claimed profit result.

If a supplier funds ₹100 of the promotion, show that separately with its eligibility and recoverability. Do not add unconfirmed funding to the price engine's margin check. Finance can compare the customer charge, cost assumptions and funded amounts without rewriting the charged price after the sale.

The pricing manager owns the rule specification; commercial finance approves the contribution basis and exceptions. Store and ecommerce leads confirm that the terms can be displayed and executed consistently. One person must own the final release version.

1. Define eligibilityCategory, customer, channel, threshold and effective time are explicit.
2. Calculate the sequence₹2,400 × 85% − ₹300 = ₹1,740 for this approved case.
3. Check the boundary₹400 illustrative contribution under the stated cost assumptions.
4. Publish and compareStore and online receipts must match the approved version.

Exception: A different total, stale rule or unsupported combination blocks that promotion path until reviewed.

Build a test pack around disagreements

Start with baskets just below, exactly at and just above the threshold. Add an excluded item, a mixed eligible/ineligible basket, a quantity change and an already-used coupon. Record the expected discount allocations by line as well as the order total.

Allocation matters after a partial return. If a customer returns one line, refunding its original list price could exceed what they paid for that line. The refund calculation should use the approved allocation and return policy. Keep the original rule version and allocation with the sale rather than recalculating against today's promotion settings.

Check rounding with low-value items and multiple quantities. Choose where rounding occurs using the platform and finance configuration. A one-paise difference repeated across many lines must be explainable; a broad tolerance should not hide a wrong sequence.

Test the effective-time boundary in each channel's configured timezone, including a store that has not received the latest rule. Preserve the actual receipt if an expired offer was charged. Route correction and customer communication through approved policy instead of silently editing completed transactions.

Use the native engine before custom repricing

Native configuration is preferable when it expresses the intended rules and exposes their results. A separate scenario runner can compare expected baskets with engine outputs without becoming another pricing authority.

Custom repricing is justified only when a required rule cannot be represented reliably and the retailer accepts responsibility for tax interactions, allocation, refunds, retries and channel consistency. Scope the first project to one promotion family. Keep automated PO, refund or customer-message actions outside a pricing test tool unless explicitly designed and approved.

A release passes when every agreed basket matches in the intended channels, the displayed terms match the calculation, and disabling the rule stops new eligibility. Rollback must preserve historical transactions. For the stock action behind a promotion, see the markdown-versus-transfer guide.

Release the rule that the receipt proves

A promotion is ready when the team can explain the final charge and every line allocation. Matching banners are insufficient if the engines calculate different baskets.

1. Write the eligibility and combination order for one promotion.
2. Have finance approve expected totals and contribution assumptions.
3. Test boundaries, returns, rounding and stale-channel behaviour.
4. Release one version, retain its evidence and assign an owner for exceptions.