What you can do without programming
You can connect your WooCommerce store, map products to license plans and deliver real customer licenses after eligible confirmed orders. You do not need to write a REST client for that.
The software you sell still needs an app-side SDK integration. Installing the store connector does not automatically put a license check inside any Python/Windows/macOS app. Start with a test product and Test payment mode.
1. Install the current connector
In your KDPika workspace open WooCommerce. Choose Download WordPress plugin. In WordPress go to Plugins → Add New → Upload Plugin, select that ZIP, install and activate it. Keep WordPress/WooCommerce updated and use a staging store for this trial if you already sell real products.
Open KDPika Licensing → Overview. Choose Connect to KDPika.
Connect to KDPika
SandboxSell your software. We handle licensing.
Sign in to the intended developer workspace and approve the correct store/products. Never paste a developer management key into WordPress pages or customer content.
2. Approve the right store and workspace
Sign in to your developer account when asked. Check the store address and workspace name. Select permitted software products if they already exist. Review the environment/permission choices shown on your current connection screen, then choose Approve and return to WordPress.
Connect WooCommerce
SandboxReview the workspace and real store address before approval. The store can manage only its permitted products and issued licenses.
Do not approve a store or address you do not recognize. If the request expired, start again from the plugin rather than reusing an old link. Manual connection is available as a recovery path; use its one-time credential, not a public management secret.
3. Import the products you want to license
In the connected store's KDPika workspace page, choose Import store products. Select only the actual software products/variations you want. Review the imported offers and device/fallback settings before completing setup. Product names, variation attributes, price, currency and schedule come from your store; any missing/ambiguous access rule needs your review instead of being guessed.
The importer prepares product App IDs, license plans and mappings together. You can also map an already-existing workspace product/plan. Importing is not a payment or a purchase by itself.
4. Check each product or variation mapping
In WordPress open KDPika Licensing → Products. Find the correct variation by its attributes, ID, SKU and price. Select the software product/plan and enable licensing for it.
Product mappings
SandboxMap the actual variation you sell. Parent mappings are not inherited by all variations. A completed eligible order issues licenses without your customer manually calling the SDK.
Choose when to issue the license, then Save all visible mappings. A parent product mapping is not inherited by every variation; review Monthly/Annual or Personal/Team variations separately. If the product cannot be chosen, check its active license plan and the approved product scope; use Sync now or the catalog refresh rather than reconnecting repeatedly.
5. Make one Test order
- Confirm the payment gateway is in Test mode and that you are using its test checkout instructions. Do not enter a real card for this learning exercise.
- Buy your mapped test software product in the store. Let WooCommerce confirm the eligible paid/completed state for the selected issue rule.
- Open KDPika Licensing → Orders and look for a synchronized license outcome. Repeated notifications/retries must reuse the same issued license, not create another.
- Check the corresponding Sandbox license in your workspace, customer order/email and My Account → My Licenses.
The connector follows the supported gateway's verified Test/Live payment evidence per order. The workspace header choice alone does not determine an order's payment mode. Unsupported/ambiguous mode stays under review rather than creating a guessed Live license. A valid zero-total completed order has its own eligibility rules; don't label it paid by a gateway that was never called.
6. See what your customer receives
The signed-in customer sees their own purchased software licenses in My Licenses. They may copy an authorized key and see status, expiry, allowance and, where applicable, balances/shared-seat usage.
My Licenses
SandboxStore My Licenses and the KDPika hosted portal are separate views. Only the signed-in customer’s authorized purchased licenses are available.
The plugin's Settings can control the customer license display/email options already available. Keep customer emails, order permissions and private pages configured correctly. Store My Licenses is not the hosted KDPika customer portal; the portal has its own verified sign-in.
7. Adjust limits from WordPress when needed
In your KDPika workspace's WooCommerce connection, explicitly enable Edit license settings from this store and save the editing permission. This is important access control; the connector does not silently give every store manager permission to change shared plans.
In WordPress Products → License settings, choose the mapped plan and Edit plan. For one customer use Licenses → Limits & overrides. Use Sync now when you need to request a refresh immediately.
License settings
SandboxEditing access from the store requires explicit workspace permission. The server remains authoritative; background refresh is not a promise of instant updates while the store is offline.
The same authoritative server settings are used on both sides. Shared plan edits can affect licenses issued outside this store when existing-license scope is selected. Open pages refresh automatically; closed/offline stores catch up on later background runs/visits. This is not a promise of instant delivery without connectivity.
8. What each licensing feature means for the store
| Feature | Store role | App role |
|---|---|---|
| Device allowance | Issue the chosen software license and expose permitted limits | SDK activates real machines and enforces the signed result |
| Offline checks / hardware matching | No raw desktop fingerprint collector in WordPress | Native SDK verifies device binding and signed deadlines |
| Floating seats | Plans/licenses can carry shared-seat settings; My Licenses shows usage | Running app checks out, renews and releases its seat |
| Usage credits | Current balance can be shown; buying a product does not automatically top up credits in this release | Grant via trusted dashboard/API, then confirm each online consume before the job |
| Customer portal / brand | You may link to the real hosted publisher sign-in | Portal handles verified access and allowed self-service; no payment checkout there |
| Overrides / audit | Permitted store manager can edit mapped access, with review/history | SDK checks updated effective access on its next eligible check |
9. Before real sales
Use an eligible KDPika plan with Live licensing, map real offers carefully and switch the actual gateway to Live deliberately. Test order confirmation, customer delivery, your app's SDK activation and renewals/refund outcomes using your supported order model. A connector update is available through WordPress; publishing it does not force-install it on your store.
Check the full loop: confirmed order → one issued license → correct email/account display → your app activates with that key → protected feature works. If an order needs attention, read its confirmed reason and use the safe retry; do not blindly issue another key.
All beginner paths · Full visual dashboard feature walkthrough · WooCommerce integration reference.