Understanding the integration of PadLock's "Get Key Online" feature and the WooCommerce Integration Kit

H

Hermannjt

New member
I am currently using PadLock v2025.2 and the corresponding version of the WC Kit and in the final stage before online Beta Testing. The Padlock Docs (2013 - 2017) touches on the subject but provides on insight into the WooCommerce Integration and the Kit documentation only addresses the "Online Activation" process which I understand; I also have a firm grasp on the workbooks.json configuration and have the Integration Kit properly configured and communicating with WooCommerce (initial setup complete. I have my subdomain, https://activation.mydomainname.me setup and the activation path to the Kit's folder.
Below is as sample snippet from workbooks.json.
Code: 
{
  "products": {
  "1": {
 "title": "My Demo App",
 "xlspadlockprivatekey": "{Some Private Key}",
 "xlspadlockmasterkey": "Some Master Key",
  "variations": {
  "2": {
  "usehardwarelocking": 0,
  "maxactivperorder": 1,
  "keymaxdays": 30,
  "shownagscreen": 1
                },
  "3": {
  "usehardwarelocking": 1,
  "maxactivperorder": 1,
  "keymaxdays": 30,
  "shownagscreen": 0
                }
            }
        },

Using the sample above, I understand the for online activation I would use - https://activation.mydomainname.me/getactivation/3 to actually "Activate" the app. What I do not understand is whether I would use the same structure with the "Get Key Online" feature, e.g., https://activation.mydomainname.me/getactivation/1 (or 2) to get the initial key to open the app in Trial Mode and if yes, does the "/3" activate based on the initial key or does it generate a new Key. Additionally, how does the user receive the new key for their records and/or future use?

**** Update ****

I attempted the Get Key Online using the real workbooks.json config:

Code: 
            "variations": {
  "950": {
  "usehardwarelocking": 0,
  "maxactivperorder": 1,
  "keymaxdays": 15,
  "shownagscreen": 0
                }
            }
        },
and received the following error:

Method Not Allowed​

HTTP 405 (GET /getactivation/950)

Thanks in advance for your assistance.
 
Last edited:
The 405 first, because it is the quickest to clear: the /getactivation/... route only accepts POST. A browser address bar sends a GET, so the Kit correctly answers "405 Method Not Allowed". That is not a sign that your id or your config is wrong, it is simply the endpoint refusing a GET. Activation is performed by the compiled application, which sends a POST with the buyer's data, so test it from the app's activation dialog or from the demo, not by opening the URL by hand: https://demo.xlspadlock.com

Now the part that clears up the model. The number in /getactivation/{id} is the PRODUCT id, that is the top-level key under "products" in workbooks.json. In your file that is product 1, so the call is /getactivation/1. It is not the variation id. You do not choose the trial or the paid variation through the URL: the Kit reads the buyer's actual WooCommerce order, sees which variation they purchased, and applies that variation's rules (shownagscreen, keymaxdays, usehardwarelocking) from workbooks.json. So /getactivation/950 is being read as "product 950", which does not exist in your file, and it would fail for that reason once you are past the GET/405 point. Use the product id (1), and the Kit selects variation 950 from the order on its own.

That also answers the trial-versus-activation question: there is a single activation call, not a separate "get a trial key" step followed by an "activate" step. Whether the key that comes back is a trial key (nag on, time-limited, not hardware-locked) or a full key is decided entirely by the variation the customer ordered in WooCommerce. In other words, the trial-versus-paid choice lives in the order, not in the URL.

On how the key reaches the user: each successful call generates a fresh activation key on demand, server-side, from your product's master key (and the system id when the variation is hardware-locked), and hands it back to the application, which applies it automatically. The user does not copy down a key for the future. On any machine they simply enter their order token (their email plus their WooCommerce order number) and the app fetches and applies the right key, up to the activation count allowed for that order. The Kit records each activated system id against the order, which is how the maximum-activations limit is enforced.

Two things that commonly trip people up while testing: the request has to be a real POST from the app (or the demo), and the WooCommerce order you test with must be in the Completed status, otherwise activation is refused on purpose.
 
gdgsupport said:
Now the part that clears up the model. The number in /getactivation/{id} is the PRODUCT id, that is the top-level key under "products" in workbooks.json. In your file that is product 1, so the call is /getactivation/1. It is not the variation id. You do not choose the trial or the paid variation through the URL: the Kit reads the buyer's actual WooCommerce order, sees which variation they purchased, and applies that variation's rules (shownagscreen, keymaxdays, usehardwarelocking) from workbooks.json. So /getactivation/950 is being read as "product 950", which does not exist in your file, and it would fail for that reason once you are past the GET/405 point. Use the product id (1), and the Kit selects variation 950 from the order on its own.
Click to expand...
Thanks for your reply.

The variation ID "950" is the variation for Product ID 928 in the JSON file. I tried that and still received the same error. I went back and reread the Padlock Docs and the suggestion was to point to a PHP file and pass the id to the kit via that method. I got rid of the 404 and managed to get a 405 error. I have been trying to figure out catch the generateActivationKey function via that route and be able to capture/display the key so the user my copy it for their records and so they may actually open the application (which is the only way the app knows it is in trial mode). I obviously do not understand the order of operations for this functionality.

Any additional insight will be greatly appriciated.
 
Let us separate the pieces, because the "capture and display the key so the user can copy it" step is the part sending you down the wrong path.

The 405. The /getactivation/ route only accepts POST. Opening it in a browser is a GET, so the kit correctly answers 405 Method Not Allowed. That is expected, and it is not about your id or your JSON. Test activation from the compiled app's activation dialog or from the demo, not by typing the URL into a browser: https://demo.xlspadlock.com

The id in the URL. It is the product id, that is the top-level key under "products" in workbooks.json, not the variation id. Variation 950 lives under product 928, so the call is /getactivation/928, and the kit then reads the customer's actual WooCommerce order and applies the variation they bought. Pointing a browser at /getactivation/950 is read as "product 950", which does not exist, so it would fail for that reason too once you are past the GET/405 point.

Now the order of operations, which is the real fix. With the kit you do not fetch a key, show it to the user, and have them type it back. Online activation retrieves the key and applies it automatically. The activation dialog replaces the standard Enter Activation Key dialog: the user enters their token (their order email plus their WooCommerce order number), the app POSTs that to your server, the kit generates the key on the fly from your product's master key and returns it, and the app applies it and restarts. The user never copies a key. There is no wp-activation.php for you to write, and no generateActivationKey call for you to invoke or intercept from your own PHP: the kit does that internally on the POST. The custom-PHP route you are building is fighting the kit rather than using it, which is why you keep landing on 404 then 405.

So "Get Key Online" is not a separate "hand the user a trial key to paste" feature. It is this same online-activation exchange. Whether the key that comes back is a trial key (nag on, time-limited) or a full key is decided by the variation the customer ordered, not by a URL you build.

On the user having a record of the key: that is not part of the app flow and is not needed for them to run the app, because the app already holds the applied key. Their proof of purchase is simply their WooCommerce order. If you want visibility while testing, look at the kit's server side (its activation log and the order record), where each generated key and the system ids activated against the order are recorded, rather than trying to surface the key in the app UI.

If what you actually want is a free trial that opens with no order at all, that is the open-trial-key pattern from your other thread: a single non-hardware-locked trial key (nag on, keymaxdays set), which you can also deliver through the kit. It is still a key the app applies, not a value the user pastes.

One reminder while testing: the request has to be a real POST from the app or the demo, and the WooCommerce order you test with must be in the Completed status, otherwise activation is refused on purpose.
 
I need to further explain my workflow. Firstly, at this time I only offer "simple" products which are different versions of the same (or having slightly different VBA code) Excel Workbook. Secondly, I am legally required (Directive 2011/83/EU) offer a time/condition-based refund which requires being able to open the app with either a "provided" trial key or the ability to "Get Key Online" for the initial trial opening. I understand that I can include a "Read Me" test document in the packaged (Paquet Builder) installer but my desire is to streamline the User Experience by providing the relevant "Product-based" key automatically via email is virtually impossible. I need to have this process as fully automated (hands off) as possible. The customer is buying a specific product, not a variant, trial v. locked; the variants in workbooks.json control the initial and activated behavior.

My understanding of the v2025.2 PadLock documentation is that this is possible by setting up the Get Key Online (Website Interaction) URL = pathToActivationFolder/getactivation/prodID and setting up workbooks.json as shown in the snippet below (I configured there variant IDs as instructed in the kit's documentation but wonder if they actually need to exist because the Product type is actually "Simple" as previously described.

Using the first product ID below the Get Key URL = pathToActivationFolder/getactivation/926 and would default to the key configured in the variant (947) which is the trial key configuration, thereby activating it in Trial Mode. When the Buyer decides to activate their purchase (Online Activation) the pathToActivationFolder/getactivation/949/+ the System ID and the buyer enters their purchase token (email + purchaseID) automatically provided at purchase time.

Code: 
{
  "products": {
  "926": {
 "title": "My App Beta",
 "xlspadlockprivatekey": "{My Beta App Private Key}",
 "xlspadlockmasterkey": "My Beta App Master Key ",
  "variations": {
  "947": {
  "usehardwarelocking": 0,
  "maxactivperorder": 1,
  "keymaxdays": 30,
  "shownagscreen": 1
                },
  "948": {
  "usehardwarelocking": 1,
  "maxactivperorder": 1,
  "keymaxdays": 30,
  "shownagscreen": 0
                }
            }
        },
  "929": {
 "title": "My App Perpetual",
 "xlspadlockprivatekey": "{My Perpetual App Private Key}",
 "xlspadlockmasterkey": "My Perpetual App Private Key",
  "variations": {
  "953": {
  "usehardwarelocking": 0,
  "maxactivperorder": 1,
  "keymaxdays": 30,
  "shownagscreen": 1
                },
  "954": {
  "usehardwarelocking": 1,
  "maxactivperorder": 1,
  "shownagscreen": 0
                }
            }
        }

As I understand the 2025.* documentation this is the default behavior. IF the Get Key feature is not configured the initial screen displays only the "Enter Key" field without the Get Online button.

The move to v2026.* compounds this problem because it defaults to asking for the Token, but to get access to the Key Entry screen one must click the Manual Activation button to gain access to the Key Entry screen and the included Get Key Online button (If configured). This may be fine for subscription-based products which have no trial period, but it is counter-intuitive for simple products and forces an additional step that is not apparent to the end user/buyer.

I hope this clarifies my initial question and I look forward to your guidance on this issue.
 
Thank you for spelling out the workflow, because it changes the answer, and it also shows that two of our earlier statements sent you in the wrong direction. Your design is built on them, so let us correct both first.

First, in a previous reply we wrote that an open trial with no order at all could "also be delivered through the kit". That was wrong, and we are sorry for the confusion. The kit cannot issue any key without a WooCommerce order behind it: every activation call resolves a real order from the token (the buyer's email plus the order number), checks that the order is Completed and contains the product, and only then generates a key. With no purchase there is nothing to resolve, so a pre-purchase trial can never come from the kit.

Since the kit is out of the picture before a purchase, generate the trial key yourself, once, in advance, with the key generator in XLS Padlock: not hardware locked, keymaxdays set to your trial length, nag screen enabled. That key is then the same for every copy you distribute, and that is precisely what makes the process hands off: there is nothing to generate per user and nothing to email. Publish it with the download itself, on the download page or in the installer's readme or final page (Paquet Builder can display it at the end of the install), so the user already has it when the app first opens. It is deliberately a low value key: time limited, nag on, not locked to any machine. To be transparent, there is no mechanism to pre-apply or embed a key inside the compiled workbook, so the user does enter this trial key once at first launch; but they never wait for anything, and your server is not involved in the trial at all, which also keeps your withdrawal right coverage independent of your infrastructure.

Secondly, we also answered "product id, not variation id" twice, which was true but incomplete for your case. Here is the exact behaviour. The kit matches the product id from the URL against the order lines. A simple product carries no variation on the order line, so the kit then falls back to the first entry of that product's "variations" block in workbooks.json and applies its settings. Two consequences:

  1. Yes, the "variations" block must still exist for a simple product, with at least one entry. The numeric id of that entry is arbitrary, it is never matched against anything.
  2. Only the first entry is ever applied. Any further entries are dead configuration for a simple product. There is no way for one purchase to resolve to 947 and another to 948: both will always resolve to 947.
Please check this before your beta, because as posted your file would misfire for real buyers: every purchase of product 926 would receive a key with the 947 profile, that is a 30 day, nag screen, non hardware locked key. And product 929 "My App Perpetual" would issue 30 day keys as well, since its first entry (953) has keymaxdays set. The fix is one entry per product, carrying the paid profile: the 948 settings for 926, the 954 settings for 929, and no keymaxdays in any paid profile that should not expire.

Where the 405 really came from, and which URL goes where. "Get Key Online" (Website Interaction page) is a plain browser button: it opens the configured URL in the user's web browser, which is a GET. The kit's /getactivation endpoint only answers POST requests from the compiled application, so pointing that button at the kit can only ever produce the 405 you saw, whatever ids you use. The two URLs belong to different pages of the project:

  • Online Activation page, Base Activation URL: this is where the kit endpoint goes, with the product id, for example https://activation.mydomainname.me/getactivation/926 for the Beta project and /getactivation/929 for the Perpetual one. The application POSTs to this URL exactly as entered; do not append the system id or anything else, the application sends all of that in the POST body on its own.
  • Website Interaction page, Get Key Online: an ordinary web page for humans, typically your store or product page. You can also leave it unconfigured, it is not needed for this workflow.
Your point about the activation screens, which we have now verified in the source code.

The order of the two screens did not change between 2025.2 and 2026: that code is identical in both versions. What decides the first screen is the project configuration. As soon as online activation is configured, that is, a Base Activation URL is set, the token screen comes first and the key entry screen sits behind Manual Activation, in 2025.2 exactly as in 2026. A build packed without an activation URL leads with the key entry screen instead, with the Get Key Online button on it when configured, which is precisely the behaviour you remember. So the difference between your two builds comes from the project, not the version: the earlier one was packed before the activation URL was set. If you still have that old project file, you can confirm it in two seconds: its Base Activation URL field on the Online Activation page will be empty.

There is currently no setting that reorders the screens: with online activation configured, token first is the only behaviour. Keep "Allow Manual Activation if No Internet Connection" checked, since unchecking it would remove the only path to the key entry screen. Your argument that a simple product with a public trial key would rather lead with key entry is a fair one, and I am passing it on as product feedback, but I do not want to promise a change here.

So the first launch trial flow in your setup is: token screen, click Manual Activation, enter the trial key. One extra click, and you can soften it: the content of the token screen is yours to edit through the Registration Form Editor (your email and order number fields already come from there), so you can add a line telling trial users to click Manual Activation and enter the trial key shown on your download page.

After that the flows separate cleanly. The trial user sees the nag screen at each launch, with the remaining days and a Purchase Online button. When they buy, they use the Enter Activation Key button from that screen (leave the "Disable the Enter Activation Key button" option unchecked in your project), the token screen appears, and this time it is the right screen: they now have an order email and an order number, the app POSTs them to the kit, and the paid key replaces the trial one automatically.

If you rework workbooks.json as above and anything does not behave as described, post the details here and we will work through it.
 
Last edited:
gdgsupport said:
Thank you for spelling out the workflow, because it changes the answer, and it also shows that two of our earlier statements sent you in the wrong direction. Your design is built on them, so let us correct both first.

First, in a previous reply we wrote that an open trial with no order at all could "also be delivered through the kit". That was wrong, and we are sorry for the confusion. The kit cannot issue any key without a WooCommerce order behind it: every activation call resolves a real order from the token (the buyer's email plus the order number), checks that the order is Completed and contains the product, and only then generates a key. With no purchase there is nothing to resolve, so a pre-purchase trial can never come from the kit.

Since the kit is out of the picture before a purchase, generate the trial key yourself, once, in advance, with the key generator in XLS Padlock: not hardware locked, keymaxdays set to your trial length, nag screen enabled. That key is then the same for every copy you distribute, and that is precisely what makes the process hands off: there is nothing to generate per user and nothing to email. Publish it with the download itself, on the download page or in the installer's readme or final page (Paquet Builder can display it at the end of the install), so the user already has it when the app first opens. It is deliberately a low value key: time limited, nag on, not locked to any machine. To be transparent, there is no mechanism to pre-apply or embed a key inside the compiled workbook, so the user does enter this trial key once at first launch; but they never wait for anything, and your server is not involved in the trial at all, which also keeps your withdrawal right coverage independent of your infrastructure.

Secondly, we also answered "product id, not variation id" twice, which was true but incomplete for your case. Here is the exact behaviour. The kit matches the product id from the URL against the order lines. A simple product carries no variation on the order line, so the kit then falls back to the first entry of that product's "variations" block in workbooks.json and applies its settings. Two consequences:

  1. Yes, the "variations" block must still exist for a simple product, with at least one entry. The numeric id of that entry is arbitrary, it is never matched against anything.
  2. Only the first entry is ever applied. Any further entries are dead configuration for a simple product. There is no way for one purchase to resolve to 947 and another to 948: both will always resolve to 947.
Please check this before your beta, because as posted your file would misfire for real buyers: every purchase of product 926 would receive a key with the 947 profile, that is a 30 day, nag screen, non hardware locked key. And product 929 "My App Perpetual" would issue 30 day keys as well, since its first entry (953) has keymaxdays set. The fix is one entry per product, carrying the paid profile: the 948 settings for 926, the 954 settings for 929, and no keymaxdays in any paid profile that should not expire.

Where the 405 really came from, and which URL goes where. "Get Key Online" (Website Interaction page) is a plain browser button: it opens the configured URL in the user's web browser, which is a GET. The kit's /getactivation endpoint only answers POST requests from the compiled application, so pointing that button at the kit can only ever produce the 405 you saw, whatever ids you use. The two URLs belong to different pages of the project:

  • Online Activation page, Base Activation URL: this is where the kit endpoint goes, with the product id, for example https://activation.mydomainname.me/getactivation/926 for the Beta project and /getactivation/929 for the Perpetual one. The application POSTs to this URL exactly as entered; do not append the system id or anything else, the application sends all of that in the POST body on its own.
  • Website Interaction page, Get Key Online: an ordinary web page for humans, typically your store or product page. You can also leave it unconfigured, it is not needed for this workflow.
Your point about the activation screens, which we have now verified in the source code.

The order of the two screens did not change between 2025.2 and 2026: that code is identical in both versions. What decides the first screen is the project configuration. As soon as online activation is configured, that is, a Base Activation URL is set, the token screen comes first and the key entry screen sits behind Manual Activation, in 2025.2 exactly as in 2026. A build packed without an activation URL leads with the key entry screen instead, with the Get Key Online button on it when configured, which is precisely the behaviour you remember. So the difference between your two builds comes from the project, not the version: the earlier one was packed before the activation URL was set. If you still have that old project file, you can confirm it in two seconds: its Base Activation URL field on the Online Activation page will be empty.

There is currently no setting that reorders the screens: with online activation configured, token first is the only behaviour. Keep "Allow Manual Activation if No Internet Connection" checked, since unchecking it would remove the only path to the key entry screen. Your argument that a simple product with a public trial key would rather lead with key entry is a fair one, and I am passing it on as product feedback, but I do not want to promise a change here.

So the first launch trial flow in your setup is: token screen, click Manual Activation, enter the trial key. One extra click, and you can soften it: the content of the token screen is yours to edit through the Registration Form Editor (your email and order number fields already come from there), so you can add a line telling trial users to click Manual Activation and enter the trial key shown on your download page.

After that the flows separate cleanly. The trial user sees the nag screen at each launch, with the remaining days and a Purchase Online button. When they buy, they use the Enter Activation Key button from that screen (leave the "Disable the Enter Activation Key button" option unchecked in your project), the token screen appears, and this time it is the right screen: they now have an order email and an order number, the app POSTs them to the kit, and the paid key replaces the trial one automatically.

If you rework workbooks.json as above and anything does not behave as described, post the details here and we will work through it.
Click to expand...
Thank you or your detailed reply. It confirms, in part my presumption(s) regarding workbooks.json setup. I will return to this thread later. I am dealing with an Excel version-based packaging issue and will create a new post specific to that issue after a bit more research/testing.

Thanks again for your assistence.
 
You must log in or register to reply here.
Back
Top