I’d like to raise a (potential) serious issue affecting SaaS apps that use credit-based pricing. This loophole allows users to exploit Shopify’s daily prorated billing to consume far more credits than they paid for — and Shopify explicitly prohibits us from blocking plan changes that could prevent this abuse.
Real-World Example (All within the same billing cycle)
Let’s assume a 30-day billing cycle starting Oct 1.
Date
User Action
Plan Price
Credits Granted
Credits Used
Oct 1
Subscribes to $5 plan
50 credits
+50
Uses all 50
Oct 3
Upgrades to $15 plan
150 credits
+150
Uses all 150
Oct 4
Upgrades to $30 plan
1000 credits
+1000
Uses all 1000
Oct 5
Downgrades back to $5 plan
50 credits
+50
Uses all 50
Each upgrade resets their credit balance to the full plan amount.
What they paid (Prorated by Shopify):
Oct 1–2 on $5 plan: ~$0.33
Oct 3–3 on $15 plan: ~$0.50
Oct 4–4 on $30 plan: ~$1.00
Oct 5–30 on $5 plan: ~$4.33
Total billed: ~$6.16
What they consumed:
50 + 150 + 1000 + 50 = 1,250 credits
If the app normally charges ~$30 for 1000 credits, the user extracted $40+ of credit value for $6.16 in actual billing
Result: The user gets ~7X more value than paid. The app loses money.
Recap of the Problem
Shopify prorates money perfectly, but credit-based apps grant full credits instantly.
Users can stack credits by switching plans multiple times in the same billing cycle.
We are not allowed to block upgrades or downgrades to prevent this abuse. Shopify has contacted us warning our app could be delisted if we do.
Shopify’s suggested solution is to prorate credits per day (e.g. drip 3.5 credits per day), but:
This creates a poor user experience (users expect full access immediately after upgrading)
It adds complex server logic, tracking partial usage over time
Users will leave 1-star reviews if they upgrade and only see a tiny credit allocation
It increases database complexity and processing load with daily “credit drip” jobs
I could be entirely wrong, but if that is true and I’m not missing some API feature to protect agains this, then:
What I’m asking for:
-A recommended formula to fairly allocate credits when users switch plans mid-cycle.
-Ideally, built-in APIs or documentation from Shopify on how to:
Access number of days remaining in cycle
Detect plan-switch timestamps
Apply prorated credit entitlements in a consistent, user-friendly way
-Sample code or reference implementation from Shopify would be extremely valuable and prevent hundreds of developers from reinventing fragile logic.
That is a tricky one. The proration of the reoccurring subscription is technically correct.
But it sounds like you’re attempting to tie usage charges as a reoccurring subscription, which opens the door to this kind of abuse.
Since you’re ultimately selling credits, why not use usage charges instead? That way the merchant has the flexibility to buy credits and there is no downgrade proration option to abuse?
If you offer multi-tiered features, you can still offer multiple plans that automatically downgrade/upgrade based on tier.
Thanks for the response and I I get what you’re suggesting, and I agree that in theory usage-based billing is closer to what we’re actually selling (credits = metered consumption). But in practice I don’t think it’s feasible for our use case, and I don’t think it solves this class of abuse for a lot of credit-based apps.
Why? because
Usage billing in Shopify requires the merchant to pre-approve a capped spend amount.
That sounds fine until you look at how our app (and a lot of similar apps) is actually used. We’re not always doing small, incremental actions. We have “bulk generation” features…. for example: optimize all products, rewrite all descriptions, generate alt text for all images, etc. A single click can trigger work across 2,000 products.
Under the usage model, we would need to create an appUsageRecord for each chunk of work and make sure we never exceed the merchant’s approved cap.
That means, mid-job, we’d have to constantly check how close we are to the cap and stop before we cross it.
That’s not just a billing call — it’s control flow. We’d now need every bulk task to:
Do 1 item,
Calculate cost,
Check remaining cap,
Bill it,
Repeat,
Potentially stop mid-run.
For bulk actions, this becomes extremely resource-heavy. We’re talking thousands of iterations per job, hammering our own queue + Shopify’s billing API just to make sure we don’t breach the cap.
The UX is terrible if we have to stop in the middle.
Imagine a merchant clicks “optimize all 2,000 products,” and we get through 417, then we have to cut them off because they hit their usage cap for this billing window. Now we’re telling them:
“You approved $X, you’ve hit it, please go raise your cap in Shopify and then try again.”
From the merchant’s point of view, we “broke.” They don’t care about the billing cap mechanics. We just look unreliable.
Operationally this shifts risk back onto us, not Shopify.
If we accidentally run too far in a bulk job (which is easy to do with async processing, retries, queues, etc.), we eat that cost because we can’t bill usage over the cap.
So now our engineering priority becomes “don’t accidentally overrun their cap,” instead of “do the job well.” That’s not great.
It also doesn’t fully address plan hopping.
Usage billing solves the “I upgrade for one day and take all the credits” problem, but only if we fully rebuild the product around per-event billing + hard stop logic. That’s basically a new billing strategy and a new job processing strategy. It’s not just “switch your pricing model,” it’s “re-architect how bulk actions run, meter, checkpoint, and fail.”
To be super clear: I’m not against usage billing in principle. For metered APIs with predictable per-call cost, it makes sense.
But for high-volume batch features where merchants expect “do all of this now,” usage billing creates a new set of problems:
We have to constantly poll how close they are to their usage cap.
We have to invoice in tiny slices as we go.
We have to potentially pause mid-batch and tell them to go change billing settings.
We still take the blame in reviews if the job stops.
What we’re asking Shopify for is something a little different:
A supported, compliant way to prevent people from harvesting multiple full “monthly credit buckets” in one billing cycle via upgrade/downgrade abuse.
Without forcing us to rebuild everything into a per-call meter that has to self-throttle live.
Right now there’s no first-class pattern for that. That’s the gap we’re trying to solve.
I definitely understand the challenges of working with usage based charges and coordinating timely notifications with usage caps.
But the problems you’re mentioning are definitely solvable within your own app’s business logic. Whereas asking for a change or additional complexity to the reoccurring based subscription logic is a tall order to ask, or at least I wouldn’t expect Shopify to change it’s policies anytime soon.
In your case, it sounds like this abuse is a clear present issue that’s hurting your margin.
You can definitely implement idempotency to prevent multiple usage charges per unit of bulk work. Additionally you can use the Shopify Admin API to retrieve the current usage balance, or subscribe to webhooks when the balance is close to exhaustion.
You can even build a self-serve way for merchants to update their usage cap, in your case present it before the work starts. That was my approach and it’s worked out pretty well.
Does this mean that you’ll still occasionally have issues with merchants missing these notifications? Sure, happens to me despite in-app notifications, email notifications, etc.
But still I would take that problem over merchants abusing the system.
So yes, it’s a bit more leg work on your part to manage the cap and time the usage charges appropriately - absolutely. No doubt about it. But I would pick a solution that I have some control over, vs a solution that I don’t have much control over even though it’s more simple to implement.
Each upgrade resets their credit balance to the full plan amount.
Result: The user gets ~7X more value than paid. The app loses money.