Rule Engine for E-Commerce: Discounts, Promotions, and Eligibility

A customer drops three things into the same cart: a coupon from your email, the 12% they get as a VIP-tier member, and the 15% summer sale running site-wide. What discount do they actually get? If you hardcoded "one discount at a time" somewhere in checkout, the honest answer is whatever the code happened to check first — and you'll learn it was wrong when finance reconciles margins at month-end.

E-commerce runs on decisions like this, and they multiply faster than almost anything else in the stack. This post is about where those rules should live, why the hardcoded version breaks, and how teams move discounts, promotions, and eligibility out of checkout code without losing control of them.

Why e-commerce decisions multiply

Most domains have a handful of business rules that change a few times a year. E-commerce has a combinatorial pile of them that changes every week, and each one looks harmless on its own:

• Coupon codes — entered at checkout, valid for a window, sometimes restricted to specific SKUs or first-time buyers.
• Tier discounts — VIP gets 12%, Gold gets 8%, tied to loyalty status.
• Seasonal promotions — a site-wide summer sale, a flash weekend, a category clearance.
• Free-shipping thresholds — over $50, or over $35 for members.
• Eligibility — who actually qualifies: a customer segment, a region, an order-history condition.
• Bundle pricing — buy two, get the third at a reduced rate.

Any one of these is a single condition a junior engineer can write before lunch. The trouble is that they all land on the same order at the same moment, and the number of combinations grows faster than anyone keeps track of. Three independent promotions already produce eight possible overlaps; a fourth doubles it again. Nobody sits down and reasons through sixteen cases, so the interactions go untested until a customer or an accountant finds them.

What separates e-commerce from other rule-heavy domains is that three pressures are high at the same time. The rules change often, because marketing runs a new campaign most weeks and the calendar never stops. They're owned by people who can't deploy, because merchandising and marketing decide the logic while only engineering can ship it. And they move money directly, because a wrong combination doesn't throw an error — it quietly sells below cost and looks like a successful order until the numbers are reconciled. Frequency, ownership, and money all pull in the same direction, and that direction is away from keeping the logic buried in code.

The hardcoded version, and where it breaks

It always starts the same way: an if-else block in the checkout service. If the coupon is valid, apply it. If the tier is VIP, apply that. If the summer sale is on, apply that too. For a single promotion owned by a single engineer, this is the right amount of structure, and reaching for anything heavier would be a mistake.

It breaks in four predictable places, and they arrive in roughly this order as the business grows.

Every change needs a deploy. Marketing wants the sale live Friday at 9am; the deploy window is Tuesday afternoon. The promotion now ships on the engineering calendar instead of the campaign calendar, and a one-line discount tweak turns into a sprint ticket, a code review, and a release. The logic isn't hard — the pipeline around it is.

Discounts interact in ways nobody predicted. Two rules that are each correct produce a combination that nobody signed off on. This is the expensive one, and it gets its own section below.

Nobody can answer why a price came out the way it did. A customer emails asking why their order wasn't discounted. Support escalates to engineering. Finance asks which promotions were live last Tuesday and which orders they touched. The checkout code computed a final number and threw away every intermediate step — which rules matched, which were skipped, and why — so the only way to reconstruct a past decision is to read the git history and guess.

The people who own the logic are locked out. Marketing and merchandising decide what the promotions are, but every change routes through an engineer's backlog. The team closest to the business problem is the team that can't touch the rule, and the team that can touch the rule has to context-switch into someone else's domain to do it.

When two correct discounts are wrong together

Here is the failure that costs real money. A VIP member, who gets 12% off, shops during the summer sale, which takes 15% off, and both rules match the same order. Each rule is correct in isolation. The order ships at 27% off, which nobody intended, and finance discovers it at month-end across thousands of orders.

The lesson underneath it is the one that catches teams off guard: the correctness of individual rules tells you nothing about the correctness of the set. Every discount can be right on its own and the combination still wrong, because the bug doesn't live in any single rule — it lives in the interaction between them. An if-else ladder has no concept of "these two must never both apply." It evaluates each branch independently and stacks whatever matches, which is exactly the behavior you don't want.

The structural fix is to make exclusivity a property of the rule set rather than something you try to enforce by hand in every new promotion. Competing discounts go into a mutex group: at most one wins per order, chosen by an explicit strategy you decide up front — highest priority, maximum customer benefit, or first match. The discount that loses isn't silently dropped; it shows up in the decision record with the reason it lost, so support can explain the price and finance can audit it.

That's the concept, and it's the part worth internalizing from this post. The exact rule definition, the decision trace that records the losing discount, and the edge cases — ties between equal discounts, choosing a strategy, what happens when nothing matches — are worked through end to end in the VIP discount stacking pattern. The one thing to take away here: stacking is not a bug you patch one branch at a time, it's a property you have to lift out of control flow and make explicit in the rule set.

Eligibility: who qualifies, and why it keeps moving

Discounts answer how much. Eligibility answers who, and it's the half of the problem that teams underestimate. Every promotion has a target: first-time buyers only, customers in a specific region, members above a certain order count, app-channel shoppers, a segment marketing built for one campaign. The discount is meaningless until you've decided who it reaches.

Eligibility has the same combinatorial habit as discounts, and it changes even faster. A discount might run for a season; the targeting behind it gets adjusted per campaign — this week it's Seoul plus new accounts, next week it's returning customers nationwide, the week after it's a segment that didn't exist yesterday. When that targeting is hardcoded as if customer.segment == "new" && customer.region == "KR", adding one segment to one campaign is a code change, a review, and a deploy, for logic that marketing wanted live an hour ago.

Pulling eligibility into rules makes the conditions data: a customer qualifies when segment IN [...], region EQUALS, order_count >= N, and marketing adjusts the target without an engineer in the loop. It also closes a gap that discounts alone can't. Eligibility and discount are two halves of the same decision — who qualifies, and what they get — and when both live in the same rule set, the interaction between them is visible in one place instead of split across a targeting service and a pricing service that don't know about each other.

The audit side matters here too. "Why didn't this customer receive the promotion?" is one of the most common support questions in e-commerce, and with eligibility as rules the answer is in the decision trace: the customer failed the order_count condition, or fell outside the region, with the exact rule and value that excluded them. No guessing, no reading code to reconstruct what the targeting was three weeks ago.

Test a promotion before it goes live

The other expensive moment is launching a promotion blind. When you lower the summer-sale threshold or add a new tier discount, how many orders will it actually affect? What happens to margin? Which existing promotions will it now combine with? Before it ships, every answer is a guess, and the guesses are usually optimistic.

A staging environment doesn't settle it, because staging has no real order distribution. "How many orders would this change have discounted?" is a question about your actual traffic — the spread of cart sizes, tiers, coupons, and regions that real customers bring on a real day. A handful of hand-written test cases can confirm the rule fires; they can't reproduce the shape of a month of orders, which is the only thing that tells you the blast radius.

The approach that does work is replaying the change against real historical orders: run the proposed promotion over last month's actual carts and read, before anything ships, how many orders newly qualify, which segments they fall into, and how the margin moves. You decide on evidence instead of on a hunch, and you find the bad combination in a report on Monday rather than in a reconciliation at the end of the quarter. The cost of being wrong drops from "live revenue" to "a number on a screen."

Replaying a rule change against real history and reading the impact side by side — matched orders, the metric delta, per-rule statistics — is the subject of the Impact Simulation pattern. The principle to carry out of this section is that a promotion change has a measurable blast radius, and the choice is only whether you measure it before customers do or after.

When you don't need this

Be honest about scale before reaching for any of this, because the wrong tool in the small case is every bit as much of a mistake as no tool in the large one. If you sell a single SKU, run no promotions, or have exactly one fixed discount that never changes, a config value is the entire answer and a rules platform is overhead you'll resent maintaining.

And if the only person who ever changes a discount is one engineer who is also the only one who needs to understand it, keep it in code and change it in a pull request. The case for moving this logic out of checkout is driven by who changes it, how often, and who has to answer for it — not by the existence of discounts as such. No recurring promotions, no marketing owner waiting on deploys, no month-end question about what was in force: then there is nothing here worth the weight, and you should walk away from it.

This post is about the specific point where promotions multiply, targeting shifts per campaign, and the people running both aren't the people who can deploy. If you're not there yet, don't build the machinery for a problem you don't have.

---

E-commerce rules multiply, change weekly, and land directly on revenue. Hardcode them in checkout and you inherit a deploy bottleneck, silent stacking bugs, eligibility you can't adjust in time, and no way to answer what was in force last Tuesday. Move them out, into data, and the shape changes: marketing runs the promotions and the targeting, stacking is closed by a mutex group instead of hoped away, and a change's impact is something you read before it ships rather than something you reconcile after.

LexQ is the Decision Operations Platform, not an e-commerce tool — which is precisely why it fits this domain and many others. A tool built only for e-commerce is locked to the e-commerce model; a platform that treats decisions as data reuses the same mechanisms (mutual exclusion, simulation, an audit trail) for fintech limits and SaaS entitlement equally well.

Test your next promotion before it goes live.

→ Start free at lexq.io

---

Related

• Resolving VIP Tier Discount Stacking with a Mutex Group — the full rule definition, decision trace, and edge cases
• Testing a Rule Change Before Deploy with Impact Simulation — measuring a promotion's blast radius on real orders
• How to Stop Deploying Code for Every Business Rule Change — the general case behind the checkout example