A license key is not the license.
The license is the rule you sold: one site or five, updates for a year or access that ends when they stop paying. The key is only an ID. The plugin or theme on the customer’s site has to send that ID back to the store and ask whether the rule still holds.
If it never asks, you sold a ZIP with a romantic string in an email. Plenty of “licensed” products work that way until the first agency installs a personal key on eleven sites.
The handshake is the same for a theme as for a plugin. Avenia Digital Products is the store side. Checkout issues the key. What you ship calls the license REST API on your store. WordPress updates use the same license. Below is the loop, and how we do each part.
What the store does. What you ship has to do.
Two jobs. People mix them up and then blame the cart.
The store takes payment, creates the key, and remembers the rules for that purchase: which product it belongs to, how many sites it may activate, whether it expires. The buyer should see the key in the purchase email and in an account they can log into later.
The plugin or theme you ship has to call that store. Commerce cannot reach into a site it does not run. A settings field that saves the key locally, and never talks to anyone, is a password manager. It is not licensing.
On Avenia, those jobs stay split on purpose. Enable license keys on the product. After Stripe or PayPal completes, we generate a key, set the site limit from the quantity they bought, and put the key in the order email and in My Account. Your plugin or theme still has to activate and validate against your store. We cannot enforce a site limit from the outside.
That split is why a generic shop plus “we will add licensing later” fails. Later means a second system that disagrees with the first about who paid.
Three calls, not one checkbox
A working license needs three requests. On Avenia they are named plainly: activate, validate, deactivate. Same three jobs if you roll your own.
Activate. This site is using a slot. You send the key, your store’s product ID, and the domain. We record the installation and return an activation key for that site. If the license is already at its site limit, we refuse. The same domain calling activate again does not burn a second slot. If they (or you) revoked that installation from My Account, activate will not quietly restore it. They restore the seat from the account page.
Validate. Is this still allowed. The key exists, it belongs to this product, it is still in term, and this domain is an active installation. Run it on a schedule, not only when they save settings. Otherwise a refunded or lapsed key keeps working until someone re-saves. If you send the domain, we require that site to already be activated. A yes on the string alone is not a yes on the site.
Deactivate. Free the slot. They moved hosts. They rebuilt staging. They hit the limit and need to drop an old domain. Your product can call deactivate, or they can revoke the installation from My Account on your store. Skip both and every migration becomes a ticket you handle by hand.
Validate without activate is a yes/no on the string. It does not count sites. Activate without deactivate is a trap with no exit. You want all three. The license REST API is those three endpoints. The licensing integration guide is how to wire them from the plugin or theme you sell.
A key is also tied to a product. A purchase for Plugin A does not unlock Theme B because someone pasted the same code into two settings screens. Validate and activate both check the product ID you send.
Site limits are the product
Personal versus Agency is a number of activations, not a mood.
If the page says one site, the store should issue a key with a max of one, and activate should reject the second domain. If Agency means five, say five. If you sell unlimited, say unlimited and store it that way. People understand site counts. They get confused by tier names that do not map to a number.
On Avenia that number is the license quantity on the product: 1 site, N sites, or unlimited. Checkout shows it as Sites. The key’s max activations is that number. You are not maintaining a separate “Personal / Pro” SKU unless you want two products. Same catalog item, different seat counts, different prices.
Write the number on the product page. Enforce it in what you ship. If you only enforce it in copy, you sold an honor system.
Customers can see which sites use the key and drop one from My Account. Without that, “maximum activations reached” is a support queue.
Localhost and staging count. We do not guess that a URL is “not production.” Every domain that activates uses a slot. If you want a free staging seat, that is a rule you implement in the plugin or theme you ship. If you do not want that complexity, sell a two-site personal license or tell people to deactivate the old URL before they activate the new one.
What yearly actually gates
The license check is how you make the offer true. The offer is still something you have to write down.
One-time. On Avenia the key does not expire. They paid for this product. Activation limits still apply. If you also promised updates forever, you promised ongoing work at a one-time price. That is a different problem; we wrote about what “lifetime” has to mean.
Subscription. Access follows billing. While the subscription is paid, including a grace period if a renewal fails, validate succeeds. When it lapses, we mark the license inactive and validate fails. Then you decide, in what you ship, what that failure does: hide Pro features, stop the product, or only stop updates.
You can sell either model on the same store. Monthly and yearly can sit on the same product. Customers cancel or restart from My Account.
Both are honest if the page and the software agree. The failure is a sales page that sounds like they own the ZIP forever, and a license check that turns the product off in month thirteen.
Updates are a second channel
Dashboard updates are how WordPress already works. They are not the license. They should consult the same license.
Enable WordPress updates on the Avenia product. When you upload a new plugin or theme package, licensed sites see it under Dashboard → Updates, the same way they update everything else. The update check uses the same key. Invalid, lapsed, or over-limit licenses do not get the package. Emailing a new ZIP to whoever still has last year’s purchase thread is not an update channel. It is a newsletter with a file attached.
That is also why yearly-for-updates is easy to explain. They already know the site does not vanish. The updates do, unless they renew.
Full setup: WordPress plugin and theme updates guide.
wordpress.org is not your license server
A free plugin or theme can live in the directory. That is distribution. The paid product’s license check still points at your store.
Do not send activate and validate to wordpress.org. Do not tell buyers the key is “their wordpress.org account.” The repo does not know who paid you, how many sites they bought, or whether the subscription is current. Avenia is that store: your domain, your API, your keys.
If the free and paid versions share a slug, people will install from the directory and wonder why a key is required. Different slugs, or a clear upgrade path, save that email.
Before the key means anything
Buy your own product once in Avenia test mode and walk the path.
1. Checkout. Confirm the key shows up in email and in My Account.
2. Activate on one site. Confirm a second site is refused if the limit is one.
3. Revoke from My Account (or deactivate from the product), then activate somewhere else. Confirm the slot moved.
4. If you sell a subscription, let a test term lapse and confirm validate fails.
5. Ship a tiny version bump and confirm a licensed site sees the update, and an unlicensed one does not.
If any of those fail, the product page is advertising a license you do not have yet.
Comments 0