Shopify App Store / Billing infrastructure overhaul

Shopify App Pricing
A new standard billing model: choose flat-rate, pay-as-you-go, or both

Managed Pricing has been renamed to "Shopify App Pricing" and expanded. In addition to subscriptions, usage-based billing via the App Events API is now available, and the Billing API is now treated as legacy.

On this page
  1. 30-second summary: what changed
  2. Three billing models to choose from (diagram)
  3. How usage-based billing works: the App Events API flow
  4. Three pricing structures: fixed / graduated / volume
  5. New APIs: Active Subscription / Historical
  6. Impact on existing apps (by scenario)
  7. Five key points for developers
  8. Three practical use cases
  9. A one-line summary for your pitch

130-second summary: what changed

The standard billing for the Shopify App Store has been unified under "Shopify App Pricing".
the traditional subscriptions (Managed Pricing) , plususage-based billing via the App Events API, and the two combined as a hybrid are now officially supported.
The old Billing API is treated as legacy — new apps must use Shopify App Pricing.
RENAME

Managed Pricing → renamed to Shopify App Pricing

Existing settings stay the same; only the display name changes. It now appears as "Shopify App Pricing" in the Partner Dashboard.

Usage-based billing is now officially available

Send events via the App Events API → define a meter in the Partner Dashboard → Shopify automatically handles aggregation and billing.

LEGACY

The Billing API becomes legacy

Existing integrations keep running, but it's now clear that anything new should be built on Shopify App Pricing.

2Three billing models to choose from (diagram)

A. Subscription only $29 / month A fixed amount every month Predictable revenue B. Usage only Billed only for what you use API calls / messages sent, etc. C. Hybrid $29 base + Base fee + usage The classic SaaS pattern
Shopify App Pricing now directly supports "subscriptions, usage-based charges, or combined models." Since usage-based billing was effectively unsupported until now,being able to build SaaS-style usage-based models nativelyis the biggest change this release.

3How usage-based billing works: the App Events API flow

Your app An event occurs (send, process, call) App Events API Shopify (receives) event : sent_email event : api_call Accumulates events Aggregates via meter definitions Shopify (aggregation & calculation) aggregation calculation invoicing Up to 3 steps automated Merchant billing Shows a pricing card in admin Visualizes plan and usage
Your app's responsibility

Just send events

Send the individual events that justify charges—like "how many were processed" or "how many were sent"—via the App Events API. That's it.

Shopify handles

aggregation / calculation / invoicing

It aggregates the events it receives, calculates the amounts, and even issues invoices. No need to build your own billing pipeline.

Supports negative reporting : send a negative event and charges are corrected automatically. You don't have to write your own logic for refunds or recovering from misreported charges.

4Three pricing structures: fixed / graduated / volume

fixed (flat unit price)

A fixed amount per event. The unit price is the same whether it's 10 events or 100,000. A simple, easy-to-read pricing design.

graduated (tiered)

The unit price changes by tier. Like $0.10 for 0–100, $0.08 for 101–500, and so on—a separate unit price for each tieris added up to calculate the total.

volume (volume-based)

the unit price of the tier your total usage falls into isapplied to all units at once. For 300 units, it's calculated as "all 300 at $0.08." Good for volume discounts.

The article only states "Three pricing structures supported: fixed, graduated, and volume." Since there are no specific pricing examples, caps, or minimum units, check the meter settings screen in the Partner Dashboard when implementing.

5New APIs: Active Subscription / Historical

Active Subscription API

of subscriptionsCurrent statein real time. The state is active / pending / cancelled / frozen. The big difference from before is that the state persists even after uninstall.

active pending cancelled frozen

Historical API

Full event logretrieval: you can pull install / uninstall / subscription changes / charges / credits / usage end to end. It becomes source data for accounting reconciliation and incident investigation.

The "pricing card (plan / status / usage / upcoming changes)" shown in the merchant's admin uses the same data source as the Active Subscription API. The key point is that the wording stays consistent between the app's dashboard and the admin.

6Impact on existing apps (by pattern)

StatusImpactWhat to do
New app (no billing) Now required Shopify App Pricing is the default Set pricing in the Partner Dashboard at submission
Running on Managed Pricing Label change only Billing continues Can keep running as is; it just shows as "Shopify App Pricing"
Running on the Billing API Treated as legacy Behavior is preserved Migration tooling is planned for a later date. No release timing stated
Want to add usage-based billing Available The App Events API is immediately usable by all apps See the dev docs, define a meter, and implement event sending
Only states "Migration tooling will be available soon."No specifics on the release date, whether migration is automatic, or the amount of code change required. Apps using the Billing API are fine to stay as is until it becomes available.

7Five points engineers should keep in mind

1. Don't build a billing pipeline

When you send events via the App Events API, Shopify handles aggregation, calculation, and invoicing. There's no need to build your own "usage-accumulating DB," "monthly batch," or "invoice delivery."

±

2. Correct with negative reporting

If overbilling or returns occur, you can correct charges just by sending a negative event. Idempotency and event ID management are key.

3. State persists after uninstall

The Active Subscription API explicitly states "persists beyond uninstall."Past subscription state can be carried over on reinstall= the rebilling flow design changes.

4. Historical API is the primary data for audits

You can capture installs / uninstalls / changes / charges / credits / usage all as logs.Less need to build up your own evidence for accounting reconciliation and dispute handling.

legacy App Pricing

5. The Billing API is legacy = drop it from your options for new builds

It explicitly states: "continues to function but is now legacy. All apps should use Shopify App Pricing going forward."No longer choosing the Billing API for new developmentis the right call. For existing assets, wait until a migration tool is released.

8Three use cases you can apply in practice

events / month
USE CASE 1

Moving email / SMS / recommendation delivery apps to "per-send billing"

Challenge
With flat-rate plans, serving large merchants tends to run at a loss, yet building your own usage-based billing is heavy once you factor in invoicing and credit.
Approach
Send a "send completed" event via the App Events API → define a graduated / volume meter → arrive at a hybrid structure of base fee + usage.
Impact
Small merchants can start cheaply, while large merchants pay only for what they use = achieving a low adoption barrier and profitability at the same time.
Technical notes
Make event sending idempotent (design it so the same event_id isn't double-counted). On returns and cancellations, correct with negative reporting.
$
USE CASE 2

Eliminating merchant inquiries about "my billing doesn't add up"

Challenge
On subscription changes, freezes, cancellations, and reinstalls, the "app-side display" and the "Shopify-side billing" drift apart and eat up support effort.
Approach
Render the in-app billing screen from the Active Subscription API response. Align it to exactly the same source as the admin pricing card.
Impact
Discrepancies like "the app says active but admin shows cancelled" disappear by design.A major reduction in support ticketscan be expected.
Technical notes
The states active/pending/cancelled/frozen cover all four types, and decide the UX for the frozen state (how to present feature restrictions) in advance.
install charge usage uninstall
USE CASE 3

For accounting / audit: auto-generate monthly reports with the Historical API

Challenge
App revenue reports are run off Partner Dashboard screenshots, so they're unusable until accounting re-tallies them.
Approach
Hit the Historical API in a daily batch and feed installs / charges / credits / usage into your own BI / Sheet to automate the monthly close.
Impact
Investigating invoice discrepancies becomes a matter of "querying the logs with SQL."The basis for audits and revenue recognition is all backed by primary data.
Technical notes
Data granularity, rate limits, and retention period aren't documented. Before going to production, pull a day's worth of data with a small app and verify the structure and size.

9A one-line summary you can use in a proposal

"Shopify app billing—subscription, usage-based, and hybrid—can now be built officially Shopify App Pricing is now unified.
Send events via the App Events API, and Shopify handles aggregation, calculation, and billing.
The Active Subscription / Historical API also lets you reconcile what the app and the admin display.
Required for new apps, with the Billing API now legacy = going forward, Shopify App Pricing is the only choice."