Plugin licences, updates and keeping a store running

Ask four questions before comparing licences

When a plugin is described as having “a licence”, several different questions are often hidden behind the same word. What may the customer use? Which new versions may they obtain? Which packages may they download? What support is included? Those questions overlap commercially, but they do not need to share one technical switch.

Separating them makes both purchasing and operation easier to understand. A customer can see what an expiry date actually changes. Support can explain the difference between a download that is unavailable and an installed integration that still runs. An administrator can inspect a specific entitlement instead of interpreting a single vague active/inactive badge.

This article explains our architectural approach, not final VivaGo purchase terms. VivaGo is in development and cannot yet be purchased. Prices, durations, supported installations and the exact conditions of updates or support will be published before sales open. No example here creates a commercial entitlement or promises a release date.

Keep licensing outside the merchant’s payment path

A checkout is part of the merchant’s own business operation. Its payment provider account, order data and customer transaction should not need a successful request to an unrelated software-distribution service each time someone pays. Otherwise, a licensing outage can become a checkout outage even when the provider and store are functioning normally.

Our requirement for VivaGo is explicit: a WideDock licence expiry, outage or revocation must not interrupt checkout, charges, refunds, payment webhooks or reconciliation in the merchant’s store. Licensing checks belong to the separate update and support path. This is a boundary in the design, not a guarantee that an installed payment integration can never fail for other reasons.

Provider credentials, payment-provider availability, the store’s server and the plugin’s own compatibility still matter. If one of those fails, the store needs diagnosis of that actual dependency. Keeping licensing separate prevents us from adding an avoidable dependency; it does not remove the operational responsibilities of running an online store.

Installed does not always mean current or safe

Keeping an installed integration running is different from saying it should remain unchanged forever. New platform releases, provider changes and security fixes can make updates important. An explicit separation between usage and updates should help a merchant plan maintenance, not encourage indefinite operation of obsolete software.

A useful product interface explains the current installed version, which newer release is eligible and what requirements apply. If access to updates has ended under the published terms, the message should name that condition clearly. It should not imply that a merchant payment has failed merely because software support or update access needs attention.

Before an update, examine the supported versions and the changelog, keep an appropriate backup and verify the intended path in staging. WordPress documents auto-update controls, but the choice to enable an automatic update still belongs in the store’s maintenance process. A release being available is not the same as proof that every configuration can install it safely.

Give staging and domain changes an explicit policy

An activation limit means little unless the product explains what counts as an installation. A production shop, a staging clone and a changed domain can otherwise look like three unrelated customers to a licensing service. That creates support friction at exactly the moment someone is trying to test or migrate safely.

We prefer stable installation identity with explicit rules for environments and transfers. A product should tell customers how a staging environment is recognized, whether it counts toward a limit and what to do when a domain changes. Those are policy decisions to publish and test, not details to infer from the shape of a licence key.

At the same time, a hostname should not become a shortcut around authorization. A download request needs the correct product, customer and entitlement context, with installation binding where the update client requires it. A customer portal download does not inherently require an activated installation. The engineering task is to make legitimate maintenance understandable while keeping each customer’s package access separate. Exact VivaGo limits remain a pre-sale decision.

An update needs identity, integrity and eligibility

For a customer, “there is a new version” sounds simple. A distribution service needs to establish more: which product the version belongs to, which channel it is on, which environments it supports, whether the customer is eligible and whether the downloaded package matches the published artifact.

We treat release metadata and package integrity as parts of one distribution flow. A version name alone is not enough. Customers should be able to understand relevant requirements and changes before updating. Private download authorization should not be replaced by an indefinitely reusable public ZIP link.

Publishing a version also does not mean forcing it onto every installation. WordPress update settings and the client’s capabilities affect installation. Product distribution and installation are separate operations with different failure modes. A failed or interrupted download should not be interpreted as a completed update, and withdrawal of a package needs a clear operational process.

Financial changes need understandable entitlement changes

Purchases, renewals and refunds can affect different entitlements. A renewal might extend an existing licence instead of creating another installation. A refund of that renewal may need to remove only the extension. A partial refund might concern one purchased unit rather than every licence in a customer account.

The exact commercial rules depend on the published product terms. The technical principle is to record the source of each grant and apply verified financial changes to that source. An operator should be able to explain why an update or support date changed and which transaction caused it, without rewriting unrelated history.

Failures should preserve this history. A timeout while verifying a renewal should not guess a new expiry date. A repeated payment event should not grant the extension twice. A recovery process should reuse the same rules as the normal path so that fixing an incident does not create a different interpretation of the customer’s rights.

Make the boundaries visible before the first sale

The best time to explain these distinctions is before the purchase. Product information should separate usage rights, installations, update access, package downloads and support. It should also explain how customers recover an account or replace an installation credential without confusing the two.

The same clarity applies to data. An update service does not automatically need the merchant’s card data or complete order history. A product should document what its external services receive and why. WordPress.org has its own distribution and external-service rules; compliance with those rules must be assessed separately if a product is submitted to that directory.

WideDock is the common platform we are building for our products. VivaGo is the first product under development, with its own release and compatibility work. Our published principle is continuity of merchant payments and clear update/support boundaries. The final commercial terms will turn that principle into specific, reviewable conditions before the product becomes available.

Sources and further reading

• WordPress: plugin and theme auto-updates
• WordPress Plugin Handbook: external services and directory guidelines
• WordPress: managing plugins