Settings → Integrations connects Stripe, WordPress / WooCommerce, PrestaShop, Wix and Squarespace. Site administrators and owners with write access can create and disconnect connections. Viewers can read their status. Enable Ecommerce in Settings → Modules before connecting a commerce source.

If your site already sends ecommerce data through its server integration or the Kehai WooCommerce plugin, keep that source. No additional Stripe connection is needed, including when Stripe processes the shop's payments.

A site has one active commerce connection. While it is connected, Kehai accepts orders only through that connection's dedicated key. Existing custom commerce keys are not deleted, but their order deliveries are refused. Stop or switch an existing sender before connecting another source, and reconcile its pending deliveries first. Browser visitor tracking continues independently.

These connections send confirmed sales and supported refunds through the same commerce contract: item revenue after discounts, excluding tax and shipping, with each currency kept separate. Creating a connection does not import historical transactions.

Connect Stripe

This connection reads supported payments from the whole Stripe account selected by the API key. It has no product, subscription, or website filter. Use it only when that account's supported sales belong to this Kehai site. It reads Stripe data; it does not create charges or initiate refunds.

In Stripe, create an account-level restricted key with read access to the account, Products, Invoices and invoice line items, Invoice Payments, Checkout Sessions and their line items, Charges, Refunds, and Credit Notes. Keep unrelated permissions disabled. Use rk_live_ or rk_test_. Full secret keys and publishable keys are refused. See Stripe's API key instructions.
In Kehai, select the site, open Settings → Integrations, paste the key into Stripe API key, and choose Connect Stripe.
Follow the setup steps shown below the saved connection. Open Stripe Webhooks and use the same account and live or test mode shown in Kehai. Choose Create event destination or Add destination, then Your account. Leave the API version at Stripe's default and select the five events listed below. If Stripe asks for the payload type, choose Snapshot payloads.
Continue, choose Webhook endpoint, and paste the exact webhook endpoint URL generated by Kehai. If an existing endpoint already uses that exact URL, check its mode, snapshot payloads, and selected events, then reuse it. If it uses a different URL, create a separate endpoint for Kehai and leave the other endpoint unchanged.
Open that destination's Signing secret and choose Reveal secret. Copy its value, starting with whsec_, into Kehai and choose Save signing secret. Use the secret from this exact endpoint, not the API key or another endpoint's secret. Stripe describes these controls in its webhook setup guide.
Use Check connection to verify Stripe API permissions and whether Kehai has a signing secret saved. This check does not inspect the destination in Stripe or confirm that its secret matches. After Stripe sends a signed event, inspect the last received event, last delivered order, pending count, and review count. Stripe's destination also lists event deliveries and their responses. A saved key or secret alone is not delivery confirmation.

invoice.paid
checkout.session.completed
checkout.session.async_payment_succeeded
refund.created
refund.updated

After this one-time setup, Kehai automatically records supported Checkout payments, initial subscription payments, renewals, paid adjustments, and confirmed refunds in the ecommerce reports. Each supported payment becomes one sale even when Stripe sends both a Checkout event and its associated invoice event. A direct PaymentIntent without a supported invoice or Checkout Session is outside this first release.

You do not upload invoices manually. The connection uses Stripe's payment records to report sales and refunds. This connection does not issue invoices or provide accounting.

Test mode does not add test payments to reports. It can verify account access and signed webhook delivery. Disconnect the test connection before connecting the live account and configuring its live endpoint. Pending, failed, or merely completed-but-unpaid payments do not become sales.

Stripe line items must have complete, reconcilable amounts and supported quantities. Collections above 200 rows, unsupported allocation, and missing required information need review rather than a partial or estimated sale. Refunds are recorded only after Stripe confirms success; ambiguous partial tax or shipping allocation needs review. Kehai does not infer a proportional refund breakdown.

WordPress / WooCommerce

One Kehai Analytics plugin handles visitor tracking in WordPress and optional sales reporting in WooCommerce. Its card in Settings → Integrations contains the download and connection controls together.

Download the Kehai Analytics WordPress plugin, then use Plugins → Add New → Upload Plugin in WordPress and activate it. The plugin requires WordPress 6.5 or newer and PHP 8.1 or newer. Activate it separately for each site in a multisite installation.

Open Settings → Kehai Analytics in WordPress.
Copy the public site ID from Kehai's Settings → Install.
Query exclusions come from Kehai Settings and are enforced when events arrive. Changes apply to the next event; nothing needs refreshing.
Enable WordPress tracker and save. Check a public page while signed out of WordPress, then use Kehai's Install diagnostics and Realtime report.

Tracking alone needs no commerce key and no WooCommerce installation. It can run alongside a Stripe commerce connection; use one source for each sale. The plugin loads the ordinary Kehai tracker from the hosted collector and skips administrator views, previews, and DNT/GPC requests. It avoids adding a second recognized Kehai snippet; remove an old manual installation when switching to the plugin. The snippet guide covers normal events and collection limits.

Optional WooCommerce sales and refunds

WooCommerce support requires version 8.2 or newer. It supports the classic checkout, Checkout Blocks, and High-Performance Order Storage. Your payment gateway must confirm payment through WooCommerce's payment-completion hook; a checkout visit or an order status alone is not proof of payment.

In Kehai's Integrations screen, choose Create WooCommerce connection. Save the public site ID and one-time commerce key.
In WordPress's Kehai Analytics settings, enter that site ID and Commerce API key, enable WooCommerce, then choose Save and check connection. The plugin uses Kehai's hosted collector; no endpoint customization is needed.
The connection check verifies the site, domain, key and Ecommerce module and synchronizes the site's query-name exclusions. Enable coupon reporting only if your coupon codes are public campaign codes, not customer identifiers.
After a genuine confirmed payment, inspect Commerce delivery in WordPress and refresh the connection status in Kehai. A newly saved key starts as awaiting an order. Without a plugin status update, queue counts are unknown.

The plugin uses the actual paid time supplied by WooCommerce and persists each delivery with a stable random retry key. Cash on delivery, bank transfers, and manually recorded refunds require an explicit confirmation after the money has actually moved. Use Confirm a manual payment or refund in the plugin, enter the local order or refund ID, supply the actual payment time with a timezone for sales, and confirm the transaction. These local IDs stay in WordPress.

Successful gateway refunds use the recorded refunded amounts and quantities. A manual refund entry without confirmation is not enough. Refunds for a purchase not recorded by this installation need reconciliation first. Ambiguous amount splits, extra fee lines, and unsupported fractional quantities enter review. Multiple coupon codes are omitted from the single coupon dimension while the discount total is retained.

The queue runs through WordPress cron. Low-traffic or paused shops need a working server cron or regular requests; monitor the last queue run and pending/review counts. Retries retain their payload and random key and stop within 47 hours of the first attempt. Do not rotate the key while deliveries are unresolved. Stopping an item does not undo revenue already accepted.

Install the PrestaShop module

The module supports PrestaShop 8.2.x and 9.0.x. Use a PHP version supported by your PrestaShop release, with cURL, OpenSSL and mbstring.

Download Kehai for PrestaShop. In PrestaShop, open Modules → Module Manager → Upload a module, upload the ZIP, then choose Kehai Analytics → Configure. Select one shop first in a multishop installation.
Copy the public site ID from Kehai's Settings → Install. For visitor tracking, paste the ID into the module, enable page tracking and save. Remove an old manual tracker when switching installation methods.
For revenue, enable Ecommerce in Kehai, choose Create PrestaShop connection, and save the one-time commerce key in the module. Enable verified paid orders and use Check connection and save.
Copy the command under Automatic retries to your hosting provider's cron service and run it every five minutes. Keep its token private. The host must forward the Authorization header to PHP.
After an actual payment, use Process queue now or wait for cron. Check the delivery status locally and the last delivered order in Kehai.

A saved paid status and complete payment records are required. A cart or unpaid order is not revenue. Product net, tax and shipping remain separate. Unsupported amounts, shared payment references and ambiguous payment times enter review. An order-wide voucher can retain exact totals while omitting an unavailable product allocation.

A PrestaShop credit slip does not prove that money was returned. After the actual refund, select Confirm money returned in the module. Kehai uses the slip's saved amounts; you do not upload an invoice. Unsupported partial voucher refunds need reconciliation.

The module can retain eligible campaign context from an existing cart. It creates no cart or analytics cookie to reconstruct an earlier landing. Keep cron running for delivery and cleanup. Its packaged README explains retention, supported payment evidence and how to retire the module.

Connect Wix

Create a dedicated Wix API key with Read Orders permission. Keep unrelated permissions disabled. Copy the store's site ID from its dashboard address, after /dashboard/.
In Kehai, select the store's site, enable Ecommerce, then open Settings → Integrations → Wix. Paste the API key and site ID and choose Connect Wix.
Kehai checks updated orders and their payment transactions about every two minutes. Inspect the last payment update, last delivered order and review count after a real payment. No webhook setup is required.
For visitor reports, separately add the ordinary Kehai snippet to Wix's Custom Code, in Head on all pages, once per visit. Publish the site and verify navigation in Kehai's Install diagnostics. Wix requires a published site with a connected domain for custom code.

This is a server connection using your API key, not a Wix App Market installation. Only confirmed supported payments and successful refunds enter revenue. Authorizations, incomplete captures and unsupported allocations remain pending or need review.

Reading an order does not reconstruct its advertising source. A custom checkout integration can place actual retained context in order custom fields named kehai_landing_path, kehai_referrer and kehai_attribution_site. Without these fields, the sale still counts with no supplied landing attribution.

Connect Squarespace

In Squarespace, open Developer tools → Developer API Keys → Generate Key. Name the key Kehai and grant read-only access to Orders and Transactions. Your Squarespace plan must provide both APIs; check its API key availability.
In Kehai, select the same store domain, enable Ecommerce and paste the key under Settings → Integrations → Squarespace. Choose Connect Squarespace.
Kehai checks transaction updates about every two minutes. A saved key confirms access; the last delivered order confirms that a payment reached reports. No webhook or invoice upload is required.
For visitor reports, add the ordinary Kehai snippet through Squarespace's header code injection and publish. Use Kehai's Install diagnostics to verify the published site.

The connector records supported paid web orders and refunds, excluding test orders and donations. Fees charged by a payment processor do not reduce product revenue. Missing tax or shipping allocation and unsupported partial refunds need review rather than an estimated split.

This uses a site API key, not a Squarespace Extensions installation. Campaign attribution requires actual order context explicitly supplied as kehai_landing_path, kehai_referrer and kehai_attribution_site in the order's form submission fields. Connecting the API key alone does not populate these fields or recover an earlier GCLID.

Campaign attribution and Google Ads

Stripe does not know a customer's landing URL automatically. Supply kehai_landing_path and, when known, kehai_referrer in Checkout Session metadata or invoice metadata. For subscription invoices, Kehai can use the subscription metadata snapshot carried by that invoice. A later edit to a subscription does not reconstruct an earlier visit.

Stripe metadata: use actual order context

{
  "kehai_landing_path": "/pricing?utm_source=google&utm_medium=cpc&gclid=REAL_CLICK_ID",
  "kehai_referrer": "https://www.google.com/"
}

When creating a subscription through Checkout, put the context in both metadata and subscription_data.metadata. Stripe copies the latter to the subscription, and its invoice carries a snapshot. These values must come from the actual context your checkout has retained. See Stripe's metadata guide.

A Stripe metadata value can contain at most 500 characters. For a longer path, omit kehai_landing_path, set kehai_attribution_version to 1 and kehai_landing_parts to the number of chunks, then send sequential kehai_landing_path_1 through kehai_landing_path_5 as needed. Each chunk holds at most 500 characters; the whole path must stay within 2,048 characters. Keep every parameter within the ordinary 255-character name/value bounds. An optional kehai_attribution_site binds this context to your Kehai public site ID.

For subscriptions, Kehai checks available invoice history to distinguish the first positive payment from renewals and paid changes. If that history is incomplete or ambiguous, the classification stays unknown while a valid sale still counts as revenue. The Google Ads export can include all eligible payments or only proven initial subscription payments. A first subscription payment does not establish that the customer is new to your business.

WooCommerce captures an eligible page URL only after a WooCommerce session already exists, then attaches the available context to checkout. It does not create a cookie to recover an earlier ad landing. The original GCLID may therefore be missing when the ad visit happened before that session. DNT/GPC opt-outs suppress this context and the associated plugin commerce delivery.

All paths apply the site's configured query exclusions. Missing context remains missing: no attribution is joined from visitor codes, guessed from an email, or manufactured from a campaign name. Eligible paid sales with a retained raw GCLID and actual payment time can use Google Ads CSV or HTTPS exports. Refunds do not automatically adjust previously uploaded Google conversions.

Check status or disconnect

The Integrations screen separates setup from actual delivery. Use its timestamps and pending/review counts alongside the provider or plugin diagnostics. Review messages describe a bounded reason without exposing API keys, signing secrets, or provider customer details. Checking a connection does not make a test purchase.

Disconnecting revokes the dedicated commerce key and erases Kehai's stored connection secrets. Recorded analytics remain. Remove the old webhook or stored plugin key at the provider too. Keep visitor tracking enabled if you still want traffic reports. After disconnecting, reconcile old custom senders before restarting them or connecting a different source.

Any other shop or payment system uses the server-to-server commerce API: your own app or webhook posts each confirmed sale and refund. Visitor measurement needs none of that; the ordinary snippet counts any storefront.

Kehai builds and supports these integrations independently. They do not imply endorsement by the connected platforms. WordPress is a trademark of the WordPress Foundation. WooCommerce and its associated designs are trademarks of Automattic Inc.