@jzaz I think the video should be used as the first piece of media on this post. It could show the old-fashioned billing first, then the new system, to better illustrate the team’s point. Also it would be good at start of documentation at shopify.dev.
With the first image, in an app where the event is something like image generation, SMS, etc. If a merchant triggers 200 of these events right after installation on day 1 and then deletes the app, under that model they’d only be billed $49 / 30 = $1.63 — even though those 200 events already cost the developer real money.
As a developer trying to switch to Shopify App Pricing, I originally referenced the first image as my model, but I now realize the model shown in the video is the one I should follow.
I think beside technical names(fixed, graduated, volume) ,use case names might be good on documentation like:
High-cost events (image generation, SMS, etc.)
Simple low-cost events (product generation)
Monthly subscription apps
Rather than registering each in-app function as its own event, could we use a unified ‘credits’ event — where, for example, an SMS invocation costs 10 credits and an email invocation costs 2 credits — so that the billing section doesn’t get cluttered for apps with 4–5 event types?
Thank you for the detailed overview of the new API. I have a couple of questions:
I think it would be useful to be able to provide an optional price when reporting a charging event via the API. This would allow us to: A. Offer special prices for individual stores or during limited marketing campaigns. B. Freeze prices for a particular shop (or all of them), ensuring that price changes made in the Dashboard UI don’t affect them.
I’m curious whether the new API addresses the issue of bad actors who create a fresh store, install an app, consume some usage-based functionality, then block their payment method and abandon the store – only to repeat the whole process with a new store. This pattern is so widespread that many app developers have had to build their own protection mechanisms to defend against it. It would be really helpful if Shopify could step in and tackle this at the platform level, rather than leaving each developer to solve it on their own.
In general, I still believe this subject involves so many edge cases that are difficult to capture in a reasonable configuration UI, which is why it still makes sense to have a programmatic configuration option that lets us set things up exactly the way we need.
Reading some online discussions about Mantle shutting down, I noticed some people were speculating that it was Shopify pushing them to close for some reasons.
Whether it’s true or not, I’ don’t know but I wouldn’t be surprised they’ve been pushed by something external because they seemed to be quite successful and profitable and close enough to Shopify so they get mentioned in this pricing update thread.
Also, as far as I know, they haven’t explained why they would close, which is suspicious.
@jzaz Any plan to expose subscription name and test flag from legacy Billing API on SubscriptionStatus events? Currently those subscriptions come back with handle: null and description: "". There is also no name or test fields that are present on SubscriptionChargeActivated -> charge
Stores consuming usage without valid payment method is a big issue!
I was actually implementing One Time Purchases instead of Usage Based Pricing just for protection against smammers, however even that seems unprotected by the current billing system and will probably remain unprotected by the Managed billing. A most likely fake indian store managed to buy multiple thousand dollars worth of features within the first few hours of using the app, and even though invoices for one time purchases usually appear right away, for this store they still don’t. Even the multiple Shopify support agents were not enough, to find a solution or give hint on what is going on.
Shopify app billing system should be the thing to trust. We should know that if a payment appears in App History, that we will also see it in Payouts. Right now, that is not the case!
This is not only about Shopify introucing a UI, this is about well designed system that is reliable and cannot be easily exploited.
There are two parts to this:
Transparency on the status of payments, so I can see if I should block the store from using app features. Perhaps even a webhook.
And the actual solution. An in app purchase coming through = me knowing that I will get paid. No crap with the store blocking payments. A payment is a payment, especially One Time purchases.
Shopify staff, if you need any more information, let me know and I will be happy to follow up (for more info on the issue I described, the Shopify Support ticket ID is 68555414)
I’m wondering if you have any plans, or if you could add to the roadmap, the ability for us to charge by Location. Essentially, the same way that Shopify POS Pro works. There are a lot of app developers now building for Shopify POS (us included), and it would be extremely helpful for us to be able to charge by location. Essentially, it would be extremely helpful for us to be able to allow merchants to optionally activate a monthly subscription on POS locations that they choose.
The FAQ and docs say that “Shopify App Pricing uses the Partners API for subscription data, not the GraphQL Admin API. Subscription changes aren’t delivered via webhooks.”
However, my testing of Shopify App Pricing enabled draft app (development version of the published public app) on my org’s development store suggests otherwise. After selecting a plan on the Shopify-hosted plans page and accepting or cancelling a test charge, I get the app_subscriptions/update webhook fired. I also get a populated legacySubscriptionId when querying activeSubscription via the Partner API version 2026-07.
Are the docs outdated, or is it a weird behaviour of draft apps? I prefer receiving webhooks as before.
In the active subscription query docs, "The activeSubscription query and all supporting types are available in the 2026-07 release candidate and unstable". I’m assuming this note is outdated, as the 2026-07 version is the latest stable version. Please confirm.
App Events API is currently unstable. Any idea when a stable version will be available?
You’re right that the plan-change webhooks still fire today but they are not fully App Pricing compatible (they don’t include usage details), so please treat them as working today but deprecated when building app logic.
Per your docs questions - they should be updated now, please take a look.