WC Serial Numbers Pro - WordPress Plugin

How to Set Up and Use WC Serial Numbers Pro in WooCommerce

WC Serial Numbers Pro is not just a place to store codes in the admin panel. Its real value shows up when a WooCommerce store needs to automatically deliver the correct serial number, license key, access code, or unique identifier to the customer after successful payment, while the store owner needs visibility into key inventory, delivery status, expiration, activation limits, and order history.

In this guide, we will look at the plugin as a working tool for a real store, not as a short feature summary. We will start by defining where it truly makes sense, then move through preparation, installation, key source setup, simple and variable products, bulk import, email and SMS delivery, result verification, API workflows, and common issues.

This material is intended for a store owner, WooCommerce administrator, or developer who already understands the basic mechanics of products and orders. If you sell digital products, access codes, game keys, subscription tiers, tickets, or physical goods with individual serial numbers, the practical side will be the most useful part here: which settings to enable, where mistakes happen most often, and how to confirm that the customer received the correct key.

I will not cover buying the plugin, entering payment details, or how to obtain the paid version. This guide assumes you already have a legitimate Pro installation ZIP and a working WordPress site with WooCommerce. Settings related to external service secrets are covered only from the standpoint of security and verification: tokens, access keys, and account data should not be shared in third-party chats, with contractors who do not need them, or in task descriptions.

What Problem the Plugin Solves and Where It Is Most Useful

Standard WooCommerce can sell a digital file, create a virtual product, accept payment, and send the customer an email. But a default store does not know that each sale needs a unique code, that one key should not be issued to two different customers, that different product editions need different pools, or that on a refund the key should ideally be revoked or returned to inventory. WC Serial Numbers Pro adds exactly that management layer.

The core workflow looks like this: the store gets a new entity called a "serial key," that key is linked to a product or variation, the order reaches the required WooCommerce status, and then the plugin assigns the key to the order and displays it wherever the administrator has configured it. The customer does not have to wait for a manual email, and the administrator does not have to copy a code from a supplier spreadsheet into each order.

The most natural use cases are:

• Selling licenses for software, plugins, themes, mobile apps, or desktop applications.
• Delivering access codes for courses, gated content, webinars, consultations, or internal portals.
• Selling game keys, gift codes, and top-up codes where fast import and supplier inventory matter.
• Assigning unique serial numbers to physical products for warranty, registration, or authenticity checks.
• Separating keys by product edition: Personal, Business, Agency, Basic, Pro, and similar tiers.

The plugin is a strong fit when WooCommerce is already your sales hub and keys need to live alongside orders, products, emails, and the customer account. If your product requires a separate licensing server, remote update delivery, signed packages, download control, and its own developer-managed infrastructure, WC Serial Numbers Pro may be only one part of the solution. It works well as a store-side layer for key delivery and tracking, but it does not replace full server-side application protection.

Practical takeaway: decide first what exactly you are selling - a pre-generated code from a pool, a key created from a pattern, a random key per order, or access tied to a subscription. That choice will determine almost everything in the rest of the setup.

Who Should Use WC Serial Numbers Pro and Who Should Consider Another Approach

WC Serial Numbers Pro works especially well for stores where the key is part of order fulfillment. That is not limited to digital storefronts. A physical product with a serial number may also require recording, delivery, export, and order-based lookup. What matters is not the product type, but whether there is a unique identifier that must be securely tied to the purchase.

When the Plugin Is a Strong Choice

It is a good fit for small and mid-sized WooCommerce stores where the administrator wants to manage keys without relying on an external dashboard. The settings live in the familiar WordPress environment: the Serial Numbers menu, the product edit screen, tabs inside Product Data, WooCommerce orders, emails, and the My Account page. That reduces the number of places where the connection between payment, product, and delivered code can get lost.

The plugin is also useful for sellers who receive batches of keys from a supplier. Instead of adding them by hand, you can use CSV or TXT import and then export the data for reconciliation. For stores with multiple editions of the same product, variable product support matters: each variation gets its own configuration and pool, so a customer who buys the Business edition should not receive a Personal edition code.

When to Be More Careful

If your store runs on a complex multilingual setup with separate domains, compatibility should be tested up front. In public PluginEver support, one case discussed keys showing only on the main WPML domain, and support explained it in terms of how keys are tied to products, orders, and metadata. So with WPML and multi-domain setups, you should not rely on the marketing phrase "compatible" alone. You need a test order on every language version.

If you need a license that will be activated inside an external application, review the REST API before you go live. The documentation describes endpoints for validation, activation, deactivation, and version checking, but the actual integration always depends on how your application stores instance, platform, email, and product ID. For a simple key-selling store, the API may not matter. For a software vendor, it becomes one of the most important implementation areas.

The plugin should not become a place to store sensitive data without an access policy. Even if keys are protected at the product level in the database, store staff still work with orders, exports, emails, and support. Restrict user roles, avoid handing out export CSVs unless necessary, review admin panel access, and make backups before bulk operations.

What to Check Before Installation and the First Launch

Preparation matters more here than it may seem. Key-related problems are often discovered not at installation time, but after the first order: the order stays in Processing, the keys run out, a variation points to the wrong pool, the import used the wrong product_id, and the customer asks support where their code is. That is why it helps to map out a small process flow before you install anything.

Your Site's Technical Baseline

Check the WordPress.org listing and official documentation for the required versions of WordPress, WooCommerce, PHP, and the database. There is no point memorizing version numbers from someone else's article: they change, and the plugin page plus the developer documentation remain the authoritative source. What matters is that WooCommerce runs reliably, store emails reach a test address, and the payment gateway moves the order into the expected status correctly.

Before making changes on a live site, back up the database. Serial numbers are tied to orders, products, and metadata, so a bad bulk import or a test against the wrong product can leave behind a messy data trail. For the initial setup, a staging copy or a hidden test product is the safer option.

Define Your Key Model Before Configuration

Create a short table in your store documentation: product, product type, key source, keys per unit, expiration period, activation limit, delivery method, and restocking owner. The plugin does not require this table, but it prevents operational chaos as your catalog grows.

For a prebuilt key pool, decide whether you will add codes manually, import TXT, or use CSV with fields such as serial_key, product_id, activation_limit, status, validity, and other supported columns. For keys that can be generated inside the store, think through the pattern ahead of time: prefix, length, random or sequential type, whether the date has any meaning in the key, activation limit, and validity period.

Access Control and Email Delivery

Review who on the team has access to orders, exports, and the Serial Numbers settings. For a support manager, it is often enough to see the order and the issued key, without permission to edit generators, allow duplicates, or enable selling without stock. If you use SMS through Twilio, treat the SID, token, and sender number as admin secrets, not as ordinary notes inside a task.

Also check WooCommerce email delivery separately. WC Serial Numbers Pro can show the key on the order page, in the customer account, and in email, but if store email lands in spam or is not sent at all, the customer will still open a support ticket. For digital products, it often makes sense to use an SMTP plugin or a transactional email service, though that is a decision at the level of the store's overall email infrastructure.

Installation and an Initial Safety Check

The official documentation covers installation of the free core plugin from the WordPress.org directory and installation of the Pro archive through ZIP upload in the admin panel or via FTP/SFTP. This article will not cover how to obtain the archive or purchase the plugin. In practice, something else matters more: the Pro component works on top of the main WC Serial Numbers logic, so the required components must be active on the site, and the Serial Numbers section should appear in the admin panel.

A Safe Installation Order

1. Verify that you have a current site backup and a working restore path.
2. Make sure WooCommerce is active, products open correctly, and a test order can be created without errors.
3. Install and activate the base Serial Numbers plugin from the official source.
4. Install the Pro add-on through Plugins - Add Plugin - Upload Plugin if the archive is already available locally.
5. Open the Serial Numbers menu and confirm that key lists, settings, and tools are available.
6. Create a test product or use a draft product that real customers cannot see.

After installation, do not enable every advanced option right away. First, get the minimum working loop in place: a key exists in stock, the product is configured to sell keys, the order is completed, and the key appears in the order and in the customer's account. Only after that should you add generators, SMS, export, key reuse, duplicates, or selling without stock.

The First Checkpoint

Open Serial Numbers - Serial Keys. In a normal state, you will see a table of keys or an empty list if no keys have been created yet. This becomes the main operational view: you can check statuses such as Available, Pending, Sold, Expired, and others, and quickly see whether keys are in stock and linked to the correct product.

Then open Serial Numbers - Settings. The documentation mentions tabs for general settings, advanced options, translations, Twilio, and other areas. Not every option matters for every store. At the beginning, focus on low stock alerts, order behavior after payment, returning or revoking keys on cancellation, displaying key properties in the order, and translating customer-facing labels.

Three Key Sources: Manual Pool, Generator Rule, and Auto Generated Key

The most important setting in WC Serial Numbers Pro is not the email layout or the feature list. The critical decision is where the key comes from at the moment of purchase. The plugin supports several approaches, and each comes with its own use case, risks, and verification method.

Manually Added: When the Supplier Already Provides the Keys

A manual pool is the right choice when codes come from an external supplier or are created outside the store. You add keys in Serial Numbers - Serial Keys, assign the product, enter the Serial Key value itself, set the activation limit, validity period, status, and optionally the order ID. The documentation emphasizes that the key value is delivered to the customer exactly as stored, without transformation, so clean data is especially important here.

The advantage of a manual pool is predictability. You know exactly which code is in inventory. The downside is the need to replenish stock and monitor levels. If the product sells actively, enable low stock alerts and decide in advance who will upload the next batch.

Generator Rule: When You Need a Controlled Format

Generator Rule is a Pro feature that creates keys from a pattern. The documentation describes going to Serial Numbers - Tools - Generators, where you define the pattern, product, type, validity, and activation limit. The # character is used as a placeholder for a letter or number, and date tokens can insert parts of the current year, month, or day. The generation type can be sequential or random.

This approach works well when the key needs to be readable and tied to a product line. For example, different editions can use different prefixes. A sequential type is easier to verify and reconcile, but it is also more predictable. A random type is less convenient in manual tracking, but harder to guess. For keys that unlock actual software access, random generation and sufficient length are usually the better choice, while a human-readable prefix can remain only for internal sorting.

Auto Generated Key: When Speed Matters More Than a Separate Generator

Auto Generated Key creates a unique alphanumeric key when the order succeeds. In the product settings, you select Key Source - Auto Generated Key, and fields such as Key Prefix, Activation Limit, Validity, and an optional product version appear. This mode is useful when you do not want to prefill a pool or manage more complex generator patterns.

The tradeoff is less control over the format. If a supplier requires a specific pattern, if the keys need to exist before the sale, or if accounting reconciles by batch, Generator Rule or import is usually a better fit. If the goal is simply to issue a unique code for every order as quickly as possible, Auto Generated Key reduces manual work.

How to Choose the Right Source Without Guesswork

Do not mix key sources without a reason. Each product or variation should have one clearly defined primary path. If some keys come from a pool today, a generator is enabled tomorrow, and the administrator manually changes statuses later, troubleshooting becomes much harder.

Setting Up a Simple Product and Testing Key Delivery

A simple WooCommerce product is a single product without variations. For WC Serial Numbers Pro, this is the clearest use case: one product, one set of settings, one pool or one generator. Even if you ultimately plan to work with variable products, this is the best place to start.

Where Key Delivery Is Enabled

Open the product in Products, scroll to the Product Data section, and find the Serial Numbers tab. The documentation highlights an important detail: until the Sell Keys checkbox is enabled, the plugin will not deliver keys for that product, even if matching codes already exist in the database. That is the first thing to check when someone reports that "the key was not delivered."

The Delivery Quantity setting defines how many keys the customer receives for one purchased unit of the product. In most stores, the value stays at 1. If the customer orders 3 units, they should receive 3 keys. If the product is a bundle and one unit is meant to unlock multiple accesses, you can increase the value, but in that case you must place a multi-quantity test order and verify that the number of delivered keys matches your business rules.

Configuring a Manual Pool for the First Test

The easiest first test is to add one or several keys manually. Go to Serial Numbers - Serial Keys, click Add New, select the correct product, paste in the key value, set the status to Available, and save. If the product does not require software activation, you can leave the activation limit and validity period empty or configure them to match the actual promise you make to the customer.

Then go back to the product, enable Sell Keys, choose Manually Added as the source, save the product, and place a test order. It is important to go through the full customer path, not just inspect the admin table. The key should appear after the order reaches Completed, because the documentation ties delivery to order completion.

Three Places to Verify

After the test order, check these three control points:

1. The order page in the WooCommerce admin - the order details should include a serial key block.
2. The customer's My Account area - the customer should see the key in the order if display has not been disabled in settings.
3. The order email - the key should be included if email delivery has not been disabled.

If the key is visible in the admin panel but not to the customer, the issue is most likely in the display settings, email templates, email configuration, or theme. If the key was not assigned at all, start by checking the order status, the Sell Keys checkbox, the key source, the presence of Available keys, and the product match.

Critical expected state: after the test order is completed, the key is linked to a specific order ID and no longer appears as free inventory for the next sale.

Separate Key Pools for Product Variations

Variable products are one of the strongest arguments for the Pro version. In a typical license store, one product often comes in multiple editions: Personal, Business, Agency, Single Site, Unlimited, Student, or Team. The customer sees one product page, but the selected variation must receive its own code, its own prefix, its own limit, and its own stock.

The official documentation explains this clearly: for a variable product, configuration is done inside each variation, not only at the parent product level. That protects you from the common mistake where the store gives a lower-tier code to a higher-tier buyer, or the other way around.

How to Configure a Variation

Open the variable product in Products, go to Product Data, select the Variations tab, and expand the specific variation. Within the standard variation fields, there should be a Sell Key checkbox. Once enabled, the key settings for that variation appear: delivery quantity and key source.

Configure the first variation fully, save the product, and then move on to the next one. Do not turn on every checkbox in bulk without checking. If the product has many variations, work in sequence: open one variation, enable key delivery, choose the source, save, note it in your working table, and only then move on.

Different Generators for Different Editions

It is often useful to create separate Generator Rules for separate editions. For example, one variation may use the prefix PERSONAL-, another BUSINESS-. Visually, this helps support and makes exports easier to review. But do not treat the prefix as your only security mechanism. A predictable prefix should help with organization, while the uniqueness and length of the key should protect it from guessing.

If all variations use the same overall format, you can rely on shared logic, but you should still test each variation with its own order. WooCommerce stores variation data separately, and the failure point is more often not the generator itself, but the fact that a specific variation ID has no key source or an empty pool.

Testing a Variable Product

Create one test order for each critical variation. If there are many variations, at minimum test different types: the least expensive tier, the highest tier, a manual pool variation, a generator variation, and an Auto Generated Key variation. After each order is completed, verify the following:

• The order shows the selected variation, not just the parent product.
• The delivered key comes from the correct pool or carries the expected generator prefix.
• The number of keys matches Delivery Quantity and the quantity ordered.
• The email and customer account display the data without unnecessary internal fields.

If one variation works and another does not, do not start by blaming a general theme conflict. The problem is more likely in the configuration of that specific variation: Sell Key is not enabled, the wrong source was chosen, stock ran out, the wrong product ID was imported, or the generator is not assigned to the right variation.

Generators, Bulk Import, and Export as Part of Store Operations

As sales volume grows, manual key entry stops being practical. WC Serial Numbers Pro provides several operational tools: rule-based generators, bulk key creation, CSV/TXT import, and filtered export. These are important not as "extra features," but as the way to keep control over inventory.

Generator Rule and Bulk Inventory Creation

Once you create a Generator Rule, you can do more than generate a key at purchase time. You can also prebuild a batch of keys in the pool. The documentation describes an action on the Serial Numbers - Tools - Generators page: enter the quantity next to the generator, click Generate, and then verify the new keys in Serial Keys with the Available status.

A prebuilt key inventory is useful for auditing and for sales where the number of codes is limited. Generation at order time is useful for an unlimited digital product. The right choice depends on whether the key needs to exist before the sale. For supplier-issued codes, yes. For self-issued training access, not always.

CSV vs. TXT

CSV is useful when each row contains not only the code itself but also settings: product_id, activation_limit, order_id, status, validity, order_date. The documentation points out that an incorrect product_id can assign keys to the wrong product or break the import. That is why, before uploading a large batch, you should build a small 2-3 row file, import it into a test product, and confirm that the plugin interprets the fields correctly.

TXT is simpler: one key per line, with shared parameters selected during upload. It works well for a batch of identical codes for one product. But if you have mixed validity periods, activation limits, or statuses in one dataset, TXT quickly becomes too blunt an instrument.

Batch Limits and File Splitting

PluginEver documentation states that CSV import processes the first thousand serial keys from the uploaded file. That is an important practical limit. For a large supplier, it is better to split batches in advance: separate files by product, variation, supplier, or month received. That makes it easier to roll back a mistake, identify the source of a disputed code, and export the exact range you need.

Do not enable duplicate keys just because the import complains about a repeated value. First figure out why the duplicate is there. Duplicates are useful only in narrow cases, such as when one shared access code can be sold to multiple event attendees. For software licenses and unique keys, duplicates more often create an activation and support conflict.

Export for Reconciliation and Support

The Pro export feature lets you download keys as CSV and filter them by product, status, and order range. That is useful for inventory audits, supplier reconciliation, and disputed-case review. Do not export "everything just in case" when the task concerns one product. The fewer unrelated keys in the file, the lower the leak risk.

In public WordPress.org support, there was a recent example where a user reported that after an update, export returned blank rows if the Product field was left empty, but worked when a specific product was selected. Support classified it as a Pro issue and redirected the user to the direct channel. That is not proof of a widespread defect, but it is a useful troubleshooting clue: if a global export is empty, first try exporting with a product selected and document the reproduction steps for support.

How the Customer Receives the Key: Order, Email, Account, SMS, and PDF

From the customer's perspective, the plugin is invisible until the key is delivered. They buy the product, pay for the order, and wait for the code. So the quality of your setup is measured not only by whether the administrator sees the key in a table, but by whether the customer receives clear information in the right place.

Order Status and the Delivery Trigger

The simple product documentation states that key delivery starts when the order reaches Completed. That is fundamental. Many payment gateways leave orders in Processing or On Hold, especially when the product is not fully virtual or the payment method requires manual review. In that case, the key is not lost or broken - it simply has not been assigned yet.

The Auto-complete orders setting moves paid orders to Completed automatically and speeds up key delivery. It makes sense for digital products with reliable online payment. For bank transfers, cash on delivery, manual review, or high-value B2B orders, it is usually better to keep completion manual so the key is not sent before verification.

What to Show on the Order Page

The Display Key Properties on Order Details section lets you choose which key properties the customer sees: the key itself, activation limit, activation count, expiration date, activation email, and status. Do not show everything by default. For a course access code, the key and expiration date may be enough. For a software license, activation limit and status may be useful. For a gift code, too many technical fields will only confuse the buyer.

On a Russian-language store, it almost always makes sense to open Serial Numbers - Settings - Translation and replace labels such as Serial keys, Key, Activation limit, Expire date, and Status with wording your customers will immediately understand. This is not just cosmetic. Good labels reduce support volume.

SMS Through Twilio

The Pro documentation describes Twilio integration: enable Twilio in the plugin settings, fill in the Account SID, Auth Token, phone number, and message template. During checkout, the customer must enter a mobile number with the country code. This channel is useful for game keys, urgent tickets, and cases where email delivery is often delayed.

But SMS should not be enabled without testing the number format, confirming customer consent, and reviewing the message text. Do not overload the SMS with too many key properties. The message should help the customer receive the code, while the details can stay in the email and account area. Store the Twilio token only in the site settings and your team's secure secrets manager. Do not send it to contractors in plain text.

PDF Invoices and Subscriptions

PluginEver documentation describes compatibility with WooCommerce PDF Invoices & Packing Slips: serial numbers can appear in PDF invoices and packing slips once compatibility is enabled and keys have been assigned. This is useful for B2B customers who need a document with the code in their order archive.

For WooCommerce Subscriptions, the documentation describes Pro settings related to license expiration, moving the validity period to the next payment date, blocking access after cancellation or subscription end, and automatically renewing the license when the subscription renews. These options should not be enabled blindly. For a subscription product, you should test a full workflow: initial purchase, renewal, overdue payment, cancellation, and re-renewal. Without that test, it is easy to grant access for longer or shorter than your subscription model promises.

The Key Lifecycle: Inventory, Delivery, Return, Revocation, and Manual Assignment

To make WC Serial Numbers Pro behave predictably, it helps to think in terms of the full key lifecycle rather than isolated settings. A key enters the system, waits for sale, gets assigned to an order, is shown to the customer, may be activated by an external product, and then either remains active, returns to inventory, is revoked, or expires. Each stage should have a clear rule.

This approach is especially important for stores with support workloads. The customer usually does not ask which key source was selected. They ask simpler questions: "Where is my code?", "Why does the code not work?", "Can I replace the key?", "What happens after a refund?" The answers depend on settings the administrator enabled ahead of time.

Key Statuses and Why They Should Not Be Changed Mechanically

The manual key documentation lists operational states such as Available, Pending, Sold, Expired, and Cancelled. For the administrator, these are not just technical labels. A status tells you whether a key can be issued to the next customer, whether it is tied to an order, whether it is still valid for the customer, and whether it has been removed from circulation.

Do not change a status manually unless you understand which order and which customer promise sit behind it. For example, moving a sold key back into free inventory can cause another customer to receive a code that has already been exposed. Moving an available key to cancelled can create a false shortage. Manual status edits are acceptable to resolve a specific incident, but the reason should then be recorded in your internal support log.

Low Stock Alerts as Protection Against Selling Without Inventory

Low stock alerts are located in the plugin's general settings. You enable email notification, define a threshold, and set the recipient address. The documentation explains that the threshold applies per product, not as one global number across the entire store. That detail matters for sellers of game keys or licenses from multiple suppliers: one product can run out while others still look fine.

The practical threshold depends on your sales velocity and restocking lead time. If the supplier can send a new batch within a few hours, a smaller buffer may be enough. If the supplier responds the next business day or the batch goes through manual review, the threshold should cover typical demand during the wait. For a variable product, check not just the parent product overall, but each tier, because Business may sell out before Personal.

How to Test an Alert Without a Real Shortage

Create a test product with a small pool, set the threshold above the current stock level, and place a test order. Then confirm whether the notification reached the selected address. After the test, restore the normal threshold or disable the test product. Do not run this experiment against a live bestseller if managers might mistake the test signal for a real urgent issue.

Sell Keys Without Stock: When Backorder Makes Sense

The Enable Backorder setting allows orders to be placed even when no keys are in stock. The documentation presents it as a way to keep sales open while you wait for a new batch, but it also means you must manually add and assign the key later. This is not "magic" automation. It is a deliberate waiting-state workflow.

Backorder makes sense if the customer clearly understands that the code will be delivered later and the team can realistically replenish inventory in time. For instant digital products, this mode can be risky: the customer has paid, expects an immediate code, and the store creates a delay. If you enable selling without stock, update the product text, email, or support policy so the delay does not look like an error.

Manual Delivery for Orders That Need Review

The manual delivery setting stops automatic key assignment and requires administrator action on the order page. In the documentation, this mode is recommended for cases where the order must be reviewed before delivery or where a specific key must be assigned to a specific customer. This is useful for high-value corporate licenses, disputed payments, manual agreements, and nonstandard orders.

But Manual Delivery should not be enabled in a store that promises instant fulfillment unless the team is prepared to monitor it. Otherwise, the plugin is working correctly while the customer experience breaks down. It is better to choose one of two honest workflows: instant automated delivery for low-risk digital products, or manual review for expensive and sensitive codes.

Reuse Keys and Revoke Keys on Refunds

Reuse Keys and Revoke Keys look similar only at first glance. Reuse Keys helps you avoid wasting a key if an order is failed or refunded and the key can safely return to circulation. Revoke Keys does the opposite: it makes an issued key invalid when the order is cancelled or refunded. For a software license, revocation is often more important than returning the key to stock, because the customer may already have seen the code, and reselling that same value to someone else creates risk.

For tickets, coupons, and access codes, the rule depends on the product. If the code is one-time use and may already have been redeemed, it should not go back into inventory. If the code was issued by mistake, was never activated, and belongs to a controlled system, reuse may be acceptable. In any case, test the full behavior on a test order: purchase, delivery, refund, new order, and an attempt to use the old code.

A reliable setup does not hide disputed cases. If a key may already have been exposed to the customer, treat it as used until your external system or activation log proves otherwise.

REST API and Activations: When the Store Becomes Part of the Product

If you are selling more than a code - for example, a software license - the customer may enter the key into an application, plugin, theme, or external service. At that point, WC Serial Numbers Pro becomes not just a delivery mechanism, but also a validation point. The documentation describes a REST API with routes for validation, activation, deactivation, and version checks.

Which API Actions Are Usually Needed

The documentation lists the endpoints /wcsn/validate, /wcsn/activate, /wcsn/deactivate, and /wcsn/version_check. Requests use parameters such as product ID, serial key, email, instance, and platform. That gives you the foundation for a workflow where the application asks the store: does this key exist, has it been activated, how many activations remain, and can a new installation be tied to it?

GET https://your-domain.com/wp-json/wcsn/validate?product_id={id}&serial_key={key}&email={email}&instance={instance}&platform={platform}

This example is useful only as a pattern. In a real product, keys should not appear in logs, be sent through insecure channels, be stored in full URLs inside public analytics, or be pasted into open issues. If the integration matters to the business, the developer should add key masking in application logs and careful error handling.

Testing the API Before Launch

Before publishing the product, create a separate test key and a separate test email. Verify four events: the key is found, the key can be activated, repeated activation behaves as expected, and deactivation frees or changes the state in line with your rules. Then test the negative cases: wrong product ID, another person's email, activation limit exceeded, expired validity, and a revoked key.

Do not promise the customer anything that has not been verified in an API workflow. If your product does not call the API, the activation limit in the store may be only an accounting field. If the application actually validates keys, that limit becomes part of access control. The difference is fundamental, and you need to understand it before the sales page goes live.

Legacy API and Older Integrations

PluginEver documentation separately covers the Legacy API for older WooCommerce projects and warns that modern WooCommerce implementations should rely on the REST API. The Legacy approach should be considered only when you are maintaining an existing integration that cannot be rewritten quickly. For a new project, choose the REST API because it fits current WordPress and WooCommerce architecture better.

Practical Example: Selling Three Editions of a Digital Product

Let us walk through a realistic example. The store sells a digital product in three editions: Personal, Business, and Agency. Each edition has its own activation limit, key prefix, and validity period. The customer should select the edition on the product page, pay for the order, and receive the correct key in the email, account area, and order details.

Goal

You need to configure a variable product so that each variation has an independent key source. Personal can use Auto Generated Key with a prefix, Business can use Generator Rule with a random pattern, and Agency can use a manual pool if the codes come from an external supplier. This mix of sources within one parent product is acceptable only because the sources are separated by variation and match the real business model.

Preparation

Create a WooCommerce variable product, add an "Edition" attribute, and create three variations. Make sure each variation has a price, SKU, and is available for purchase. In Serial Numbers, prepare a generator for Business, add several manual keys for Agency, and leave Personal on on-the-fly generation. If you use a manual pool, assign the keys to the variation itself, not only to the parent product.

Configuration Steps

1. Open the product and go to the Variations tab.
2. Expand Personal, enable Sell Key, set Delivery Quantity to 1, choose Auto Generated Key, enter a clear prefix, and save.
3. Expand Business, enable Sell Key, choose Generator Rule, and select the generator you created.
4. Expand Agency, enable Sell Key, choose Manually Added, and confirm that free keys exist in the pool for that specific variation.
5. Save the product and clear the product page cache if the store uses front-end caching.

Verifying the Outcome

Create three separate test orders, one for each edition. Move each order to Completed or use a test gateway that does so automatically if that setting is enabled. Then open the order, the customer account, and the email. Personal should show a key with the expected Auto Generated Key prefix, Business should show a key built from the generator pattern, and Agency should receive one of the pre-added codes.

After the tests, go back to Serial Numbers - Serial Keys and filter the keys by product or status. You should see that delivered codes are linked to orders, while the remaining Agency codes still have free inventory status. If Business receives a Personal prefix, the source is assigned to the wrong variation or a shared generator was selected for the wrong tier.

A Note on Order Auto-Completion

For a digital store, it is tempting to enable Auto-complete orders so the customer receives the key immediately after payment. That is convenient, but check the payment methods first. For instant payment methods, the setting usually makes sense. For manual transfers, it can release the key before the payment is verified. In a mixed store, it may be better not to enable auto-completion globally, and to use manual review or separate rules only for digital products.

Quality Control Before Publishing the Product

Before opening sales, run a short but strict review. It should be tied to how WC Serial Numbers Pro behaves, not to generic advice about testing WordPress.

Product Configuration Check

• The Sell Keys checkbox is enabled on the simple product or on each required variation.
• Delivery Quantity matches the sales model: one unit of the product delivers the intended number of keys.
• Key Source is chosen deliberately: manual pool, Generator Rule, or Auto Generated Key.
• The key pool is not empty if a manual source is selected.
• The generator is saved and assigned if Generator Rule is selected.
• A test order has been completed, and the key appears in the order, account, and email.

Customer-Facing Text Review

Open the order page as a test customer. If the customer sees fields such as Activation Count, Activation Email, or Status, but your product does not use software activation, remove unnecessary properties from the display. If the labels are still in English, configure the translations under Settings - Translation. A good order page should answer two questions: which code the customer received and where to use it.

Support and Refund Handling Check

Decide what should happen on cancellation, refund, and failed payment. The documentation describes Reuse Keys and Revoke Keys settings. Reuse Keys helps return an unused key to the pool after a failed or refunded workflow, while Revoke Keys marks a key as invalid on cancellation or refund. The correct choice depends on the product. For a one-time access code, returning it to the pool may be risky. For a software license, revocation on refund is often necessary.

Run a test: place an order, receive the key, then cancel or refund the order in the test environment. Check the key status. If the behavior does not match the store policy, do not open sales until you fix the settings and update the internal support instructions.

Common Issues and Troubleshooting

Problems with WC Serial Numbers Pro usually happen at the boundary between WooCommerce statuses, the key source, and customer-facing display. Do not start troubleshooting by reinstalling the plugin. First identify where the chain broke: the product is not enabled, there are no keys, the order is not completed, the email was not sent, the customer template does not show the field, or the integration expects a different product ID.

The Key Was Not Issued After Payment

Symptom: the customer paid for the order, but the serial number does not appear in the order details, account area, or email.

Likely cause: the order did not reach Completed, the product does not have Sell Keys enabled, an empty manual pool was selected, or the generator is not assigned to the product. The documentation explicitly ties delivery to order completion, so status is the first thing to check.

What to check: open the WooCommerce order and review the status, then open the product and its Serial Numbers tab. For a variable product, check the exact variation that was purchased. In Serial Keys, confirm that there is a key with Available status or that a generation mode is selected.

How to fix it: manually move the test order to Completed and update it. If the key appears after that, the issue is with auto-completion or the handling rules for that payment method. If the key still does not appear, correct the key source and repeat the test with a new order.

The Customer Received a Key for the Wrong Edition

Symptom: a Business or Agency order receives a code with the prefix or properties of another edition.

Likely cause: the settings were applied to the parent product or to the wrong variation. Variable products must be configured inside each variation, and each variation can have its own pool.

What to check: open the order and verify which variation ID was purchased. Then open that variation in the product editor and review Sell Key, Delivery Quantity, Key Source, and the generator. If import was used, confirm that the keys were assigned to the correct variation.

How to fix it: reconfigure the sources by variation, create a new test order for each edition, and do not use old incorrect orders as proof that the fix worked. If the customer has already received the wrong key, resolve it through a manual replacement in the order and an internal support note.

The Import Completed, but the Keys Ended Up in the Wrong Place

Symptom: after a CSV/TXT import, the keys appear under the wrong product, do not have the expected status, or are not being issued.

Likely cause: an incorrect product_id, mixed variations in one file, an unsuitable status, or an attempt to upload too large a batch without testing. CSV gives you more control, but it also requires more care with columns.

What to check: run an export or filter by product and status. Compare a few lines from the source CSV with the actual keys in the admin panel. If the import was intended for variations, verify the variation ID, not just the parent product.

How to fix it: do not re-upload the same file on top of the mistake. First isolate the incorrect records, prepare a small test CSV, import 2-3 rows, and only after a successful check upload a new batch.

The Export Is Empty or Incomplete

Symptom: the CSV exports with headers but no rows, or it does not contain the expected keys.

Likely cause: a filter that is too broad, an unfortunate combination of status and date, or a specific Pro feature bug. In public support, there was an example where selecting a specific product returned rows, while leaving the Product filter empty produced an empty file.

What to check: repeat the export with a product selected, then separately with the status Available or Sold. If a narrower filter works, save the reproduction steps and contact the developer through the Pro support channel.

How to fix it: use more precise filters until an official fix or support response arrives. Do not manually export all keys from the database unless you fully understand the storage structure and the disclosure risks.

Keys Are Not Visible on a WPML Language Domain

Symptom: the key appears in the main language, but the customer cannot see it on another domain or translated order view.

Likely cause: keys are tied to products, orders, and metadata, while a multilingual setup may create separate product IDs and different domain contexts. In public support, PluginEver stated that full compatibility with WPML and multi-domain setups is not guaranteed.

What to check: create a test order in each language, review the product/variation ID, order metadata display, and email. If the store critically depends on WPML, verify this before moving the setup to the live site.

How to fix it: for a key-based store, it is often safer to use one operational delivery language or get a confirmed integration method from the developer. Do not build custom metadata synchronization without testing refunds, emails, and activations.

The API Responds Differently Than the Application Expects

Symptom: the key has been sold, but the application cannot activate it, or validation returns unexpected data.

Likely cause: the wrong product ID, a different email, the wrong instance, activation limit exceeded, the key was revoked, the validity period expired, or the application still uses the old Legacy approach instead of the REST API.

What to check: start with one test key and one /wcsn/validate request. Then test /activate and /deactivate. Do not use real customer keys for debugging in open logs.

How to fix it: align the application parameters with the API documentation and add clear user-facing error messages: "key not found," "activation limit reached," "key expired," and "email does not match." A generic "invalid" error creates unnecessary support load.

Safe Improvements and Practical Admin Habits

With WC Serial Numbers Pro, you should not start with code. Most issues can be solved through settings, roles, test orders, and careful imports. But there are several safe operating habits that improve reliability without touching the plugin files.

Keep a Batch Log Outside the Plugin

If keys come from a supplier, maintain an internal batch log: source, date received, product or variation, quantity, who uploaded it, and which file was used. The article itself does not need dates, but your workflow does. When a customer reports a disputed code, you will be able to trace which batch it came from much faster.

Separate Access Rights

Not every store manager should be allowed to change Duplicate Key, Enable Backorder, Manual Delivery, and generators. These settings can alter the business rules of delivery. Use WordPress roles and internal procedures to define who adds keys, who runs exports, who manually assigns a key to an order, and who can change global settings.

Do Not Store Secrets in Support Tasks

If you are configuring Twilio or an external API integration, do not send the SID, Auth Token, live keys, or admin URLs in open messages. For support, a screenshot with masked values, plus the workflow step, order status, source type, and verification outcome, is enough. Secrets belong in the admin panel and a password manager.

Test Risky Settings With a Separate Order

Before enabling Allow Duplicate Keys, Enable Backorder, Manual Delivery, Reuse Keys, or Revoke Keys, create a dedicated test. These settings can be useful, but they change customer expectations. Selling without stock means the order can be accepted without immediate key delivery. Manual delivery means automatic fulfillment will stop. Allowing duplicates means the same code may reach multiple customers. Each of these settings should have a clear process owner and a clear support workflow.

When WC Serial Numbers Pro Is the Right Choice

WC Serial Numbers Pro is worth using when WooCommerce remains your main sales channel and the key needs to be part of the order. The plugin covers the practical chain: add or generate a key, link it to a product, deliver it after order completion, show it to the customer, monitor stock, import or export batches, revoke or reuse the key when the order status becomes disputed, and connect an API when needed.

The strongest part of the product is not any single feature, but the way WooCommerce order behavior is tied to key management. Simple products get a clear Serial Numbers tab, variations get separate settings, and Pro modes add generators, import, export, SMS, backorder workflows, manual delivery, and control over customer-facing display.

Before launching on a live store, do not stop at installation. Create a test product, configure the key source, place an order, move it to Completed, and check the order in the admin panel, the customer account, the email, key inventory, and export. For variations, repeat the test for each tier. For the API, verify validate, activate, and deactivate with a test key. That review takes less time than dealing with real support requests after sales begin.

If the workflow matches your store model after that, you can download the latest version of WC Serial Numbers Pro and move on to careful testing on your own site. If instead you need a complex multilingual setup, a separate licensing server, or an existing integration built around another plugin, compare the alternatives first and prepare a migration plan with a test batch of keys.