Build for Shopify review - Discount usage in loyalty program

Hello Shopify team,

We have received a report from your team during our Build for Shopify review process, and we want to discuss one query regarding section 5.5.3 – Use a single redeem code per discount.

We would like to share additional context about our current architecture and explain why fully adopting this approach is not feasible for our use case.

Our discount generation logic is built around customer-specific and dynamically generated rewards, which introduces several important constraints:

  1. Dynamic reward logic
    A significant portion of our rewards are dynamic (variable amounts, conditions, expiration dates).
    Migrating to a single discount with multiple redeem codes would require a complete rewrite of our rewards engine, as discounts are currently generated based on per-customer parameters.

  2. One discount per customer by design
    Even when rewards share the same nominal value, they often differ in:

    • expiration date

    • eligibility rules

    • reward context
      As a result, we still need to generate a separate discount object for each reward instance to preserve correct behavior.

  3. Security and non-transferability
    Our business logic intentionally issues discounts for a single customer only.
    This is a strict requirement from many of our merchants to prevent:

    • sharing discount codes between customers

    • reuse of rewards by unintended users

    • fraud activities

  4. Each discount is therefore tightly bound to a specific customer, both logically and technically.

  5. Per-customer expiration dates
    Many rewards include an expiration date that is unique per customer (e.g. X days after redemption).
    This makes it impossible to manage all codes under a single discount entity without losing correctness or introducing complex synchronization layers.

  6. Admin-side edits and data consistency
    If a shared discount is edited directly in the Shopify Admin, it may cause a desynchronization with our internal database, as our system treats each discount as an immutable, customer-scoped reward artifact.
    By generating isolated discount objects, we ensure data consistency and predictable behavior.

  7. We would also like to note that our current implementation follows the intent of the “Single Redeem Code per Discount” guideline.
    Each discount is created with a single, unique redeem code, issued for one specific customer and intended for one-time use.
    This approach helps us prevent code sharing and reuse, while maintaining predictable and controlled discount behavior for merchants.

To summarize, while we understand the intent behind section 5.5.3, our current implementation does not violate the core principle of controlled, single-use discounts.
However, due to the highly dynamic, customer-specific, and security-driven nature of our rewards system, consolidating multiple codes under a single discount entity is not technically viable without compromising core functionality and merchant requirements.

We are, of course, open to discussing alternative approaches or adjustments if you believe there is a compliant path that would still allow us to preserve the guarantees described above.

1 Like