Picture a Gulf retailer preparing a weekend campaign across its UAE and Saudi storefronts. Merchandising has reduced selected products. CRM has scheduled a welcome voucher. The loyalty team promises member savings, and paid media advertises free delivery above a threshold. Every team has approval for its own offer. Nobody has approved the basket containing all four. Ecommerce promotion stacking is the decision about which of those promises may operate together.
The executive question is not whether the checkout supports discount codes. It is whether the retailer can explain and afford every permitted combination. I would treat that as a pricing policy before treating it as a software setting. A campaign calendar shows when offers run; it does not show what happens when they collide.
Ecommerce promotion stacking needs one owner
Give a commercial owner authority over the combined offer, with finance checking the economics and ecommerce implementing the rule. Channel teams should propose discounts, not independently define how much value the same order can surrender. Include customer service because it will have to explain rejected codes and inconsistent promises.
Inventory every active incentive: catalogue sale prices, automatic discounts, voucher codes, loyalty benefits, employee offers, payment-provider subsidies, free gifts and delivery promotions. Distinguish a lower base price from a discount applied later. A checkout may treat an already reduced product as the starting price even when your campaign spreadsheet treats that reduction as the entire offer.
Record market, currency, eligible products, customer group, channel, start and end time, funding owner and redemption limits. Specify whether a provider contribution is contractually recoverable or merely expected. Do not let an assumed reimbursement make an otherwise loss-making combination appear acceptable.
Build a combination matrix before touching settings
Put the offer types on both axes of a simple worksheet. Mark each pairing as allowed, excluded or conditional. A conditional pairing needs a testable rule: selected products, a contribution floor, a customer group or a defined trading window. Replace vague notes such as “loyalty should usually work” with an executable decision.
Then check the full basket. Pairwise approval alone can miss the cumulative cost of three or four individually acceptable offers. Require someone to price the richest valid combination and the lowest-margin eligible products. Include shipping subsidy and gift cost in that calculation.
Shopify's discount-combination documentation distinguishes product, order and shipping discounts. It states that combination settings must permit the pairing on each discount, and that supported combinations depend on eligibility and plan. Confirm the behaviour available to the actual store; a feature demonstrated in another account is not an implementation guarantee.
Priority needs its own policy. Oracle's promotion documentation describes stacking groups, priority and individual exclusions that override stacking rules. That is a useful reminder that two engines can resolve competing offers differently. Document whether your configuration selects a preferred campaign, the best customer saving or another explicit outcome.
Price the order the customer will actually pay for
Consider an illustrative basket with AED 200 of merchandise revenue before discounts, excluding tax solely to keep the arithmetic clear. A 20% product discount reduces it to AED 160. If a further 10% order discount applies to that reduced amount, the customer pays AED 144 before tax and delivery. The combined merchandise reduction is 28%, not 30%.
Suppose, for this example only, product cost is AED 100 and the retailer absorbs AED 15 in delivery cost. That leaves AED 29 before payment fees, picking, packaging, expected returns and other variable costs. These are invented planning inputs, not market benchmarks or reported results. Substitute your actual figures and calculation sequence.
Set the contribution floor using finance-approved definitions. Keep customer-facing totals and tax treatment in the production checkout calculation; the simplified worksheet does not replace them. Show both the most attractive advertised saving and the cash the business expects to retain.
Also decide what qualifies toward a spend threshold. Does free delivery use the basket before or after discounts? Are excluded products counted? What happens when the customer removes an item? The banner, cart and payment step should describe the same rule.
Test awkward baskets, not just the campaign example
Build a small set of saved baskets with expected outcomes agreed by the commercial owner. Run each through every relevant storefront and channel. Record the rule version, input basket, customer status, discounts attempted, final total and explanation shown to the customer.
- Boundary baskets: just below, exactly at and just above the qualifying spend, including a change after a voucher is applied.
- Mixed baskets: eligible and excluded products, sale items, multiple quantities, gifts and products with different delivery treatment.
- Identity changes: guest to logged-in member, an existing customer trying a welcome code and a customer changing market.
- Timing changes: a cart created before an offer starts or expires, checked out after the boundary in the intended local time.
- Recovery paths: payment retry, order amendment, partial cancellation and refund, with the original discount allocation preserved.
Read the Arabic and English messages as part of the test. “Invalid code” is poor guidance when the real issue is an excluded category or an incompatible member offer. Explain the applicable condition without asking the customer to understand your promotion engine.
For multi-item offers, the adjacent note on ecommerce bundle economics covers composition and fulfilment. Here, the concern is the interaction between independently created incentives. A perfectly configured bundle can still inherit a welcome voucher nobody intended to fund.
Watch combinations after release
Launch with identifiable promotion versions and a clear way to disable the offending rule. Monitor actual combinations redeemed, contribution after funded discounts, rejected-code reasons, manual overrides and support contacts. Review the orders where the saving differs from the approved expectation, not only the total campaign revenue.
Separate a rule defect from a commercial disappointment. If the engine applied an excluded pairing, repair the configuration and affected journey. If it correctly applied an approved pairing that earns too little, the pricing decision needs revision. More automation cannot settle that disagreement.
This is a concrete responsibility within marketing automation and customer-journey design: a message should lead to an offer the business can honour consistently. Ecommerce promotion stacking deserves approval at basket level, where the promises finally meet. Do not launch four sensible campaigns until somebody has signed the fifth offer they create together.