PENDING_INSTALL subscription plus an
operator install job instead.
kurnl does not ship a WooCommerce plugin. Connecting your store is a small
server-to-server integration your developer builds against kurnl’s
external-checkout API: read the checkout session, call
kurnl when an order is paid, and — because you bill — tell kurnl to
suspend/restore when a subscription payment fails or recovers. This keeps your
store fully under your control and unaffected by kurnl releases.
WooCommerce stays your source of truth for the catalog, pricing and
billing. kurnl never charges the shopper — it only creates the subscriber and
configures the network port.
What’s involved
Selling through WooCommerce is an external checkout (CKO-03) with WooCommerce as the storefront. It needs a developer to wire your store to kurnl once; after that it runs on its own.- The shopper selects a plan in the kurnl marketplace.
- kurnl creates a checkout session and redirects them to your store’s checkout
URL with a
session_id. - Your store reads the session (kurnl API), shows the matching WooCommerce product, and the shopper pays.
- On payment, your store calls kurnl to provision the subscription.
- Your store then sends the shopper back to the kurnl marketplace return page —
https://<marketplace-host>/external-checkout/return?session_id=<id>— which polls the public session-status endpoint and shows provisioning progress. Without this redirect the shopper is stranded on your thank-you page with no service status. - When your billing puts a subscription on-hold or active again, your store tells kurnl to suspend or restore the port.
Prerequisites
- A WooCommerce store — any setup works; kurnl never touches your store.
- The WooCommerce Subscriptions extension and a tokenising gateway (Stripe / WooPayments) for recurring billing.
- One WooCommerce product per kurnl plan you want to sell. Keep your own SKUs and prices — WooCommerce owns them.
- A developer to implement the kurnl external-checkout API in your store (session read, order-paid callback, and suspend/restore hooks).
Step 1 — Checkout settings in kurnl
1
Choose the external checkout type
In the dashboard, open Checkout and pick External checkout (your own store). WooCommerce is one kind of external store — there is no separate WooCommerce mode.
Then set:
- Store checkout URL — where kurnl sends shoppers to pay (the page your store serves).
- Shared webhook secret — generate it here; your store sends it as
X-Webhook-Secreton every call to kurnl.
kurnl never calls into your WooCommerce store, so no WooCommerce REST API
keys are needed. If you pasted WooCommerce consumer key/secret here in the
past, they were never used — the fields have been removed.
2
Mint an API key (optional)
On the API Key page, generate a
krnl_… key if your integration also
reads plan data or reports. The checkout callbacks themselves authenticate
with the shared webhook secret, not the API key.Step 2 — Connect your store (developer)
Your developer wires four things into the store. Each is covered in the partner guides — this is the WooCommerce mapping:1
Read the session on the checkout page
When kurnl redirects the shopper to your store with
?session_id=…, fetch
the session — GET /external-checkout/sessions/{session_id} with your
shared secret as X-Webhook-Secret — to learn which plan and location they
chose, then add the matching WooCommerce product to the cart. See
Direct delivery.2
Provision on a paid order
Hook WooCommerce’s order-paid / order-completed event and call
POST /external-checkout/complete with the session and the shopper’s
details. kurnl creates the subscriber; what happens next depends on the
building’s line type: first-line buildings are provisioned immediately
(the response carries a job_id), while second/third-line or unclassified
buildings get a PENDING_INSTALL subscription plus an operator install job
— and the response has no job_id. Treat job_id as optional, and
handle a 422 (unclassified building with no unit on the session).3
Send the shopper back to kurnl
After calling
/complete, redirect the shopper from your thank-you page to
https://<marketplace-host>/external-checkout/return?session_id=<id>. That
page polls the public
GET /external-checkout/sessions/{session_id}/status endpoint and shows
the shopper their provisioning progress.4
Sync suspend / restore from your billing
Because WooCommerce owns billing, map the WooCommerce Subscriptions
on-hold / active hooks to
POST /external-checkout/subscription-status
(suspend / restore) so a failed payment actually cuts service and a
recovery restores it. See
Suspend / restore.Step 3 — Test the integration
1
Test the callbacks in the sandbox
The redirect leg cannot be tested against a staging store: for a
sandbox provider, session creation ignores your Store checkout URL and
redirects to a kurnl-internal fake-payment page instead. What you can
sandbox-test are the callbacks —
/complete and /subscription-status —
using the sandbox provider id and sandbox webhook secret from
GET /sandbox/provider-info. See Sandbox.2
Run one plan end-to-end against a test location
From the marketplace, start a checkout for a plan at a test location you
control. Confirm your store shows the right product, pay with a gateway
test card, and check the subscription appears in kurnl and the shopper
lands back on the kurnl return page.
Troubleshooting
- Nothing to buy at the store — your integration didn’t resolve the session
to a product. Log the
session_idand theGET /external-checkout/sessions/{session_id}response (send yourX-Webhook-Secret) and confirm the plan maps to a published WooCommerce product. - Service not cut on a failed payment — check your WooCommerce Subscriptions
on-hold hook is calling
subscription-statuswithaction: "suspend".