> For the complete documentation index, see [llms.txt](https://docs.intelligems.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.intelligems.io/pricing-experiences/price-testing-integration-guides/price-testing-with-kaching-bundles.md).
# Price Testing with Kaching Bundles
You can run an Intelligems Price Test on a store that uses the **Kaching Bundles** quantity-break widget. There are three ways to do it. The right one depends on how many products you're testing and how your Kaching deals are set up.
{% hint style="info" %}
**Recommended:** for most price tests, use **Intelligems Quantity Buttons** in place of the Kaching widget on the products you're testing. They work with Price Tests automatically, so prices update by test group with no extra setup. If Kaching's offer is important to your merchandising, you can keep it using Option 2 or Option 3 below.
{% endhint %}
## Why Kaching needs a little setup
When you run a Price Test, Intelligems updates prices in two places. The first is the cart and checkout, which is the amount the customer actually pays. The second is the front end, which is the price shown on the product page and inside the widget.
The cart and checkout side is handled by Shopify Cart Transform Functions and works correctly. The gap is the price shown inside the Kaching widget. Kaching's widget doesn't expose the product's variant ID in a way Intelligems can read, so we can't automatically tell which price to write into the widget.
| Kaching widget | Cart | Checkout |
| ------------------- | --------------------------------------- | --------------------------------------- |
| Shows old price :x: | Correct test price :white\_check\_mark: | Correct test price :white\_check\_mark: |
{% hint style="info" %}
Nothing is broken in the transaction. The correct price is always applied at cart and checkout. This is only a display gap inside the widget, and the options below fix it.
{% endhint %}
## Your three options
### Option 1: Switch to Intelligems Quantity Buttons (recommended)
Replace the Kaching quantity/bundle widget with our native Quantity Buttons on the products you're testing. Our buttons are built for price testing, so prices update automatically based on the visitor's test group, with no per-product edits.
* **Best for:** most price tests, especially if you'll run more than one over time.
* **Effort:** one-time setup, then it's automatic.
See our guide on setting up a price test with Quantity Buttons [here](https://docs.intelligems.io/offer-personalizations/how-to-set-up-a-price-test-with-quantity-buttons).
### Option 2: Keep Kaching, fix the display with Content Edits
Keep your Kaching widget and use the Intelligems Visual Builder to correct the prices shown inside the widget for each test group. Intelligems still applies the real price change at cart and checkout. The onsite edit just makes the widget's displayed number match.
* **Best for:** testing a small number of products (roughly 3-5), where a few manual edits are manageable.
{% hint style="warning" %}
**Two limits to check first:**
**Discount type.** This works only if your Kaching tiers use a percentage-off or dollar-amount-off discount. If a bundle uses a specific price (for example, "2 pillows for $89"), Kaching hardcodes that number and it overrides the test price everywhere, including cart and checkout, so this route won't work.
**Variants at different prices.** An onsite edit is a single static replacement. If your widget has a variant selector where the variants have different prices, the edit can't follow the customer's selection. Use Option 1 or 3 instead, or hide the higher-priced variants from the bundle.
{% endhint %}
The quickest way to make this edit is with **Viv**, our AI Visual Builder (learn more [here](https://docs.intelligems.io/general-features/visual-builder/ai-visual-builder)). Open the Visual Builder on your test, click the AI Assistant, and describe the change. Viv previews it live before you apply it. Here's a starter prompt you can paste in and adjust (fill in the bracketed parts):
```
Context: I'm running an Intelligems price test on this product and I'm keeping my Kaching Bundles widget on the product page. Intelligems is already applying the correct test price in the cart and at checkout, so the amount customers pay is right. The only problem is the price displayed inside the Kaching bundle widget. It still shows the original (control) price instead of this test group's price.
What I need you to do:
- Find the price figures inside the Kaching bundle widget on this page (the per-tier prices and any "total" or "per item" prices it shows).
- Update ONLY those displayed numbers so they match this test group's pricing:
1 item = [test price for 1]
2 items = [test price for 2]
3 items = [test price for 3]
(add or remove tiers to match this product's bundle)
- If the widget shows a "you save" amount or a per-unit price, recalculate those so they stay consistent with the new numbers above.
Do NOT change any of the following:
- the cart, the mini-cart, or anything at checkout
- the Add to Cart / buy button, its text, or its behavior
- the product's real Shopify price or variant selection
- the widget's layout, styling, spacing, or any other section of the page
This is a display-only text edit inside the Kaching widget. When you're done, list exactly which price elements you changed so I can QA them before I apply.
```
{% hint style="info" %}
The prompt above covers one test group. Repeat it for each additional test group, swapping in that group's prices.
{% endhint %}
{% hint style="warning" %}
**Always preview and QA Viv's result.** Viv can sometimes shift the widget's layout or misread bundle and subscription pricing. Confirm the widget still renders correctly and that the cart and checkout prices are untouched before you start the test.
{% endhint %}
For the mechanics of onsite edits, see our guides on the [Visual Experience Builder](https://docs.intelligems.io/general-features/visual-builder) and [how to set up an onsite edits test](https://docs.intelligems.io/content-testing/content-testing-getting-started/how-to-set-up-an-onsite-edits-test).
### Option 3: Keep Kaching, use the Duplicate Products integration
We set the test price directly on duplicate versions of your products, and you set your Kaching deals up on those duplicates. Because the test price is baked into the duplicate product's actual Shopify price, Kaching's own logic for bundles, free gifts, and quantity breaks keeps working normally in every test group.
* **Best for:** testing many products or your whole store, or any case where you want to keep Kaching's full bundle behavior.
* **Effort:** an integration our team completes for you, usually within a few business days. You'll set your Kaching deals up on the duplicate products.
See our integration guide using duplicate products [here](https://docs.intelligems.io/price-testing/price-testing-integration-guides/integration-guide-using-duplicate-products).
## Which should I use?
| Your situation | Recommended option |
| --------------------------------------------------- | ------------------------------------------------------- |
| You're open to changing the widget | Option 1 - Quantity Buttons |
| Keeping Kaching, testing a few products, % or $ off | Option 2 - Onsite Edits |
| Keeping Kaching, testing many products or sitewide | Option 3 - Duplicate Products |
| Kaching uses specific bundle prices ("2 for $89") | Option 1 or 3 (Option 2 won't work) |
| Kaching widget has variants at different prices | Option 1 or 3 (Onsite Edits can't follow the selection) |
## Before you launch: QA the test
Whichever route you choose, QA the test before and after launch. Confirm that the displayed price, the cart price, and checkout all match the intended test group for every variant in the test.
{% hint style="success" %}
Run through our Price Test QA Checklist [here](https://docs.intelligems.io/price-testing/price-test-qa-checklist) to check pricing across the PDP, widget, cart, and checkout for each test group.
{% endhint %}
## Frequently asked questions
Why does the widget show the old price but the cart is correct?
The Kaching widget doesn't expose the variant ID Intelligems needs to rewrite the displayed price, so the widget number can lag. Your cart and checkout prices are handled separately by Shopify Cart Transform Functions and stay correct, so the customer always pays the right test-group price. Options 1 through 3 fix the display gap.
Do I have to stop using Kaching to run a price test?
No. Options 2 and 3 let you keep Kaching. We only recommend Quantity Buttons because they remove the extra setup. It's a convenience, not a requirement.
My Kaching deal is "2 for $89." Can I still test the price?
Not with Onsite Edits (Option 2), because a specific price is hardcoded by Kaching and overrides the test price everywhere. Use Quantity Buttons (Option 1) or the Duplicate Products integration (Option 3) instead.
How long does the Duplicate Products integration take?
Usually a few business days. Our team handles the integration, and you'll set up your Kaching deals on the duplicate products once they're created.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.intelligems.io/pricing-experiences/price-testing-integration-guides/price-testing-with-kaching-bundles.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.