I run a public app on the classic Billing API with a monthly recurring charge plus a usage line for overage (extra tracked SKUs and locations). That works, but we have hit a structural problem with capped amounts and I want to check whether a different shape is acceptable before we build it.
The problem we have today
Each of our plans has its own cappedAmount. A merchant whose usage far exceeds their plan limit simply pays their plan’s ceiling, because the overage is capped. Since our smallest plan has the lowest ceiling, a very large merchant is cheapest on our smallest plan. The pricing ladder inverts at the top end.
The shape we are considering
Create one subscription per shop with two line items:
a recurring line item priced at $0.00, EVERY_30_DAYS, never modified
a usage line item with a generously sized cappedAmount
Every charge, including what merchants think of as their monthly plan fee, is then posted to the usage line with appUsageRecordCreate. Because the recurring price never changes, moving a merchant between our tiers does not require them to re-approve the subscription, and there is a single capped amount they agree to once at signup.
This is the model the Mantle billing platform used before it shut down, so it clearly worked in practice at some point. What I cannot find is any statement from Shopify about whether it is acceptable as a production pricing model for a public app.
My questions
Is a $0.00 recurring line item, with the entire merchant-facing price posted as usage records, permitted for a public app? The docs describe $0 recurring and usage prices in the context of development stores and app review, which makes me unsure whether it is intended as a production pattern.
If it is permitted, what does the App Store listing show for such a plan? Our listing currently displays the recurring price, so I would expect these plans to show as $0/month with additional charges, which seems likely to confuse merchants or fail review.
Is there a supported way to move a merchant between pricing tiers without sending them back through the subscription approval screen? That is the underlying thing we are trying to solve. The $0 recurring approach is a means to that end, not the goal.
If we later raise a subscription’s cappedAmount with appSubscriptionLineItemUpdate, that requires fresh merchant approval. Is there any pattern for sizing or adjusting caps that avoids repeatedly interrupting a growing merchant?
For context on why we are not simply moving to Shopify App Pricing: our overage is usage based, and yearly intervals do not support usage charges, so we would lose either the annual option or the overage. We are also on USD only, so that constraint is not the blocker for us, but the usage plus annual one is.
Any guidance appreciated, including a plain “do not do this”, which would save us building it.
Follow-up, because having read more of the App Pricing docs I think my original question was the wrong one.
App Pricing supports graduated and volume pricing on usage meters, up to six tiers per meter, and states that usage caps are not supported. If I have understood that correctly it dissolves the problem I described: with no cap there is no ceiling, so a large merchant cannot end up cheaper on a smaller plan. That is a much better answer than the workaround I was asking about.
Five things I would like to confirm before committing to a migration.
Is volume pricing on a usage meter the intended way to price by a scaling resource such as tracked SKUs or tracked locations, rather than fixed tiers plus a flat overage rate? Our cost genuinely scales with SKUs multiplied by locations, so a per unit meter fits the shape of the product better than buckets do.
How are individually negotiated prices meant to work alongside a meter? We have a merchant on a hand agreed flat rate that deliberately ignores usage, agreed as part of winning the account. A meter would price them by their real usage and break the commercial terms. Are private plans the right mechanism for that, and is 15 private plans with 20 stores each the hard ceiling? Negotiated deals are not something we can stop doing, so I need to understand what happens when we outgrow that.
The docs say that once you opt in to App Pricing you can no longer create new recurring application charges through the Billing API. Does that include the bespoke per merchant subscriptions we currently create for negotiated deals? If so, opting in commits us before we have proven private plans can express those terms, which makes this a one way door we would rather understand first.
Our development build is a custom distribution app rather than a public one, and the Billing API refuses to work on it. Can App Pricing be configured and tested from a custom distribution app on a development store, or does testing also require public distribution? I have seen the $0 private test plan mentioned and it sounds like the right tool, but I want to know whether distribution type blocks it. I have also seen several reports of “This feature isn’t currently available for your store” on development stores, and specifically of graduated pricing plans failing to subscribe in development, which is the exact feature we would be testing.
The migration guide says usage based subscriptions do not move until the Migration API is available, and the Partner Dashboard shows “Move subscriptions” as coming soon. Every one of our subscriptions is usage based, so none of ours can move today. Is there a rough timeline? And in the meantime, is running new signups on App Pricing alongside existing Billing API subscriptions the expected approach, with the app querying both systems to determine paid access?
Happy to be told the original question is moot. That would be the best outcome available.
Hey again @Luke, I’d say your follow-up is pretty on point. App Pricing looks like the better shape for this, but I’d test it fully before enabling it.
Just sharing a few recommendations per your breakdown there:
I’d compare graduated and volume pricing to see what works best for you. Volume pricing applies one rate to every unit once a tier is reached, so it can create pricing cliffs. Graduated pricing may be smoother: Setup usage charges
I’d also define exactly what one metered unit means for merchants. For example if it’s SKUs × locations, you may want to look at whether you’re billing a monthly snapshot or cumulative activity so events don’t accidentally double-count usage if that makes sense
Don’t enable App Pricing yet if annual + usage is required for new merchants. That combination still isn’t supported.
Test draft plans against the public app on a same-organization development store. I wouldn’t use the separate custom-distribution app for this flow: Shopify App Pricing
Plan for both billing systems during migration. New subscriptions can use App Pricing while existing usage subscriptions continue through the Billing API (at least for the time being), but your app will need to check both systems and report usage through the appropriate API: Migrate to Shopify App Pricing
I still don’t have a timeline for the migration API, so what I’d recommend is completing the preparation and testing steps now, then hold off on enabling App Pricing until the annual and negotiated-pricing constraints work for your business.
That said, it is always up to you, but just wanted to follow up here, hope this helps!
Thanks @Alan_G, that is genuinely useful and the point about volume pricing creating cliffs is one I had wrong. I had been planning to use volume, and had not spotted that applying one rate to the whole quantity means the total can fall as usage rises, which is a version of the same inversion I opened this thread about. Graduated it is.
Noted on testing draft plans against the public app on a same organisation development store rather than our custom distribution build. That answers the testing question completely.
On the annual point, I think that one may not apply to us, and I would like to check my reading. We do not offer annual today. We ruled it out precisely because a subscription cannot carry both an annual interval and a usage line, which as far as I can tell binds the classic Billing API and App Pricing equally. So enabling App Pricing would not cost us anything on annual that we are not already without. If that is right, the constraint is not a reason for us to delay. If App Pricing restricts annual further than the classic API does, that would change the answer, so I would rather ask than assume.
Two things from my earlier list are still open, and they are the two that decide whether enabling App Pricing is a door we can walk back through.
Individually negotiated prices. We have a merchant on a hand agreed flat rate that deliberately ignores usage, agreed as part of winning the account. A meter would price them on their actual usage and break the commercial terms. Are private plans the intended mechanism for that, and is 15 private plans with 20 stores each a hard ceiling? Negotiated deals are not something we can stop doing, so I need to know what happens when we outgrow that limit.
The one way door. The docs say that once you opt in to App Pricing you can no longer create new recurring application charges through the Billing API. Does that include the bespoke per merchant subscriptions we currently create for negotiated deals? If it does, then enabling App Pricing commits us before we have proven private plans can express those terms, and we would want to prove that first.
Put together: if private plans cover negotiated pricing and the 15 plan limit is not a wall, this is straightforward. If they do not, we would be trading a capability we use today for one we cannot yet replace, and I would rather understand that before flipping the switch than after.