Hi everyone — hoping someone from the Shopify team here can help us understand one of the BFS requirements we’ve been asked to fix.
Why we’re asking here
After submitting our app, we received a list of required fixes. One of them seems pretty illogical when applied to how our app works. Since the emails now come from a no-reply address, we’re going through Partner Support — but the responses we’ve received so far are very brief and really frustrating.
Context: what our app does
Our app is a loyalty platform that lets merchants create multiple loyalty programs (points, VIP tiers, etc.). Each program can have many rewards, and each reward is implemented as a separate discount (code-based or automatic).
Each reward has its own configuration — included/excluded products, tag requirements, VIP tier, point cost, order minimums, combinesWith, references to the specific reward or program, etc.
So even if two rewards have the same output of “10% off,” they’re fundamentally different discount nodes with completely different logic and constraints.
How it works technically
-
Merchant creates a reward in our app.
-
We call discountCodeAppCreate, attach our Discount Function, and pass all reward parameters through metafields + combinesWith.
-
On the storefront, the customer activates a reward in our widget, and we apply its code via the Storefront API.
-
Shopify runs the discount function → the function reads metafields → validates → returns the calculated discount.
So the app naturally produces multiple discounts of the same type, but they are not duplicates — they behave completely differently.
The BFS requirement we received
5.5.3 Use a single redeem code per discount
Your app must use discountRedeemCodeBulkAdd to create any discounts with multiple redeem codes. Don’t use the Admin GraphQL API to create multiple discounts with the same value but different redeem codes.
Our interpretation
We assumed this means - if an app needs multiple redeem codes for the same discount, it should use discountRedeemCodeBulkAdd.
That obviously makes sense for some use cases (like marketing).
But our app never creates “the same discount with different codes.” Every reward = its own independent discount with distinct logic. So we explained this in detail.
The BFS reply
The second message we received was:
For each discount type you offer, you should be able to use the discountRedeemCodeBulkAdd mutation if you create multiple redeem codes for that specific type.
The requirement is not strictly limited for marketing.
This reply seems to assume:
“multiple discounts of the same type” = “one discount with multiple redeem codes”
If taken literally, it would mean that if an app has 3 Discount Function types, it should only ever create 3 total discounts. Which obviously can’t be the intended meaning.
Why combining rewards into a single discount is impossible
Even hypothetically, if we tried unifying all rewards into one discount:
-
The discount would have multiple codes via discountRedeemCodeBulkAdd.
-
We’d store per-code settings in metafields (`{“code1”: {…settings…}, "code2: {…settings…}, …}`).
-
The function would read settings based on the entered code.
But Shopify does not evaluate multiple codes from the same discount independently.
If a discount has codes CODE1 and CODE2, and both should apply (`combinesWith` allows it), Shopify shows at checkout page:
“CODE2 is valid but not applicable. Check discount terms.”
Meaning Shopify treats it as a single discount, runs it once, and does not evaluate both codes independently.
That makes it impossible to:
* combine multiple rewards of the same type;
* have different `combinesWith` rules;
* have different `context` settings;
* have different eligibility logic;
Basically, the entire concept of separate rewards becomes impossible in this scenario.
We even explored the idea of generating combination codes — for example, with three rewards: code1, code2, code3, code1-code2, code1-code3, code2-code3, code1-code2-code3.
However:
-
the discountRedeemCodeBulkAdd limit of 250 codes is reached at just 8 rewards (2^n-1);
-
the documentation never suggests this approach is intended or supported;
-
and overall, the solution becomes very impractical.
Existing documentation
-
The discountCodeAppCreate documentation clearly anticipates apps creating multiple discounts of the same type, each with its own combinesWith, context, metafields, and eligibility logic. There’s no mention anywhere that this pattern is discouraged or incompatible with BFS requirements.
-
Additionally, the documentation for discountRedeemCodeBulkAdd states:
“You can use the discountRedeemCodeBulkAdd mutation to automate the distribution of discount codes…” (https://shopify.dev/docs/api/admin-graphql/latest/mutations/discountRedeemCodeBulkAdd)
This mutation is clearly intended for creating multiple identical redeem codes for marketing distribution.
Our app does not distribute codes, does not send emails, and does not generate bulk sets of identical redeem codes.
Other BFS-approved apps
We reviewed multiple BFS-approved loyalty apps. They also generate multiple discounts of the same type. This suggests the rule is either being misinterpreted or applies only in certain cases.
What we’re ultimately trying to understand
Maybe the actual intended requirement is simply:
“If your app needs a discount that supports multiple redeem codes, you must use discountRedeemCodeBulkAdd.”
Because if that’s the meaning — we fully agree. But our app does not create multi-code discounts, so there’s nothing for us to change**.**
Our question to the Shopify team
What exactly is the BFS team expecting us to change?
-
Are we misunderstanding the requirement?
-
Is the moderator interpreting the rule too broadly?
-
Or is there newer guidance we’re unaware of?
Any clarity or experience from others who’ve gone through BFS review would be super appreciated.
P.S. After reading other threads here, I’m kinda realistic about the chances of getting a reply — but I’ll still try. We can’t enable our ads because the issue with fake clicks hasn’t been resolved, and we can’t mitigate the problem by targeting only logged-in users until we obtain BFS status. At the same time, we can’t obtain BFS status because of the unclear and seemingly inapplicable requirements described above. So we’re effectively stuck in a cycle we can’t break without clearer guidance on Shopify’s side.
