BFS Category vs. App listing Category

Built for Shopify
1

One of our apps has been assigned Discounts as the BFS category, and we are planning to reposition our app to another category as it is more suitable as a category for our app’s use case.

Just wanted to know if changing the category for the BFS has any impact on the App’s visibility and ranking for the search results on the Shopify app store. The primary and secondary category has already been configured for the app and is working fine for us.

2

Hi @Jay_Makwana :waving_hand: thanks for reaching out.

That’s a good question. I’ll look into this for you and I’ll loop back here when I have more info to share.

3

Hi @Jay_Makwana

Circling back on your question here now that I’ve done some digging:

Your app listing’s primary and secondary categories (the ones you control) are what drive search benefits and visibility - those aren’t touched by a BFS category change.

When it comes to changing your BFS category, the BFS category is something that’s evaluated by our team rather than something you can change on your end - either when your app comes up for annual review if it’s already been approved, or when you apply for BFS if it hasn’t.

If your app still offers discount functionality, then your assigned BFS category shouldn’t change in the review process. If your app functionality changes away from discounts entirely, then your assigned category is re-evaluated if one of the two scenarios above occurs.

I hope this helps and let me know if you have any other questions.

4

Hi Wes,

Thanks for the clarification here, that really helps.

We had a follow-up question regarding our BFS categorization. Our app is currently placed under the Discounts category, but a significant portion of our core functionality relies on draft order creation, which is actively used by many of our merchants on a daily basis.

Because of the restrictions under the Discounts category, we’re finding it difficult to continue supporting these core features, and it doesn’t seem like the right fit for our app.

Given this, could you help us understand:

  • If there is a more suitable BFS category for apps like ours that rely on draft orders as part of their core functionality?
  • Or what would be the recommended approach in this situation to stay compliant without disrupting existing users?
5

Hi @Jay_Makwana, thanks for the follow-up. I dug into this further and here’s what I found.

Although it’s difficult to say for sure without looking at the specifics of the app firsthand, it sounds like the restriction you’re running into is a specific BFS requirement for apps in the Discounts category: apps must not create draft orders to give custom discounts.

Draft orders with custom discounts are designed for one-off, merchant-driven flows rather than automated customer-facing ones, and they don’t have the same reporting tools. You can find the full requirement here:

Regarding your questions:

  1. There isn’t a different BFS category that would let your app use draft orders for custom discounts. The BFS category is based on your app’s observed functionality, so as long as your app offers discount functionality, it falls under the Discounts category and its requirements. The only way to move out of the Discounts category would be to remove all discount functionality from the app entirely.

  2. The recommended path to stay compliant is to separate your discount functionality from your draft order creation so they don’t overlap. If your app’s draft order flow doesn’t apply custom discounts through the draft order itself, and your discount logic runs through the proper discount APIs instead, that should satisfy the requirement without disrupting your merchants’ existing workflows.

I hope this helps and let me know if I can clarify anything further on my end here.

6

Hi Wes,

Thanks again for the detailed explanation earlier—it really helped us understand the requirements better.

We wanted to clarify one aspect of our implementation and get your guidance on the best way to handle it.

In our case, draft orders are not primarily used for applying custom discounts. Instead, we use them for:

  • Allowing merchants to define custom shipping (including free shipping scenarios)
  • Adding a custom product option as an upsell

Given this, the draft order flow is more about enabling flexible checkout behavior rather than just discounting.

With that context, we wanted to ask:

  • Is there an alternative or recommended approach within Shopify to handle these use cases without relying on draft orders?
  • Are there specific APIs or patterns you would suggest that align better with BFS requirements?

We want to make sure we’re following the right approach while still supporting these core merchant needs.

Appreciate your guidance on this as well!

7

Hey @Wes-Dev-Shopify

any thoughts on my last response,

Thanks.

8

Thanks for the additional context @Jay_Makwana, that really helps clarify your app’s functionality. Here are some purpose-built APIs for these use cases that you could check out as alternatives to draft orders:

Custom shipping / free shipping

One thing that would help me point you in the right direction: is your “custom shipping” use case more about discounting/free-shipping logic on top of existing rates, or about offering entirely new shipping rates that the merchant’s configured carriers don’t provide?

If it’s the former, the Discount Function API (Discount Function API) (with the cart.delivery-options.discounts.generate.run target could be a good option to explore. There’s a free shipping with currency thresholds example in the docs).

If it’s the latter, the CarrierService API (DeliveryCarrierService - GraphQL Admin) might be something to explore, which lets you return real-time custom rates that show up at checkout natively, no draft order needed.

Separately, if any of your flow involves renaming, reordering, or hiding existing delivery options at checkout, the Delivery Customization Function API (Delivery Customization Function API) might be a good fit.

Custom product / upsell

  • For pre-purchase upsells, you could explore checkout UI extensions (Build a pre-purchase product offer checkout UI extension). There’s a tutorial specifically for building a pre-purchase product offer. With that said, it’s worth noting that pre-purchase checkout UI extensions render on the information/shipping/payment steps, which are Shopify Plus only.
  • For non-Plus stores, a common pattern is a theme app extension (About theme app extensions) (app block) on the cart or product page that adds the upsell to the cart via the Storefront API or Ajax Cart API.
  • You could also explore post-purchase checkout extensions (https://shopify.dev/docs/apps/build/checkout/post-purchase) for offers that appear after checkout but before the thank-you page.
  • If your “custom product option” is more about bundling or attaching an add-on item to a cart line, the Cart Transform Function API (Cart Transform Function API) lets you expand a cart line into multiple items with their own prices, which can be a good replacement for using draft orders to attach extras.

Each of these is a supported, BFS-aligned path, so moving to them should help resolve the Discounts-category restriction while keeping the merchant experience the same (or better, since these run natively in checkout instead of routing through a draft order).

Let me know if you have any questions about this, I’m happy to dig in deeper.