Shopify App Pricing for Vibe Coders: What You Still Have to Build

You have vibe coded the useful part of your Shopify app. The interface works. The AI agent helped with OAuth, routes, database calls and a polished onboarding flow.

Then you ask one last question:

Add a Free, Pro and Business plan to my Shopify app.

The agent produces a pricing page, a few buttons and some convincing looking billing code. You click through it once on a development store. It works. Pricing feels done.

It probably is not. Billing is where an app stops being a demo and starts making decisions about money, access and trust. A wrong button colour is irritating. A wrong entitlement check can give away a paid feature, lock out a paying merchant, or keep access alive after a cancellation.

Shopify can own the charge without owning your application permissions.

This guide starts from zero. It explains what Shopify App Pricing does, what your app still needs to do, why the DIY path grows quickly, and where a reusable pricing layer can remove work without pretending to be your entire application.

What Shopify App Pricing actually is

Shopify App Pricing is the current recommended billing approach for public apps on the Shopify App Store. You define plans in the Partner Dashboard, Shopify hosts the plan selection page inside Shopify admin, and Shopify automates common billing work such as recurring charges, free trials, proration, upgrades and downgrades.

It supports free, monthly and yearly recurring plans, usage based pricing and combined recurring plus usage models. It also supports public and private plans. Shopify, “Shopify App Pricing”

For a new public app, this is good news. You do not need to invent a checkout, collect card details, calculate proration or build a merchant facing plan approval screen.

That second column is the part a pricing page mockup does not solve.

Fig. 01 — The billing handoff

The complete flow, without the jargon

A simple recurring plan flow looks like this:

1. A merchant opens your app
2. Your server identifies the authenticated shop
3. Your server asks Shopify for the current subscription
4. No valid plan: send the merchant to Shopify’s hosted pricing page
5. The merchant selects and approves a plan
6. Shopify redirects the merchant to your configured welcome link
7. Your server queries Shopify again to verify the live contract
8. Your app grants only the features mapped to that verified plan

Shopify’s hosted page follows a predictable admin URL pattern. After approval, Shopify appends a plan_handle to the welcome URL; external welcome URLs also receive the shop domain. These values are useful for navigation and reconciliation. They are not proof of access.

Challenge 1: the internet contains two billing eras

This is the first trap for a vibe coder. Search for “Shopify app billing” and an AI agent can find tutorials for the older manual Billing API alongside current Shopify App Pricing documentation. Both are real. They are not the same integration.

If your app is migrating from manual pricing, the problem becomes harder: Shopify says existing Billing API subscriptions can continue while new subscriptions use App Pricing, so the app may need to recognize both systems until old contracts end or migrate. Shopify’s migration guide

Before asking an agent to write billing code, tell it which billing system the app uses.

Challenge 2: a plan name is not an entitlement model

A merchant sees “Pro”. Shopify and your code need a stable machine identifier: the plan handle. Your application then needs to translate that external handle into an internal plan with explicit capabilities.

free  -> exports: 10/month,  teamMembers: 1
pro   -> exports: 500/month, teamMembers: 5
scale -> exports: unlimited, teamMembers: 25

Shopify plan handle
        ↓
internal plan
        ↓
features + limits

Scattering checks such as plan === "pro" across React components and API routes seems fast at first. Later, a renamed plan, yearly variant, private plan or new limit forces you to hunt through the whole repository.

A central plan definition gives the AI agent—and your future self—one place to change handles, features and limits. Unknown handles should not quietly inherit the nearest paid tier. They should resolve to a restricted state until you deliberately map them.

A configured free plan also deserves an explicit mapping. Do not assume “Shopify returned no active contract” automatically means “this merchant selected Free”. Those are different business states and may need different onboarding or access behaviour.

Challenge 3: the redirect is a clue, not authority

After a merchant approves a plan, Shopify redirects to your welcome link with the plan handle. It is tempting to read that query parameter and immediately unlock Pro.

const plan = url.searchParams.get("plan_handle");

if (plan === "pro") {
  session.hasPro = true;
}

Query parameters can be copied, edited, replayed or attached to the wrong session. Shopify explicitly instructs apps to query the Partner API after approval to confirm subscription status before granting paid access.

Verification means comparing the authenticated shop, the expected plan handle and the current Partner API response. The redirect can trigger a fresh lookup. The lookup—not the URL—decides access.

Fig. 02 — A signal is not proof

Challenge 4: the current plan lives in another API

With current App Pricing, your server queries activeSubscription(appId, shopId) on Shopify’s Partner API. The response can include the billing period, current cycle, line items, prices, usage, discounts and pending updates. It returns null when that public app has no active App Pricing contract for the shop.

This creates plumbing a generated pricing page will not show:

• 01 Store the Partner organisation ID, app GID and access token securely.
• 02 Keep Partner API credentials in server only code.
• 03 Derive the shop identity from the authenticated session—not an untrusted browser parameter.
• 04 Handle GraphQL errors as well as HTTP 401, 429 and 5xx responses.
• 05 Normalize Shopify’s response before the rest of the app sees it.
• 06 Decide what happens when Shopify cannot be reached.

The raw API response should not leak into every loader and component. Give the rest of the application a smaller result such as active plan, features, limits, reason and whether the result was verified.

Challenge 5: hiding a button is not access control

Vibe coded applications often begin with client side gating. If the merchant is on the Free plan, hide the export button. That improves the interface. It does not protect the export endpoint.

You normally need both. Every paid capability needs a server side decision close to the operation it protects. A determined user can call an endpoint without clicking your button. A background job has no button at all.

The server enforces the plan. The interface explains it.

Challenge 6: subscriptions move after checkout

The happy path is “merchant chooses Pro and arrives on the welcome page”. Production contains more states:

Current Shopify App Pricing does not use subscription update webhooks for these changes. Shopify says to use redirect parameters for merchant driven flows and query the Partner API for lifecycle changes that happen without a redirect, including cancellations, freezes and expirations.

That means your app needs a refresh strategy. Resolve on sensitive requests, cache briefly where appropriate, and invalidate when installation or pricing actions make stale data dangerous.

Fig. 03 — The contract keeps moving

Challenge 7: caching creates a money shaped trade off

Calling the Partner API before every render is wasteful and vulnerable to throttling. Caching forever is worse because cancelled merchants can keep paid access. The right answer is not simply “add Redis”. You need policy.

In a single Node process, an in memory cache may be enough to begin. In a multi instance deployment, each process can hold a different answer unless you use shared caching or a deliberate invalidation and fresh resolution strategy.

Failure also needs its own state. “No subscription” and “Shopify did not answer” are not the same event. Both can deny a paid operation, but they should produce different logs, messages and recovery paths.

Challenge 8: one successful click through proves very little

Shopify lets developers exercise App Pricing on development stores without real charges, including a private zero cost test plan and no charge testing options. Use that facility for more than the happy path.

A useful test matrix includes:

• 01 clean install with no selected plan
• 02 configured free plan, paid plan and trial
• 03 immediate upgrade and scheduled downgrade
• 04 cancellation, frozen shop and reinstall
• 05 edited, replayed or mismatched redirect parameters
• 06 unknown plan handle
• 07 Partner API timeout, throttling and malformed response
• 08 stale cache in one process and across multiple instances

Unit tests can prove mapping and guard behaviour. Integration tests can prove API error handling. Manual testing on a clean public development app proves that your Partner Dashboard configuration, welcome links and real Shopify lifecycle agree with the code.

If you want to build it yourself

You can. Shopify publishes the pieces you need. Build them in this order so your AI agent has a narrow job and an explicit trust boundary:

1. Confirm you are using hosted App Pricing on a public app
2. Configure plan handles and welcome links in the Partner Dashboard
3. Create a server only Partner API client with explicit error handling
4. Normalize activeSubscription into a small internal pricing state
5. Map plan handles to features and limits in one configuration
6. Add server guards, then client side presentation helpers
7. Verify redirects against fresh subscription state
8. Add caching, invalidation, observability and the full test matrix

Give the coding agent the current Shopify documentation, your exact stack, your plan handles and the rule that URL parameters never grant access. Ask for tests alongside each boundary. Do not prompt “add billing” and accept whatever era of Shopify code it remembers.

We use Shopify hosted App Pricing on a public app.
Our stack is TypeScript + React Router.

Use Partner API activeSubscription as billing authority.
Never grant access from plan_handle query parameters.
Keep credentials server side.
Unknown or unverified state must not receive paid access.
Protect server actions as well as UI controls.

First propose the state model and test matrix.
Do not write code until both are explicit.

Where Silver Vault App Pricing Kit helps

If your goal is to build your own Shopify product—not spend several weeks rediscovering pricing plumbing—our Silver Vault App Pricing Kit gives you a tested, reusable TypeScript pricing and entitlement layer to adapt inside an existing app.

It includes source for:

The kit is designed for Node.js 22.12+, React Router 7.12+ and current public Shopify apps using hosted App Pricing. Its documentation includes integration guidance and instructions an AI coding agent can follow with less guesswork.

It is reusable developer source, not a complete Shopify application or finished production system. It does not add OAuth, your database, deployment configuration, usage based billing or a legacy Billing API migration. You must review, test and adapt it before production, connect it to your authenticated shop context, configure your plans and validate the result against your own development app.

You still own the app. The kit gives the pricing boundary a stronger place to start.

Fig. 04 — Start from a coherent layer

The decision is build versus adapt—not build versus learn

Buying source code does not remove the need to understand billing. You should know which system is authoritative, where access is enforced, how failures behave and what your plans promise. That knowledge is part of operating a paid application.

The choice is whether you want to design and prove every pricing primitive from scratch, or adapt a focused implementation whose state model, guards, redirect verification, cache behaviour and tests are already visible.

For a tiny prototype, building the minimum yourself can be reasonable. For a public app approaching submission, the edge cases stop being theoretical. That is the point where paying for a reusable foundation can be cheaper than debugging access decisions after merchants are already being charged.

A note about Shopify’s current billing model

Shopify’s billing platform is evolving. This article reflects Shopify’s public documentation as of August 2026, including the Partner API Active Subscription flow introduced for current Shopify App Pricing. Verify the latest documentation and supported API version before implementing or migrating billing.