How to Sell VST Plugins Online: Storefronts, Licensing, Activation, and Fulfillment

A practical developer guide to storefronts, payments, license delivery, activation, device limits, offline access, refunds, and subscriptions for audio plugins.

Approx. 12 min read

To sell your own VST, AU, or audio plugin online, you need more than a product page and a checkout button.

You also need a way to take payments, deliver the installer, create a license, activate the plugin, manage device limits, support offline use, and deal with refunds, subscriptions, and computer changes.

This guide is about selling a plugin you developed yourself. It does not cover reselling or transferring an existing software license.

Selling a Plugin Is a Stack

When developers prepare their first paid release, the storefront often gets most of the attention. That makes sense: customers need somewhere to read about the plugin and buy it.

But the storefront is only the visible part of the system.

Behind it, a typical setup includes:

  1. A product page or marketplace listing.
  2. A checkout and payment provider.
  3. Delivery of the installer or download link.
  4. A record showing that the customer owns the product.
  5. A way to activate the plugin.
  6. Rules for devices and offline use.
  7. Workflows for refunds, cancellations, updates, and support.

A useful way to think about it is this:

The store handles the sale. The licensing system decides whether the plugin should unlock.

Those can be part of the same platform, but often they are separate systems connected through webhooks, product IDs, and customer data. stripe_webhooks paddle_digital_products fastspring_license_management repository_facts

Start With the Sales Channel

There are several reasonable ways to sell an audio plugin. The right choice depends on how much control you want and how much infrastructure you are prepared to manage.

Audio Plugin Marketplaces

Marketplaces such as Plugin Boutique or KVR can give your product a presence in places where musicians already look for software. Both provide routes for developers to submit or list products. plugin_boutique_developer_intake kvr_developer_access

A marketplace may handle some combination of:

  • Product pages.
  • Checkout.
  • Download delivery.
  • Customer emails.
  • Promotions.
  • Order history.

The main question is what happens after the sale.

Before using a marketplace, find out:

  • Can it generate license keys?
  • Can it send purchase data to your system?
  • Does it support webhooks?
  • Can you import orders manually?
  • How are refunds communicated?
  • How are subscriptions or upgrades represented?

You do not have to use the same system for sales and licensing. A marketplace can sell the plugin while your own licensing service controls access inside it.

Your Own Store With a Payment Processor

A direct store gives you more control over branding, pricing, bundles, customer relationships, and the checkout experience.

With a payment provider such as Stripe, you can create products and prices for both one-time purchases and subscriptions. After payment, Stripe can send webhook events that your backend uses to update its database and start fulfillment. stripe_products_prices stripe_webhooks

The tradeoff is that you need to connect the pieces yourself.

A completed payment still has to be translated into something your plugin understands:

  • Which plugin did the customer buy?
  • Which edition?
  • Is the purchase permanent or recurring?
  • Which user owns it?
  • How many devices are allowed?

That translation is usually handled by your backend or a licensing platform.

Merchant of Record

A Merchant of Record can take responsibility for a larger part of the commercial transaction.

Depending on the provider and service scope, this may include payment processing, tax collection, disputes, refunds, and transaction-related support. Stripe, Paddle, FastSpring, and Lemon Squeezy all offer products or workflows relevant to digital software sales, though their exact scope and eligibility can change. stripe_managed_payments paddle_digital_products fastspring_license_management lemon_squeezy_mor_webhooks_license_api

This can reduce the amount of commerce infrastructure you need to operate.

It does not, however, automatically solve plugin activation.

The provider may know that a customer paid, but your plugin still needs a reliable way to answer:

Is this person allowed to use this product on this computer right now?

Selling VST Plugins on Shopify

Shopify can work well when you want a full ecommerce storefront rather than a simple checkout page.

It can handle product pages, customer accounts, checkout, digital delivery, and subscriptions through apps. shopify_digital_downloads shopify_subscriptions

What Shopify does not natively provide is DAW-aware plugin authorization.

A common setup looks like this:

  1. The customer buys the plugin through Shopify.
  2. Shopify sends an order event.
  3. A licensing system reads the purchased product or variant.
  4. It creates a license for the customer.
  5. The customer installs the plugin and activates it.

In this model, Shopify handles the store, while a separate licensing layer handles access inside the plugin.

Tax responsibilities depend on the services you use, your setup, and your business obligations. Shopify’s tax features should not be treated as a replacement for professional tax advice. shopify_taxes

Lightweight Digital-Product Platforms

Platforms such as Gumroad and Payhip can be practical for a first release because they reduce the amount of storefront work.

Both support software license-key workflows. Gumroad documents generating and verifying keys, while Payhip supports generated or pre-assigned keys that can later be enabled or disabled. gumroad_license_keys payhip_license_keys

This can be enough for a straightforward flow:

  1. The customer pays.
  2. They receive a license key.
  3. They enter the key in the plugin.
  4. The plugin or backend verifies it.

The important design decision is what the key represents.

It can remain the permanent proof of ownership, or it can be used once to create a license tied to a user account.

The second approach is often easier for customers over time. They redeem the key once, then use their account for future activations instead of searching through old emails for a serial number.

Payment Does Not Automatically Unlock the Plugin

This is the part that is easy to underestimate.

A successful checkout proves that a payment event occurred. It does not tell the plugin running in a DAW what access to grant.

The plugin still needs to know:

  • What product was purchased.
  • Who owns it.
  • Whether it is a permanent purchase or subscription.
  • Whether the current device is allowed.
  • Whether the payment was later refunded.
  • Whether the subscription expired.
  • Whether the plugin can continue working offline.

Payment providers use webhooks because fulfillment happens after the transaction. Your application receives the event, verifies it, updates its own records, and grants the purchased access. stripe_webhooks

Paddle describes fulfillment triggered by completed transactions, while FastSpring treats fulfillment as its own post-purchase step. paddle_digital_products [fastspring_fulfillments]

For audio plugins, fulfillment usually means more than sending a ZIP file. It also means creating a license or entitlement that can later be checked inside the plugin.

How Purchase-to-License Fulfillment Works

The basic workflow is usually simpler than it first appears.

You need to connect:

  • The provider’s product ID.
  • Your own internal product ID.
  • The customer.
  • The payment status.
  • The resulting license.

Imagine that you sell a compressor plugin through several stores.

Your internal record might look like this:

Product name: Example Compressor
Internal product ID: prod_example_compressor

Each sales platform will use its own identifier:

Stripe price ID: price_123
Paddle price ID: pri_456
Shopify variant ID: 789
FastSpring product path: example-compressor

Your fulfillment system stores the relationship between those external IDs and the protected product.

When an order arrives, it can say:

Shopify variant 789 was purchased by customer@example.com.

Your licensing system can then translate that into:

Create an Example Compressor license for customer@example.com.

Inlay product records, for example, can store external IDs used to match storefront or billing products to plugins, applications, add-ons, expansions, or editions. repository_facts

A Typical Webhook Flow

A common automatic license-delivery flow looks like this:

  1. The customer completes checkout.
  2. The provider sends a webhook to your backend.
  3. Your backend verifies the signature or credentials.
  4. It checks the event type.
  5. It reads the purchased items.
  6. It maps their external product IDs to your products.
  7. It creates the appropriate licenses.
  8. The customer receives download and activation instructions.

For example, a Stripe, Paddle, FastSpring, or Shopify purchase event can be mapped to an external product ID and used to create a customer license. stripe_webhooks paddle_digital_products fastspring_license_management repository_facts

Webhook processing should also be idempotent. Providers may deliver the same event more than once, and a retry should not create duplicate licenses.

License Keys or Account-Based Activation?

Both models can work. They solve slightly different problems.

License Keys

Keys are useful when:

  • A sales partner expects serial-number fulfillment.
  • A store cannot call your API.
  • You sell bundles or promotional copies.
  • You need to distribute codes in batches.
  • You want a simple integration with an external channel.

For example, a partner may purchase or receive a batch of redeemable keys. Each customer redeems one key and receives access to the plugin.

The main challenge is key management:

  • What happens if a key is shared?
  • Can it be redeemed more than once?
  • Which product does it unlock?
  • Can it be revoked?
  • How do you replace a lost key?

One option is to treat the key as a one-time claim code. After redemption, it becomes a user-bound license rather than remaining the customer’s permanent login credential.

Account-Bound Activation

With account-bound activation, the license belongs to a user account rather than to a text string.

The customer experience can be quite simple:

  1. The customer buys the plugin.
  2. They install it.
  3. They open it in their DAW.
  4. They click Activate.
  5. A browser window opens.
  6. They sign in.
  7. The plugin confirms that their account owns the product.
  8. The plugin unlocks.

Inlay supports this browser-based flow. When a license exists for the signed-in user and product, the plugin can unlock without requiring the customer to type a serial number. repository_facts

Account-based activation also makes it easier to manage several products and devices from one place.

Device Limits Without Unnecessary Support Tickets

Most commercial plugins need some limit on the number of computers that can be activated.

The limit itself is only part of the design. You also need to decide what happens when someone replaces a machine.

A customer may reach the limit because they:

  • Bought a new laptop.
  • Reinstalled the operating system.
  • Replaced a motherboard.
  • No longer use an older studio computer.

Without self-service device management, every one of these situations can become a support request.

A better flow is:

  1. The customer tries to activate.
  2. The system shows that the device limit has been reached.
  3. The customer removes an unused device.
  4. They continue activation.

Inlay supports configurable device limits and lets users remove unused devices during the activation flow. repository_facts

Your product page and support documentation should clearly explain:

  • How many devices are included.
  • Whether the customer can remove them.
  • Whether removed devices can be added again immediately.
  • What to do after a hardware change.

Offline Access After Activation

Audio plugins need to behave reliably in studios, on stage, and while travelling. Requiring a server connection every time the plugin loads can create unnecessary risk for legitimate users.

A more practical model is:

  1. The user activates while online.
  2. The service issues local authorization data.
  3. The plugin validates it locally on later launches.
  4. The plugin refreshes the entitlement periodically when a connection is available.

This gives the customer offline access while still allowing refunds, revocations, subscription expiration, and device changes to take effect later.

You still need to choose a policy:

  • How long can the plugin work without refreshing?
  • What happens if the licensing server is unavailable?
  • Is there a grace period after a failed subscription payment?
  • When does a revoked license stop working locally?

Inlay supports secure local access after activation, followed by later online refresh and update checks. repository_facts

What About iLok and PACE?

PACE/iLok is another established licensing approach for audio software.

It supports several activation-location models. Depending on the publisher and product configuration, access may be associated with a computer, a physical iLok, cloud authorization, or another supported location. Internet requirements also vary by model. pace_ilok

The relevant question is not simply whether to use iLok.

It is better to compare the full customer and developer experience:

  • Does the customer need an extra application?
  • Is a dongle required?
  • Can the plugin work offline?
  • Who manages device resets?
  • How does activation happen?
  • What infrastructure must the developer maintain?

For a deeper look at the tradeoffs, see Choosing a copy-protection model for audio plugins and Comparing iLok with browser-activated licensing alternatives.

Adding Activation to a HISE or JUCE Plugin

Creating the license on the server is only half of the job. The plugin must also know how to use it.

HISE

A HISE plugin typically needs to:

  • Check whether valid local access already exists.
  • Show an activation interface when it does not.
  • Start the browser activation flow.
  • Unlock protected functionality after successful activation.
  • Validate local access on future launches.
  • Refresh entitlement information when online.

Inlay provides a HISE module that handles plugin-side activation and local validation. repository_facts

The implementation is covered in Integrating InlayModule in HISE.

Developers selling expansions or other paid content can also see Protecting HISE expansions with InlayModule.

JUCE

The same lifecycle applies to JUCE plugins, although the integration happens in C++.

A JUCE plugin needs to:

  1. Check local authorization at startup.
  2. Show activation UI when required.
  3. Open the browser authentication flow.
  4. Receive and store the result.
  5. Validate access locally.
  6. Refresh the license when needed.
  7. Update the plugin state if access changes.

Inlay provides a JUCE SDK for activation and local validation. repository_facts

See Integrating product unlocking in JUCE for the integration flow.

Whichever approach you use, test it in real hosts. Activation code should be tested across DAWs, operating systems, offline sessions, plugin rescans, reinstalls, and computer changes.

Refunds, Cancellations, and Expired Subscriptions

A purchase can change state after checkout.

You need to handle events such as:

  • A refund.
  • A chargeback.
  • A cancelled subscription.
  • A failed renewal.
  • An expired subscription.
  • A restored subscription.
  • A manually revoked license.

The payment or storefront provider normally reports these changes through lifecycle events or webhooks. stripe_webhooks paddle_subscription_provisioning lemon_squeezy_mor_webhooks_license_api

Your licensing system then updates the entitlement.

For example:

Subscription status: cancelled
Paid-through date: 2026-08-31
Plugin access: active until 2026-08-31

Cancelling a subscription does not always mean that access should stop immediately. A customer may already have paid through the end of the current billing period.

Likewise, a temporary payment failure may justify a grace period rather than an immediate lockout.

These decisions should be intentional and documented.

Updates Are Part of the Customer Experience

After launch, customers need a reliable way to get new versions.

You may use:

  • Email announcements.
  • A customer account page.
  • Store download updates.
  • An installer or download manager.
  • In-plugin update notifications.
  • A simple update link returned during license refresh.

Inlay can provide update information to licensed HISE and JUCE products as part of the same infrastructure used for entitlement refresh. repository_facts

Licensing and updates should still be treated as separate concerns. A failed update check should not unnecessarily block a valid customer from using the plugin.

Policies Worth Deciding Before Launch

A lot of support work comes from questions that were never answered before release.

Decide these points early:

  • How many computers can one customer activate?
  • Can customers remove devices themselves?
  • What happens after replacing a computer?
  • How long does offline access last?
  • Can a license be transferred?
  • When does access end after a refund?
  • What happens when a subscription is cancelled?
  • How are email changes handled?
  • Can support create or revoke licenses manually?
  • How will partner and marketplace sales be fulfilled?

The answers should match across your website, checkout, documentation, support replies, and plugin interface.

First Paid Plugin Launch Checklist

Product and delivery

  • Confirm supported operating systems and plugin formats.
  • Test installation on clean systems.
  • Prepare download and installation instructions.
  • Decide how customers receive updates.
  • Publish clear system requirements.

Store and checkout

  • Choose a marketplace, direct checkout, Merchant of Record, Shopify store, or lightweight platform.
  • Create products and prices for each edition.
  • Record all external product and variant IDs.
  • Test successful and failed payments.
  • Decide how bundles and upgrades are represented.

Licensing and fulfillment

  • Map external products to internal protected products.
  • Configure and verify webhooks.
  • Make webhook processing idempotent.
  • Create entitlements only for the correct events.
  • Test orders containing multiple products.
  • Prepare license keys for partner or non-store sales.

Activation

  • Implement activation inside the plugin.
  • Test the flow in multiple DAWs.
  • Store and validate access locally.
  • Test browser cancellation and network failures.
  • Test launching the plugin offline.

Device and support policies

  • Set a device limit.
  • Provide a device-removal process.
  • Test computer replacement and reinstall scenarios.
  • Define offline duration and refresh behavior.
  • Give support a manual license-management path.

Refunds and subscriptions

  • Handle refunds and chargebacks.
  • Handle cancellation and expiration events.
  • Define paid-through behavior.
  • Decide how failed renewals are treated.
  • Test revocation and restored access.

Where Inlay Fits

Inlay is not a storefront, marketplace, payment processor, or Merchant of Record.

It is the layer that connects a completed purchase to usable access inside an audio plugin. repository_facts

Inlay can connect supported Stripe, Paddle, FastSpring, Shopify, and WooCommerce purchases to automatic license creation. It can also issue redeemable license keys for partner sales and other billing methods. repository_facts

A typical flow looks like this:

  1. The customer buys your plugin.
  2. The purchase is matched to the correct Inlay product.
  3. A license is created automatically.
  4. The customer installs the plugin and clicks Activate.
  5. They sign in through the browser.
  6. The plugin unlocks.
  7. It continues working locally according to your offline-access rules.
  8. If the device limit is reached, the customer can remove an unused device.
  9. Later refreshes can reflect revocation, expiration, and available updates.

Inlay supports both HISE and JUCE plugin integration, device limits, browser activation, offline local access, license-key redemption, and license management through the Console. repository_facts

See Introducing the Inlay Console for product setup, integrations, licenses, license keys, and billing configuration.

The main point is simple: a customer has not fully received a paid plugin just because checkout succeeded and a download link was sent.

A complete selling workflow connects the payment to a license, the license to plugin activation, and the activation to a clear long-term policy for devices, offline use, refunds, subscriptions, and support.

Sources

  1. Stripe webhook quickstart, Accessed 2026-07-03; no page date surfaced in manual research.. https://docs.stripe.com/webhooks/quickstart back
  2. Paddle for digital products, Accessed 2026-07-03; no page date surfaced in manual research.. https://developer.paddle.com/get-started/how-paddle-works/digital-products/ back
  3. FastSpring license management integrations, Accessed 2026-07-03; no page date surfaced in manual research.. https://developer.fastspring.com/docs/license-management-integrations back
  4. Inlay repository facts, Generated for this session before research review.. content/sessions/2026-07-03-how-to-sell-vst-plugins-online/01-repository-facts.json back
  5. Plugin Boutique developer intake, Dated 2026-04-29 in manual research.. https://help.pluginboutique.com/hc/en-us/articles/6232293017108-Selling-with-Plugin-Boutique back
  6. KVR Developer Access, Accessed 2026-07-03; no page date surfaced in manual research.. https://www.kvraudio.com/developer_application.php back
  7. Stripe products and prices, Accessed 2026-07-03; no page date surfaced in manual research.. https://docs.stripe.com/products-prices/how-products-and-prices-work back
  8. Stripe Managed Payments, Accessed 2026-07-03; no page date surfaced in manual research.. https://docs.stripe.com/payments/managed-payments back
  9. Lemon Squeezy merchant of record, webhooks, and license API, Accessed 2026-07-03; no page dates surfaced in manual research.. https://docs.lemonsqueezy.com/help/payments/merchant-of-record https://docs.lemonsqueezy.com/help/webhooks https://docs.lemonsqueezy.com/api/license-api back
  10. Shopify Digital Downloads, Accessed 2026-07-03; no page date surfaced in manual research.. https://help.shopify.com/en/manual/products/digital-service-product/digital-downloads back
  11. Shopify subscriptions, Mentioned in curated source-quality metadata, but no detailed source URL was provided in the evidence pack.. No public URL supplied in curated evidence. back
  12. Shopify taxes, Accessed 2026-07-03; no page date surfaced in manual research.. https://help.shopify.com/en/manual/taxes back
  13. Gumroad license keys, Accessed 2026-07-03; manual research surfaced a 2023-01-09 event date for product_id usage.. https://gumroad.com/help/article/76-license-keys back
  14. Payhip software license keys, Accessed 2026-07-03; search result said published last week.. https://help.payhip.com/article/317-software-license-keys-new back
  15. PACE/iLok support documentation, Accessed 2026-07-03; no page dates surfaced in manual research.. https://help.ilok.com/ilm_overview.html https://help.ilok.com/faq_cloud.html back
  16. Paddle subscription provisioning, Accessed 2026-07-03; no page date surfaced in manual research.. https://developer.paddle.com/build/subscriptions/provision-access-webhooks/ back
Try Inlay