Weaverse LogoWeaverse
All Articles
Paul Phan
11 mins read

Shopify Just Made Usage-Based Billing A First-Class Citizen. Your Stripe Integration Is About To Look Quaint.

Shopify App Pricing made usage billing native. July 2026 previews App Events in Analytics alongside ShopifyQL, charts, annotations, and targets.
#shopify#hydrogen#app-pricing#usage-billing#shopify-analytics#shopifyql#platform-engineering#headless-commerce
Shopify Just Made Usage-Based Billing A First-Class Citizen. Your Stripe Integration Is About To Look Quaint.
Table of Contents

Shopify quietly rebranded Managed Pricing as Shopify App Pricing on May 12, 2026.

Read the changelog and it looks like a rename.

Read the docs and it looks like Shopify just absorbed the entire app billing layer that every indie developer used to wire up themselves.

Usage-based pricing is now native. The Billing API is legacy. Webhooks for subscription updates are gone — Partner API queries take their place. And the App Events API turns "charge per merchant action" from a Stripe-and-prayer integration into a four-line Partner Dashboard configuration.

For Hydrogen merchants and the agencies who run companion apps for them, this changes the math on what's worth building and what's worth buying.

What Actually Shipped On May 12

Shopify App Pricing replaces Managed Pricing as the default billing solution for new app submissions.

Three pricing models, all configurable in the Partner Dashboard without writing billing code:

  1. Recurring charges — free / monthly / yearly / monthly-with-yearly-discount plans
  2. Usage-based pricing — fixed, graduated, or volume structures, metered through the App Events API
  3. Combined — recurring fee plus usage on top, the hybrid most real apps actually want

The Billing API still functions but is marked legacy.

Shopify hosts the plan selection page. Free trials, proration, test charges, plan switching, downgrade scheduling — all handled by the platform.

The piece that matters most for developers building on Hydrogen and adjacent surfaces: usage-based billing is finally first-class, not a custom Stripe integration glued onto the side of a Shopify app.

The App Events API Is The Real News

The App Events API is how usage-based billing actually works under the hood.

You define a meter in the Partner Dashboard.

Your app sends events.

Shopify aggregates, calculates, invoices — and supports negative reporting for automatic charge corrections when something gets refunded or cancelled downstream.

Three pricing structures supported on top of the meter:

  • Fixed: $0.01 per event, every event
  • Graduated: first 1,000 events at $0.01, next 9,000 at $0.005, etc.
  • Volume: everything in a tier priced at that tier's rate

This is the pricing model anyone who's run a real SaaS knows you eventually need — and the one every indie Shopify app has been hacking together with Stripe Billing, webhook glue, and a custom subscription reconciliation cron.

That work is now somebody else's problem. Specifically, Shopify's.

July 21 Update: App Events Are Coming To Shopify Analytics

Shopify is extending App Events beyond billing and developer monitoring. In developer preview, approved apps can declare supported standard events, send them through the same App Events API, and make that activity queryable by merchants in Shopify Analytics.

The query surface is ShopifyQL:

FROM app_events
SHOW emails_sent
GROUP BY app_name
TIMESERIES day

This is not generally available yet. App Events in Analytics is open to approved apps through an early-access program, and the preview currently supports declared standard events. A 202 Accepted response from the App Events API only confirms receipt. Analytics processing happens asynchronously and can still reject an event that does not match an accepted declaration.

The broader analytics stack matters just as much as the event pipe:

  • Apps can mark eligible metafields as analytics-queryable dimensions alongside Shopify store data.
  • Apps can run documented, versioned ShopifyQL queries through the GraphQL Admin API.
  • Analytics web components can render Shopify-native metric cards and charts inside an embedded app without a separate charting, currency, or locale layer.
  • Annotations can mark events such as a campaign launch directly on merchant charts with app attribution.
  • Metric targets let merchants set goals and compare actual performance against them.

That changes the architecture decision for supported merchant-facing analytics. The default used to be a second data store, ETL jobs, a charting library, and a reporting UI that never quite matched Shopify admin. Apps can keep more of that workflow inside Shopify, where merchants already inspect sales and operational data.

For Weaverse, the interesting possibility is not another vanity dashboard. It is connecting storefront operations to merchant outcomes. A future integration could report approved events such as a page publish or campaign launch, annotate the relevant date, and let a merchant compare the change against Shopify metrics in the same analytics environment.

Weaverse does not currently claim to emit those Shopify Analytics events. The preview also requires approval and supported standard-event definitions. The practical next step is to validate which composition events Shopify accepts and whether they answer a real merchant question before adding another telemetry stream.

Three New APIs Replace Three Old Patterns

Shopify App Pricing comes with three new Partner API surfaces. Each one replaces a workflow that used to live in the indie developer's codebase.

1. Active Subscription API → replaces "what plan is this merchant on?"

Query activeSubscription(appId:, shopId:) on the Partner API and you get the live contract state: active plan, billing period, current cycle, subscription items with pricing and usage, discounts, pending updates.

The key behavioral change is in the docs: "the query returns the live contract state, not a derived view of historical events."

Translation: stop maintaining a local mirror of subscription status that drifts the moment a merchant downgrades. Ask Shopify, in real time, and trust the answer.

This API persists beyond uninstall, which matters for re-engagement flows and reactivation campaigns where the merchant disappears and then comes back two weeks later.

2. Historical Events API → replaces webhook subscription tracking

The root events query on the Partner API returns a full event log: installs, uninstalls, plan changes, cancellations, freezes, charges, earnings, credits.

Subscription lifecycle event types are explicit:

  • SUBSCRIPTION_CREATED
  • SUBSCRIPTION_UPDATED
  • SUBSCRIPTION_CANCELLATION_SCHEDULED
  • SUBSCRIPTION_CANCELED
  • SUBSCRIPTION_FROZEN
  • SUBSCRIPTION_UNFROZEN

Default window is 30 days, max range 365, page size 250 with cursor-based pagination.

This replaces three Billing API webhooks: APP_SUBSCRIPTIONS_UPDATE, APP_PURCHASES_ONE_TIME_UPDATE, and APP_SUBSCRIPTIONS_APPROACHING_CAPPED_AMOUNT.

Webhook-driven subscription state was always a leaky abstraction — ordering matters, retries are noisy, you end up reconciling against an admin GraphQL query anyway. Killing that pattern in favor of "query the source of truth when you need it, replay history when something looks wrong" is the kind of API redesign you only get to do once a decade.

3. App Events API → replaces Stripe-for-usage

The third API is the consumption-event ingestion endpoint. Your app posts events. Shopify meters them. Invoicing handles itself.

The reason this matters: every Shopify app that wanted usage-based pricing before this had to choose between:

  • Bolting on Stripe Billing and reconciling two billing systems
  • Using the Billing API's usageRecord create mutation and writing your own meter
  • Pricing flat-rate and leaving margin on the table

Now there's a fourth option, and it's the path the platform actively prefers.

What Changes For Hydrogen App Developers Specifically

If you build a companion app for a Hydrogen storefront — a search service, a personalization layer, a B2B catalog tool, a review widget — your monetization model just got a lot more interesting.

You can now charge per query, per recommendation served, per catalog sync, per quote generated. Fairly. Transparently. With the merchant seeing exactly what they're paying for in their admin billing card.

That last part is underrated. Shopify added a merchant-facing billing card on the app settings page that shows current plan, subscription status, usage charges, and upcoming pricing changes — including downgrades. The same information is available via the Active Subscription API.

Merchants get transparency. Developers get a metering primitive they didn't have to build. Both sides win, and Shopify takes its cut as the platform.

This is the pattern AWS uses, the pattern Stripe uses, the pattern every successful API-first platform converges on eventually. Shopify joining that club for its app developers is overdue and welcome.

The Migration Story Is The Thing To Watch

Here's what the docs actually say, verbatim:

"Existing apps with active charges on Managed Pricing or Billing API: Your current billing continues without changes. Migration tooling will be available soon to support the transition to Shopify App Pricing."

"Available soon" is doing work in that sentence.

If you have an existing app on Managed Pricing, you're already on Shopify App Pricing — the rebrand was automatic. Nothing breaks.

If you have an existing app on the Billing API with custom plans, you keep running. Until migration tooling ships, you can't move existing paid merchants to the new system. You can configure new plans for new apps in the meantime, but the cutover for live apps is still gated on tooling Shopify hasn't shipped yet.

The realistic read: expect the migration window to open over the second half of 2026, expect early adopters to hit edge cases, expect the canonical path to be Active Subscription API queries replacing whatever local subscription tracking you currently maintain.

If you're building a new app today, you start on Shopify App Pricing. No question.

If you're running a Billing API app that works, you wait for tooling, then migrate deliberately.

If you're somewhere in the middle — Managed Pricing customers — you're already migrated and just need to know the new APIs are sitting there waiting for you.

Why This Is Post #4 In The Platform-Engineering Story

The pattern is getting hard to ignore.

Last six weeks of Shopify changelog, in order:

  • April 9 — Hydrogen April 2026 release, SFAPI 2026-04, proxy mandatory, backend consent mode
  • May 6 — App deployment in CI/CD GA for all apps (app automation tokens GA)
  • May 12 — Shopify App Pricing GA, usage billing native via App Events API (this post)
  • May 21 — Shopify CLI 4.0 with SemVer + auto-updates
  • May 27 — Build App Home as a UI extension (Preact admin, API 2026-07)

Every one of these takes a piece of infrastructure that used to live in the app developer's codebase or the agency's runbook and moves it into the platform.

CI/CD tokens replace ad-hoc deploy scripts and 90-day Partner Dashboard token rotation. CLI 4.0 replaces "guess what version of @shopify/cli everyone on the team has installed." App Pricing replaces custom Stripe integrations and webhook-driven subscription state machines. App Home extensions replace iframe-hosted admin UIs.

Running a serious Shopify app or a serious Hydrogen storefront in 2026 looks less like "indie shop with Node and a Postgres database" and more like "small platform-engineering team consuming platform primitives." Billing, deployment, auth, surfaces, telemetry — Shopify is shipping the layer underneath your product, and the smart move is to take the help.

The agencies and shops we work with on Hydrogen builds have noticed. The ones moving fastest stopped writing custom billing flows six months ago and started architecting their apps around whatever the platform was going to ship next.

That bet just paid out again.

What To Do This Week

Three things.

1. If you ship a Shopify app, read the migration doc and the Active Subscription API reference end to end. You don't need to migrate today. You need to know what migrating will look like when tooling drops.

2. If you're scoping a new Hydrogen companion app, design for usage-based pricing from day one. The friction that used to exist around "we'd love to charge per query but billing is a nightmare" is gone. The pricing model that was always the right answer for API-heavy apps is now the path of least resistance.

3. If you're running a Billing API app with custom usage tracking, audit your reconciliation logic against the new event model. When migration tooling ships, the apps that already think in SUBSCRIPTION_* events will move in hours. The apps that maintain hand-rolled subscription state machines will move in weeks.

For teams without the cycles to map the platform changes onto a Hydrogen roadmap themselves, this is exactly the kind of work our team takes on — quoting and scoping Hydrogen builds and companion-app integrations against the platform primitives Shopify keeps shipping. Talk to us when the migration calendar starts feeling crowded.

The Bottom Line

Shopify App Pricing isn't a rename.

It's the platform absorbing the billing layer the same way it absorbed deployment in May and admin UI hosting in May 27's App Home extension changelog.

Usage-based pricing went from "build it yourself with Stripe and pray" to "configure it in the Partner Dashboard and stop thinking about it."

The Billing API still works. The webhooks still fire for legacy apps. Nothing breaks today.

But the writing on the wall is clear: by the time migration tooling ships and the second wave of new apps lands, the developers who designed their pricing models around App Events from day one will look prescient, and the ones who didn't will be paying off custom-billing tech debt for two more years.

The platform is offering to do the boring work for you. Take the deal.

Sources

Reactions

Like
Love
Celebrate
Insightful
Cool!
Thinking

Join the Discussion

Never miss an update

Subscribe to get the latest insights, tutorials, and best practices for building high-performance headless stores delivered to your inbox.

Join the community of developers building with Weaverse.