Shopify App Pricing: The next generation of app billing

[Soufiane_Ghzal]

Hi @jzaz that’s a great update, looking forward to trying it as it might simplify pricing for client and help offering them more fair and flexible prices that grow as they grow.

With that being said I was wondering if you’ve considered the situation where the pricing is abused and the merchant is billed a lot more than they expected?

For example an ill-intended app developer, or simply because of a bug (with the rise of AI slop apps that will eventually occur).

Let’s use a stupid example on purpose. If an app charges for the number of times a button is clicked on the storefront, , there is no bugs it’s what was intended to be charged, but it would clearly be an abuse of the system.

Or the case of a bug the app starts sending billing events, that are hard to figure out for the merchant, but still they would pay for something they’ve not used.

Or even an app that on the purpose registers more events than actually used in a way it’s hard to detect by the merchant.

Just wondering if you’ve anticipated cases like that?

Thank you

[Jaron_Smith]

@jzaz For usage-based charges, how should we handle cases where the same unit has different pricing across countries?

For example, SMS rates vary by country, so the cost of sending one SMS can differ depending on the destination.

[Chris_Eaton]

I’m trying to implement a percentage based usage charge, for example X% of total order value. Its not clear how to structure the payload in the usage payload - there’s currently a documentation gap around the percent usage charge - all the examples are for unit price.

Asking Shopify Support I got this response:

“After digging into this, it looks like you’ll want to send whole dollars, not cents. So for a $100 order at 1.9%, send value: 100.”

So I wouldn’t send in the calculated value - Shopify will perform that on their side. Maybe that’s obvious for some, wasn’t for me.

Following up, they responded to my question as to where this documentation lives:

“It looks like this is a documentation gap, our Public docs only document the quantity-style models (Fixed/Graduated/Volume per unit), they don’t explain what value means in PERCENTAGE mode at all. This is something we’ll raise with our Billing/Engineering teams so they can update our documentation to clarify this to Partners.”

So hopefully they’ll document this soon, but maybe this can help others in the interim.

[jzaz]

How many plans do you think would be enough?

[daryl]

I have 9 volume based plans - I guess 10 would be great.

[jzaz]

How do you help merchants navigate 9 plans? Could you share what that looks like?

[daveb]

If I have three plans, and include graduated overages, and the overages increase by an order of magnitude per plan tier, then the pricing estimator on my app landing page seems to default to the middle plan, making my cheapest tier calculate and display ALL of those overages, such that the cheapest tier then appears to be cheaper only than the most expensive tier. Something is amiss with how the estimator chooses the default value to set the overage sliders at. Maybe it sets the overage sliders to the maximum of the free graduated price/events of the middle plan?

[Felix_Ilett]

Hey @jzaz

Just playing with the app store listing price preview slider and have a few questions

• The preview slider is 0 - 3000, will that be standard for all? Slider is quite touchy and getting it to land on an exact number is very hard.

• It currently shows the estimated price, which adjusts as you slide up - but beneath the estimated price it states “Plus usage charges” which reads as though there additional usage costs beyond the already adjusted estimate that includes usage charges…

[Drewski]

@jzaz How is Shopify handling app review testing with Managed Billing / Shopify App Pricing?

I currently have an app in review that was flagged for “broken” managed billing because the reviewer couldn’t switch between plans. The suggested method of creating private $0 plans for testing is not feasible, as the review dev site domain changes with each review session.

Are app reviews paused or is there a solution to get around this?

[sebastian.pisula]

I’d like to share one of our billing and plan-selection use cases, because I’m not sure whether scenarios like ours will be supported with Shopify App Pricing.

In most of our apps, merchants currently see 3 pricing tiles, but in reality these represent two types of plans:

• DEV STORE TEST — a free plan for stores on the Development plan
• a paid {PLAN NAME} available in monthly and yearly versions (yearly with a discount)

For example, a merchant may see:

• DEV STORE TEST
• SHOPIFY PLUS — monthly
• SHOPIFY PLUS — yearly

or equivalent variants for other app modes.

How this currently works

1. Development stores

If the store is a Development store, the merchant can only select:

• DEV STORE TEST

All other plans are visible, but disabled.

Technically, selecting DEV STORE TEST simply marks the store with the appropriate app plan. This could just as easily happen automatically in the background without requiring any user interaction.

2. Production stores

If the store is not a development store, the merchant can only select paid plans assigned to their store type, while DEV STORE TEST remains visible but disabled.

We also have what we call “app modes”

This is our internal term for how the app behaves depending on the Shopify store type and available capabilities.

Currently we have three modes:

• plus
• csa
• non_csa

plus

Shopify Plus stores.

We detect this during app installation using Shopify API data.

csa

Stores with:
Carrier-Calculated Shipping (CCS) enabled.

non_csa

All remaining stores that do not qualify for the above groups.

App mode affects both pricing and functionality

This is a very important distinction.

It’s not only about different pricing — the app functionality itself depends on the app mode.

For example:

• features available on Shopify Plus do not work on lower modes,
• merchants on non_csa cannot select plus plans,
• merchants on plus can be manually downgraded by support to csa or non_csa, but not the other way around.

Current plan structure

We currently have the following plan groups:

• DEV STORE TEST
• SHOPIFY BASIC (non_csa)
• GROW & ADVANCED (csa)
• SHOPIFY PLUS (plus)

Each production plan has:

• a monthly version,
• a discounted yearly version.

The biggest question regarding Shopify App Pricing

Right now it’s unclear to me whether Shopify App Pricing supports this kind of advanced dynamic plan-selection logic.

More specifically:

• Will it be possible to dynamically show and hide plans?
• Will it be possible to disable plans depending on the store type?
• Will we be able to decide which plans are available based on Shopify API store data?
• Will it be possible to restrict plans based on:
  • Shopify Plus,
  • CCS,
  • Development stores,
  • other store parameters?

In our current setup, this flow works very well both from a UX and business perspective, so I’m trying to understand whether a similar approach will still be possible after migrating to Shopify App Pricing.

Additional questions for the Shopify technical team:

• Are there plans to support condition-based plan visibility?
• Will it be possible to mark plans as available only for specific store types?
• Will developers be able to programmatically control plan availability via API?
• Is Shopify planning an official “app modes” / capability tiers mechanism?
• What is the recommended flow for apps whose functionality depends on:
  • Shopify Plus,
  • CCS,
  • other store capability flags?

[abdulrahim]

Hi.
Can we use ActiveSubscription API when developing a new app right now? It says that the release candidate for query is 2026-07? can we submit a new app for review now with this query?

Partner API reference

[jzaz]

Hi Miguel, thanks for your questions

If you were on Managed Pricing, you’re now on Shopify App Pricing automatically but your existing billing and code continue to work exactly as they did. Nothing requires an immediate code change. New subscriptions still work through the same APIs you’re using today.

What’s new is that you now have the option to define usage charges on your plans and use our new APIs (Active Subscription, Historical Events). We’re encouraging partners to migrate to the new APIs because we think they are just better, but the existing APIs still function. There’s no forced migration.

Regarding the dev store test charges, this is an issue we’re actively looking into resolving.

[jzaz]

I hear you on localization via API.

What do you mean by “external apps” ? Do you mean apps that run outside of the Shopify Admin?

[jzaz]

Yes, you can start to use ActiveSubscription API for new apps you’re submitting for review.

[jzaz]

Hi @Min_Liu,

Thank you for writing this. We are aware of the issue regarding test charges on dev stores. We’re working on shipping a fix for this ASAP.

Appreciate hearing what billing solutions you’re hoping for. Will take this back to the team!

[muchisx]

Brilliant @jzaz, thank you for clarifying!

In regards for techniques on reconciliation jobs, are Partner API webhooks being considered, should we rely on polling the Partner’s API to keep our systems up-to date with current merchant’s subscriptions?

Big thanks for your work, appreciate it!

[Merchbees]

Yes the apps run outside of Shopify admin.

[cobn]

Does Shopify App Pricing support instant plan changes (e.g. immediate upgrades), the way the Billing API does today?

Is the team currently working with established/high-volume apps as part of the rollout? My concern is around timing: with the Billing API now flagged as legacy, it would be tough on developers if its deprecation timeline moved faster than App Pricing’s feature parity (one-time charges, usage caps, yearly + usage combinations, etc.). Would be helpful to understand how you’re thinking about that transition.

[Patrick_Jakubik]

Hey folks,
excited to see the recent updates to the Partners API. We’re currently stitching together the Partners API and the Admin GraphQL appSubscriptions API, and ideally we’d love to drop the dependency on the Admin API entirely, so we can still see the full picture even after a shop uninstalls the app.

I had Claude review the recent Partners API changes against our codebase, and here are the blockers it flagged:

1. No way to fully reconstruct subscription history on Partners.
The new events query with SubscriptionStatus(state: CREATED) gets us close, but two things block actually using it as a replacement for Admin’s allSubscriptions:

• SubscriptionStatus has no subscriptionId / chargeId / legacySubscriptionId field, so there’s no stable way to tie a state: CREATED event back to its corresponding SubscriptionChargeActivated row (which carries charge.id). Joining by shop + occurredAt is fragile.
• Plan.trialDays on the event — does it reflect post-activation trial extensions? Docs just say “number of trial days for the plan”. trialDaysRemaining is a live snapshot, so it’s not useful on historical events.

Either a dedicated query:

shop(id: ID!) {
  appSubscriptions(first: Int, after: String): SubscriptionConnection!
}

returning ActiveSubscription-shaped objects (with status + authoritative trialEndsAt), or just adding a stable subscription/charge ID + authoritative trialEndsAt onto SubscriptionStatus, would unblock this.

2. Trial info on Charge / SubscriptionChargeActivated doesn’t reflect extensions.
Admin’s AppSubscription.trialDays is authoritative — it reflects extensions granted after activation. Partners’ billingOn doesn’t. That’s the only reason we still hit Admin: compute createdAt + trialDays and join it back to the charge event. An authoritative trialEndsAt directly on Charge / SubscriptionChargeActivated would eliminate the join — and would also fix Gap 1 if mirrored on SubscriptionStatus.

3. GID prefix mismatch between Admin and Partners.
Admin: gid://shopify/AppSubscription/123. Partners: gid://partners/Charge/123. We strip to the numeric suffix to join. ActiveSubscription.legacySubscriptionId already solves this for the active sub — extending that pattern to all subscription/charge objects (and ideally SubscriptionStatus events) would mean we wouldn’t need to regex-strip IDs.

Nice-to-haves

• Charge.shop / Charge.app references on SubscriptionChargeActivated.charge so events are self-describing — right now we rely on the query being scoped to one app to know which app an event belongs to.
• Uniform pagination across Partners — HistoricalEventsPageInfo differs from the standard PageInfo shape, which trips up generic pagination helpers. Fine if intentional, but worth documenting.
• A way to fetch the merchant’s contact/owner info alongside ShopReference (currently we still need Admin’s Shop.email etc. for support flows).

Closing 1 + 2 would let us drop the Admin call entirely. Curious if others are stitching the same data, and whether any of this is already on the roadmap.

[sebastian.pisula]

I’ve been analyzing the topic a bit — going through the documentation and community discussions — and there’s one thing I’m wondering about.

We’re currently using the Billing API. When making requests to the Active Subscription API:

Partner API reference

we receive handle: null for existing subscriptions.

I’m trying to understand what the recommended approach is to make sure existing subscriptions have a non-null handle.

Specifically:

• Is there a way to automatically map existing Billing API subscriptions to App Pricing plan handles?

• Will this require the upcoming migration tool?

• Or will handle remain null for legacy subscriptions until the merchant switches to a new plan / resubscribes?

I’m trying to understand the correct way to handle plan mapping for existing merchants currently using the Billing API.