We’ve started the migration from Mantle to Shopify App Pricing, but we’re seeing some major blockers we’re unsure on how to resolve or work around.
In order of importance:
1. Yearly subscriptions don’t support usage prices
Currently we have yearly plans with usage charges, eg.: $700/year with 2000 orders included every month and usage charge of $15 for every 100 orders above. This let us offer significant discounts compared to monthly subscriptions for the merchants opting to pay annual.
2. Max 20 merchants on private plans
As our product expands in functionality and value it provides we sometimes change the pricing and functionalities offered in each plan. As a goodwill gesture to our early customers we always grandfather in existing merchant so they can keep their current pricing and features.
This results in private plans with a lower pricing/more functionality used by many more then 20 merchants. It feels that App Pricing pushes developers to charge existing merchants more as well if they want to raise prices.
3. Hard limit of 15 private plans
At the moment we have over 50 private plans. When working with bigger Plus and Enterprise brands they often have unique support, onboarding, functionality and integration requirements. To meet these requirement we often create custom plans for these merchants matching their exact requirements and budget.
4. No packet based usage pricing
Eg.: 2000 orders included, then $15 for every 100 orders. A workaround could be to send one event every 100-order but it will look weird on the pricing page (eg.: it’ll say 20 100-order, instead of 2000 orders)
5. No usage caps for plans
Some of our plans have hard upper limit on usage, eg.: Up to 500 orders since many merchant prefer a flat subscription then usage based pricing. They don’t want to have surprise bills and usage fees and rather manual upgrade if neccessary.
It would be handy if we could set a maximum usage cap for plans, currently we would need to store the plan limits as a feature flag in a different tool.
Are any of these planned to be resolved natively?
If not any best practices or recommended workarounds would be appriciated.
