How to Add Kaching Bundles to a Replo Landing Page (Without Wrong Cart Items)

The simplest way to add Kaching Bundles to Replo is to drag Replo’s native Kaching Bundles Widget inside the Product Component that owns the product and Add to Cart button. Before doing that, install Kaching, publish an eligible deal for the product, and enable the Kaching app embed in your Shopify theme.

Then remove competing Replo quantity and variant selectors from that Product Component, keep only one Kaching embed inside it, and test the published page through cart. The widget is not expected to appear inside the Replo editor, so editor visibility is not your release test.

⚡ ShopSideK Verdict

Use Kaching Bundles & Upsells inside Replo when you want Kaching to own the offer and keep the same app-managed deal across Replo and other Shopify storefront surfaces.

Best path: Replo Product Component → native Kaching Bundles Widget → one responsive embed → published page-to-cart QA.

Use Replo’s native Bundle Builder instead when: The offer is Replo-only, its product/variant and reward controls cover the requirement, and you do not need an unsupported native-builder feature such as subscription products.

Hold the launch when: Two systems still control quantity, variants, or Add to Cart—or any tested tier sends the wrong product, variant, quantity, discount, or cart line.

Unlock 20% OFF Kaching for your first 3 months →

Choose Kaching or native Replo before placing anything

The first decision is not where the widget should sit. It is which system should own the bundle.

Replo’s current bundle-app guidance calls its native Bundle Builder the first choice for many Replo use cases while also listing Kaching as a supported integration. That makes the comparison legitimate rather than a reason to default to either tool.

Use the smallest architecture that covers the actual offer:

Replo’s native Bundle Builder documentation currently lists product-based and variant-based bundles, percentage or fixed-amount discounts, and tiered rewards. If that covers a page-specific offer, a separate bundle app may be unnecessary.

Kaching becomes more compelling when the merchant already uses its Quantity Break, BXGY, or Bundle Upsell deals elsewhere and wants Replo to become another presentation surface—not a second source of offer logic.

Do not choose Kaching merely because this article is about Kaching. Choose it when centralized Kaching control is worth the integration boundary.

Follow four product-form ownership rules

Most Replo–Kaching failures become easier to understand when you stop thinking in terms of visual placement and start thinking in terms of ownership.

Rule 1: Put Kaching inside the Product Component

A Replo Product Component supplies the product context and purchase form. Replo’s Kaching integration guide says the Kaching component should sit inside that Product Component.

A widget placed nearby can look as though it belongs to the buy box while still missing the form scope it needs.

Before adding Kaching, identify:

• the Product Component that owns the Add to Cart button;
• the Shopify product assigned to it;
• whether the page is a standalone landing page or a dynamic Product Template;
• whether that product has an eligible published Kaching deal.

For a dynamic Product Template, keep the product relationship dynamic unless the page is deliberately fixed to one product. A hard-coded product in the wrong context can make a reusable template show or submit the wrong offer.

Rule 2: Use one Kaching embed per Product Component

Replo documents that when multiple Kaching embeds sit inside the same Product Component, the first embed can determine the quantity added.

This often happens when a merchant builds one desktop buy box and a second mobile buy box, then hides each at the opposite breakpoint. Hidden components can remain in the page structure; visual hiding does not necessarily remove their references.

Use one Kaching embed and change its spacing, width, typography, and surrounding layout with Replo’s responsive controls. Replo’s own page-building best practices also recommend responsive styling instead of duplicating and hiding whole desktop/mobile sections.

If separate layouts are unavoidable, Replo’s Kaching guide says the Kaching components should live in separate Product Components. That architecture needs a more careful transaction test because the page now contains more than one product form.

Rule 3: Give quantity and variant state one owner

Replo Product Components normally support Replo quantity and variant selectors. That general capability does not mean those controls should remain active beside Kaching.

Replo’s Kaching-specific instructions say its quantity or variant selectors are not recommended inside the same Product Component. When Kaching is present, the options selected in Kaching override the Replo selectors for that component’s Add to Cart button.

Two visible controls create an ambiguous promise:

• the shopper chooses one variant in Replo;
• the shopper chooses another variant or tier in Kaching;
• only one state reaches cart.

If Kaching owns the bundle, let Kaching own the tier and any bundle-level variant selections it supports. Remove or disable the competing Replo controls unless you have documented, reproduced evidence for the exact combined behavior.

Rule 4: Give Add to Cart one owner

Replo supports powerful Add to Cart interactions, including adding several products or chaining actions. Replo’s Kaching guide says the Kaching widget takes precedence over those interactions.

Do not attach an independent Replo multi-product Add to Cart sequence to the same button and expect it to merge cleanly with the Kaching selection.

Start with one ordinary submit path:

1. shopper selects the Kaching tier and variants;
2. shopper uses the Product Component’s Add to Cart action;
3. Kaching’s selected state supplies the intended cart items;
4. the resulting cart is checked against the selection.

If an extra item must be added through custom behavior, treat that as a separate technical integration—not as another no-code interaction to layer onto the button. The base Kaching transaction should pass before any custom action is introduced.

Add Kaching with Replo’s native component

Use this as the default route because it requires the fewest moving parts.

1. Complete the Kaching preflight

Before opening Replo:

1. Install Kaching Bundles on the Shopify store.
2. Create and publish at least one deal.
3. Confirm that the deal’s visibility includes the product used by the Replo Product Component.
4. Enable the Kaching Bundles app embed in the active Shopify theme.
5. Confirm that the deal works on an appropriate Shopify product-page context before introducing the Replo page.

The fifth step separates an offer-configuration problem from a Replo-placement problem. If the deal cannot render or add correctly outside Replo, moving the same configuration into Replo will not diagnose the root cause.

2. Identify or add the Replo Product Component

Open the Replo page or Product Template. Locate the Product Component containing the relevant product information and Add to Cart button.

If the page does not have one, add a Product Component and connect it to the correct Shopify product or templated product. Replo’s Product Component guide explains that the component owns dynamic product data, variant state, quantity, selling-plan choices, and Add to Cart behavior.

That is why Kaching belongs inside it.

3. Drag in the Kaching Bundles Widget

In Replo:

1. Open the Components panel.
2. Search for Kaching Bundles Widget.
3. Drag the component inside the correct Product Component.
4. Position it within the buy-box sequence.
5. Save the page.

The Kaching app controls the widget’s internal appearance. Replo controls the surrounding placement and container layout.

Do not spend time trying to rebuild Kaching’s tier-card styling with unrelated Replo controls. Make offer-content and widget-style changes in Kaching, then use Replo for the page hierarchy around it.

4. Remove competing controls

Inside the same Product Component, audit:

• Replo quantity selectors;
• Replo variant or option selectors;
• buttons with Add Product to Cart interactions;
• chained actions that add other products;
• duplicate Kaching components;
• duplicate desktop/mobile buy boxes.

The goal is not to remove every Replo element. It is to remove every element that independently claims ownership of the same product-form state.

5. Publish a controlled page and test it

Replo states that the Kaching widget will not appear inside the editor. It should appear on the published page when the integration requirements are satisfied.

Do not repeatedly delete and re-add a correct component because the editor looks empty. Save, publish in a controlled context, and inspect the storefront result.

For a paid campaign, use a temporary unlinked page or another controlled release process that fits your store. Do not send paid traffic until the complete matrix below passes.

Use Custom Liquid only as a fallback

Replo’s native Kaching component should be the first route. Use Custom Liquid when the component is unavailable in the required context or cannot reach a legitimate placement.

Place a Custom Liquid Component inside the correct Replo Product Component and use Kaching’s documented web component:

Custom Liquid snippet: <kaching-bundle product-id=”{{ product.id }}”></kaching-bundle>

Kaching’s custom-placement documentation identifies three requirements:

1. a product ID;
2. a product form containing the snippet;
3. a form submit button.

The snippet does not create a complete product form or a replacement Add to Cart button. It renders the Kaching web component inside an existing purchase context.

Use the dynamic {{ product.id }} value when the Replo Product Component supplies the current product. A hard-coded product ID can be appropriate for a deliberately fixed landing page, but it becomes dangerous inside a reusable template because every page instance can load the same product’s deal.

Custom Liquid is not permission to build a second cart system. If the fallback also requires custom JavaScript, multiple forms, or manual cart requests, move the implementation out of the no-code path and assign technical ownership before launch.

Run the 15-case Published Page-to-Cart QA Matrix

Test every live tier and every materially different variant path. The default tier passing does not prove the higher tiers work.

Classify the result:

• LAUNCH: Every transaction gate passes for every published tier and material device path.
• FIX AND RETEST: The architecture is viable, but a specific configuration or presentation failure remains.
• HOLD: The wrong product, quantity, variant, discount, total, or cart line appears—or two systems still own the same form state.

Do not average the matrix. Fourteen passing cases cannot compensate for the wrong variant entering cart.

Diagnose the integration by symptom

The widget is missing from the Replo editor

This is expected according to Replo’s Kaching guide. The editor is not the live rendering environment for the widget.

Next action: verify the component is inside the Product Component, save it, and inspect the published page.

The widget is also missing from the published page

Check in this order:

1. Kaching is installed.
2. The theme app embed is enabled.
3. A published deal is eligible for the selected product.
4. The Kaching component is inside the correct Product Component.
5. The Custom Liquid snippet is exact, if using the fallback.
6. The Product Component has an Add to Cart path.

This sequence narrows the failure before custom code or support access is considered.

The wrong quantity or variant enters cart

First count the Kaching embeds inside the Product Component. Replo documents that the first of multiple embeds can determine the quantity.

Then remove competing Replo quantity and variant controls. Select each Kaching tier again and record the exact cart result.

Do not diagnose this as a pricing problem until the selected product, variants, and quantities are correct.

Desktop works but mobile does not

Check whether the page contains two buy boxes or two Kaching components that are merely hidden at different breakpoints.

Rebuild the section around one responsive Kaching embed where possible. A layout difference should be handled with style overrides, not a second transaction owner.

Dynamic Checkout disappears

This can be expected behavior.

Kaching’s Dynamic Buy Now explanation says Shopify’s dynamic button supports a single product or variant. Kaching hides it when the bundle includes different variants, a free gift, or an upsell product to prevent an invalid path.

Use the normal Add to Cart route for those selections. Do not force the Dynamic Checkout button back into a state it does not support.

Items enter cart but the cart drawer does not open or refresh

Separate cart content from cart presentation.

If the correct items exist in the cart but the drawer remains closed or stale, the base Kaching selection may be working while the theme/cart-drawer trigger is not. Replo’s slide-out cart guidance notes that drawer behavior depends on the theme or cart app and can require a separate refresh/open action.

Fix the drawer integration without changing a correct product, quantity, variant, or discount result.

Where Kaching fits versus Replo’s native Bundle Builder

Kaching is the better candidate when Replo is one destination in a broader Kaching offer system. Native Replo is the better candidate when the bundle lives only in Replo and its documented controls cover the complete requirement.

Neither choice removes the need to test the published transaction. Replo’s native Bundle Builder guide also notes that discounts do not function in preview and require a published page for the complete test.

If Kaching is the right owner for the quantity or bundle offer, you can claim 20% OFF Kaching for your first 3 months. The App Store route is available through the linked Kaching name in the Verdict Card.

Final launch sequence

1. Decide whether Kaching or native Replo should own the offer.
2. Configure and publish the offer in the chosen system.
3. Connect the Replo Product Component to the correct product.
4. Add one native Kaching component—or use Custom Liquid only as a fallback.
5. Remove competing quantity, variant, and Add to Cart owners.
6. Use responsive styles instead of duplicate desktop/mobile embeds.
7. Publish the controlled page.
8. Run all 15 QA cases across every live tier and material variant path.
9. Fix cart-drawer presentation separately from correct cart contents.
10. Send paid traffic only after the page earns LAUNCH.

A Kaching widget is not integrated merely because it occupies the intended space. It is integrated when one product form owns the decision and the cart reproduces what the shopper selected.

Frequently asked questions

Does Kaching Bundles work with Replo?

Yes. Replo provides a dedicated Kaching Bundles Widget and lists Kaching as a supported bundle-app integration. Place the widget inside the Product Component that owns the relevant product and Add to Cart button.

Why can’t I see the Kaching widget in the Replo editor?

Replo says the Kaching widget does not appear inside the editor. Save the correct structure and inspect the published page. If it is missing there too, check the app embed, eligible deal, product assignment, component nesting, and integration method.

Can I keep Replo’s quantity and variant selectors with Kaching?

Replo’s Kaching-specific guide does not recommend those selectors in the same Product Component. Kaching selections override Replo quantity or variant selectors for the Add to Cart button, so leaving both visible can create contradictory states.

Can I use separate Kaching widgets for desktop and mobile?

Not inside the same Product Component. Replo warns that when multiple Kaching embeds share one Product Component, the first can control the quantity. Prefer one embed with responsive styling.

Why does the Dynamic Checkout button disappear?

Kaching hides Shopify’s dynamic Buy Now button when the selected bundle includes different variants, a free gift, or an upsell product. The button supports only one product or variant, so use the normal Add to Cart path for those bundles.

Should I use Kaching or Replo’s native Bundle Builder?

Use Kaching when you need a Kaching-managed offer across Replo and other Shopify surfaces or require a documented Kaching mechanic. Use native Replo when the offer is Replo-only and its current product, variant, reward, styling, and limitation set covers the requirement. Test either choice on the published page.

How this guide was researched

ShopSideK reviewed current Replo and Kaching documentation on July 27, 2026. The Product-Form Ownership Map and 15-case Published Page-to-Cart QA Matrix are ShopSideK editorial models. They do not represent an independent ShopSideK benchmark across every Replo page, theme, cart drawer, or Kaching configuration.