Logically, a discount model can be anything, so you can't assume you can program all cases in advance. Nor can anyone answering your question be completely sure what you actually need. However, assuming you get the usual kinds of discounts found in the real world...
A big question is whether the discounts will be programmed, or if you want users to enter them. As mentioned above, you can't never have them be programmed, but usually the goal is to try to make it more data entry like for common cases, rather than programming them all. This applies to some extent even if programmers are used to create all the discounts.
Martin Fowler mentions "Individual Instance Method" in "Analysis patterns: reusable object models" as part of how to implement "Posting Rules" for accounting systems, but the rules seem fairly similar to yours. I'd give more detail but it's a copyrighted work and
For a user interface, you either need to come up with use-cases that are fairly simple, or else build an interpreter and query builder. Possibly both, one for simple cases and one more advanced. If you do write an interpreter, this is likely a fairly good case for using the Interpreter pattern, since it's relatively simple to code compared to a parser generator, and the slower parse time probably won't really matter. (If you like using parser generators don't let me stop you).
Don't try to do everything with an interpreter though - at some point you are just programming in your own crummy language, so you might as well use a real one. If your interpreted language supports functions (it probably should support calling them - defining them is dubious) those can be coded in a real language. Don't go further down this road than you have to.
No matter what you do, eventually someone will want the discount to be based on whether they purchased within 30 business days of a promotion - where business days count only if there was no holiday in the region defined by either the store's postal code or the client's postal code. So don't try to design the perfect system in advance - assume you will sometimes need to write code for new kinds of discounts and design accordingly.