Shopify App Pricing: 8 Public Plans and Free Testing

Shopify app pricing just got twice as much room to breathe. On July 9, 2026, Shopify raised the public-plan limit per app from 4 to 8 and the private-plan limit from 10 to 15 — and, in the same update, made every plan testable at $0 by App Review and development stores, and taught the App Events API to accept negative and fractional values.

Most coverage will restate those changelog bullets. The more useful question for app partners is what to rebuild: a tier structure designed around a hard four-plan ceiling looks very different from one designed with eight slots, native usage credits, and fractional cost units. In an App Store that Digital Applied’s own prior 2026 research put at over 13,000 published apps and roughly $890M in annual developer revenue, pricing architecture is a competitive surface, not a form field.

This playbook covers what actually changed on July 9 and what didn’t, a before/after map of the whole update, how the three new free-testing paths work (including the one gotcha a developer hit on day one), what negative and fractional App Events unlock operationally, the API mechanics that constrain your design, and a concrete tier-restructuring plan for the four new public slots.

The July 9 developer changelog entry bundles three separate changes to Shopify App Pricing: higher plan limits (public 4 → 8, private 10 → 15), no-charge plan testing for reviewers and development stores, and expanded value types on the App Events API — negative values for adjustments and credits, and fractional values such as 1.5.

The framing matters. Shopify App Pricing itself is not new — it reached general availability on May 12, 2026 as Shopify’s default billing system, configured during app submission in the Partner Dashboard, replacing the older Managed Pricing system. July 9 is an iteration on that system, not a new billing product. If your app already opted in during the May rollout, everything here is additive; if you haven’t, the decision calculus in Section 06 applies first.

It also lands in a busy season for Shopify’s developer platform — the plan-limit change follows the June 2026 wave of Shopify developer-platform changes that retired Scripts in favor of Functions. The pattern across both: Shopify is consolidating bespoke workarounds into first-class platform primitives.

Four public plans forced a familiar compromise: Free, Starter, Pro, and one of either Enterprise or an annual variant — never both. Any further segmentation had to be crammed into usage meters or handled off-platform. Doubling the public ceiling to eight, and raising private plans to fifteen, removes that constraint for the large majority of apps.

The structural limits underneath each plan are unchanged, and they still shape what a “plan” can be: per Shopify’s App Pricing documentation, a plan supports up to five active usage meters, each with up to six pricing tiers, across fixed, graduated, and volume-based tiering structures. Eight plans × five meters × six tiers is a lot of design space — the scarce resource is no longer slots, it’s merchant comprehension.

No single Shopify page lays the whole update out side by side — the plan limits, the testing model, and the API value types live in three different docs. So we compiled it. Each “before” cell comes from Shopify’s own documentation of the prior state, including the “$0 private test plan” workaround the App Pricing overview itself documented as the standard pattern.

Before July 9, testing a paid plan meant a genuine QA gap. The standard pattern — documented in Shopify’s own App Pricing overview — was to create a $0 private “test plan” purely so App Review and your own dev stores had something to subscribe to. That stub never exercised the billing behavior real merchants would hit: no real price, no real usage meters, no real upgrade path. The alternative was eating live charges during QA. The update replaces that with three distinct no-charge paths.

One boundary worth stating precisely: the reviewer plan-selection change is sourced to the July 9 changelog and the community-forum corroboration — Shopify’s formal review-process documentation still describes the same four-status lifecycle (Draft → Submitted → Reviewed → Published) and has not been rewritten around the new flow. Treat the plan-selection change as an operational update layered onto the existing review lifecycle, not a revision of the published review criteria. And since testing access now crosses Partner-org boundaries, it lands alongside Shopify’s Partner identity-verification push — verified Partner accounts are increasingly the key that unlocks these workflows.

The least flashy line in the changelog may be the most consequential for usage-based apps. The App Events API — the endpoint apps use to report billable usage — now accepts negative values, used to adjust or credit previously reported usage, and fractional values such as 1.5. The changelog states the prior constraint plainly: “Previously, event values were limited to whole numbers greater than 0.”

Operationally, that whole-numbers-only constraint forced ugly workarounds. Mid-cycle downgrades couldn’t be prorated through the API. Over-reported usage meant a support ticket and a manual credit. And any unit that didn’t divide cleanly into integers — AI tokens, fractional compute-hours, partial shipments — had to be rounded or rescaled. With negative and fractional values, credit notes, reversals, and fine-grained metering become native API operations. For developers packaging usage-based AI features into a monetizable app, fractional cost units are the difference between billing what the feature actually costs and billing a rounded approximation of it.

Real-world demand for exactly this was visible in the announcement thread: one developer raised a “postpaid risk” concern and asked for explicit ordering control on usage events plus per-event description fields on plan pages — one developer’s concern, not a resolved Shopify commitment, but a signal that the change targets genuine billing-correction edge cases rather than cosmetic API polish.

New value types don’t change the plumbing. Per Shopify’s App Events technical reference, events are sent one at a time to the events endpoint — batch requests are explicitly not supported — so high-volume metering needs client-side queuing and retry logic on your side.

Three system-level constraints from the App Pricing docs matter just as much when you restructure tiers. First, usage charges must be billed monthly and can’t be combined with yearly-only recurring plans — so an annual plan and a usage-metered plan are structurally different products, and the new slots are how you offer both. Second, Shopify App Pricing currently has no native usage-cap feature — spend limits have to be enforced in your own application logic, which is exactly why the postpaid-risk concern in the forum thread resonates. Third, opting in is a one-way door for the legacy path: once an app adopts Shopify App Pricing, it can no longer create new recurring application charges via the legacy Billing API. And note the integration cutover that predates this update: since April 28, 2026, plan identification flows through the Partner API with plan handles rather than the old subscription-webhook charge-ID pattern.

The worst response to the new ceiling is shipping eight plans because you can. The right response is fixing the compromises the four-slot limit forced. Here is how we’d allocate the freed slots for a typical usage-based app — as an illustrative framework, not a vendor-published recipe.

Step back and the trend is legible: taken together — more plan granularity, native credits and reversals, and fractional cost units — the July 9 update reads as Shopify aligning its billing rails with usage-based economics, the pricing model that AI-heavy apps in particular default to. That fits the broader platform direction we mapped in agentic Shopify Plus app stacks that lean on usage-based billing: the apps growing fastest meter consumption, and the platform is removing the friction between metering and money.

Looking forward, two pressures seem likely to shape the next iteration. Merchant-facing pricing pages will get more granular as partners restructure into banded tiers, which raises the stakes on plan-page clarity. And the absence of a native usage-cap feature — combined with negative values making corrections cheap — suggests spend-control tooling is the most conspicuous remaining gap; developers are already asking for ordering guarantees on usage events in the announcement thread. Neither is announced; both are where the current design points. If you’re restructuring a Shopify app’s pricing — or deciding whether usage metering fits your product at all — our ecommerce development services cover exactly this kind of billing-architecture work.