# Wix eCommerce / Velo - Automatic Discounts Service Plugin

**URL:** <https://forum.wixstudio.com/t/wix-ecommerce-velo-automatic-discounts-service-plugin/79105>\
**Category:** Ask the community\
**Tags:** question, cms, wix-stores, code, wix-studio\
**Created:** [July 27, 2026, 12:08pm UTC](https://forum.wixstudio.com/t/wix-ecommerce-velo-automatic-discounts-service-plugin/79105 "2026-07-27T12:08:36Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Julie\_Bergen](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/julie_bergen/32/121032_2.png) [@Julie\_Bergen](https://forum.wixstudio.com/u/Julie_Bergen)\
**Post date:** [July 27, 2026, 12:08pm UTC](https://forum.wixstudio.com/t/wix-ecommerce-velo-automatic-discounts-service-plugin/79105/1 "2026-07-27T12:08:37Z")

</div>

I’m building a sponsorship system for a Wix Studio eCommerce site using Velo and Kickflip.

I already have:

- Custom Discount Trigger service plugin
- Sponsorship CMS
- Usage tracking

I can determine whether a customer is eligible and exactly how many complimentary strings they have remaining.

My business rule is:

- Sponsor has 2 complimentary strings remaining.
- Cart contains 3 qualifying string products.
- First 2 strings should receive a 100% discount.
- Third string should remain full price.

Kickflip has confirmed their products use the normal Wix cart and checkout flow and that Automatic Discounts are the recommended integration point.

**My question:**

Is there any supported Wix eCommerce extension point that allows custom business logic to control the number of qualifying line items that receive an automatic discount?

If not, what is the recommended architecture for implementing annual product entitlements?

---

<div class="post-metadata">

**Author:** ![noahlovell](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/noahlovell/32/118920_2.png) [@noahlovell](https://forum.wixstudio.com/u/noahlovell)\
**Post date:** [July 28, 2026, 1:07pm UTC](https://forum.wixstudio.com/t/wix-ecommerce-velo-automatic-discounts-service-plugin/79105/2 "2026-07-28T13:07:17Z")

</div>

I might be missing something - but can you share a few more details about what you’re trying to achieve?

We have Discount Rules - [Introduction | API Reference](https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/extensions/discounts/discount-rules/introduction?apiView=SDK) - but I’m not sure that it answers your question.

Would you be able to explain the ideal flow and then we can take it from there 🙂

---

<div class="post-metadata">

**Author:** ![Julie\_Bergen](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/julie_bergen/32/121032_2.png) [@Julie\_Bergen](https://forum.wixstudio.com/u/Julie_Bergen)\
**Post date:** [July 29, 2026, 7:51pm UTC](https://forum.wixstudio.com/t/wix-ecommerce-velo-automatic-discounts-service-plugin/79105/3 "2026-07-29T19:51:47Z")

</div>

Thanks for the response!

The goal is to give sponsored archers an annual allotment of complimentary strings while letting them use the normal Wix shopping and checkout experience.

Here’s the desired flow:

1. A sponsored archer logs into their account.
2. Their sponsorship benefits are stored in a CMS collection.
3. I can already determine:
  - whether they have an active sponsorship,
  - how many complimentary strings they have remaining for the current year,
  - which products in the cart qualify for the benefit.

4. They shop normally and can add any number of qualifying string products to their cart (including products configured through Kickflip, which still use the standard Wix cart and checkout).
5. At checkout, I want only the number of qualifying strings they have remaining to receive a 100% discount.
6. After the order is successfully completed, I record the redeemed strings against their annual allotment in my own CMS collection.

For example:

- Sponsor has **2 complimentary strings remaining**.
- Cart contains **3 qualifying string products**.
- The first **2** qualifying strings receive a **100% discount**.
- The third string remains full price.

The part I’m trying to understand is whether the Automatic Discounts extension point supports this level of custom business logic.

Specifically:

- Can a custom Discount Rule determine **which individual line items** receive a discount based on data from my own CMS?
- Can it apply the discount to only a subset of the qualifying items (for example, the first two qualifying strings)?
- Or can Discount Rules only return a simple yes/no decision for the entire cart?

If Automatic Discounts isn’t the right extension point, what would you recommend for implementing annual product entitlements like this while staying within the supported Wix eCommerce extension points?

For context, I’ve already built the sponsorship backend, CMS collections, and redemption tracking. The remaining challenge is determining how to apply the correct discount during checkout in a supported way.

---

<div class="post-metadata">

**Author:** ![Christo\_Wilken](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/christo_wilken/32/121779_2.png) [@Christo\_Wilken](https://forum.wixstudio.com/u/Christo_Wilken)\
**Post date:** [August 17, 2026, 8:19pm UTC](https://forum.wixstudio.com/t/wix-ecommerce-velo-automatic-discounts-service-plugin/79105/4 "2026-08-17T20:19:11Z")

</div>

Your third question is the right one, and the answer is yes: a custom discount trigger is a cart-wide yes or no. The response from getEligibleTriggers is just a list of trigger ids, no line item id and no quantity, and on the rule side the target is SPECIFIC\_ITEMS scoped to catalog item ids or a catalog filter, both of which name products rather than a particular line in this cart. There is no “first N units” cap anywhere in the rule object either (the docs say a rule can apply to multiple items per cart and only once per item). So the plugin can decide whether the cart qualifies, but it cannot cover two of three strings.

What can do it is one layer down. Instead of asking the discount engine to cover part of a line, hand the cart a line that is already priced at zero: catalogOverrideFields.salePrice on the cart line item sets a per-line price while the item stays a real Wix Stores product with its name, image, inventory and catalog link. Your three qualifying strings become a line of two at 0 and a line of one at full price, the cart total reads correctly, and redemption gets recorded from onOrderPaid by counting the units that were actually priced at zero on the order. The one thing the docs don’t settle is whether an elevated Velo backend on a Studio site can reach catalogOverrideFields (it lives on the eCommerce v2 REST/SDK surface and needs the Manage eCommerce admin scope; the wix-ecom-backend wrapper doesn’t expose the field). That is a ten-minute probe on your site, and it needs to catch the nasty outcome specifically: the call succeeding while the field is silently ignored, which looks fine in testing and charges an archer full price in production.

I came across your thread while looking into this kind of problem, so I built the whole thing out to see where the ceiling really is. I have a working simulation of your scenario with the allocation logic running and the code next to it. It covers your case as three lines and as one line of quantity 3, the allotment running out mid-cart, mixed carts, and a resync step, because a shopper who bumps a quantity from 2 to 4 in the cart UI otherwise walks off with four free strings. The Velo files (allocation rule, entitlements from a redemption ledger rather than a stored counter, the cart sync, the probe, and your existing trigger plugin built out so it refuses to fire when the cart exceeds the allotment) are all in there to copy. It runs on invented archers and products and there is nothing to sign up for. If you’d like to see it, say so here and I’ll share it.

If it would help, I’d be happy to look at the probe result with you once you’ve run it. Whether the salePrice route works on your site decides which of the two versions you keep.
