#thomas_code

1 messages · Page 1 of 1 (latest)

alpine shoreBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1505990657464991806

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

modern hull
#

Hi there,
so you are selling one time items either separately or in a (discounted) bundle as a one-off payment/invoice?

inner flint
#

Hi, thanks for the quick reply!

Yes, exactly. Today I sell two products separately, each as a one-off
payment. I want to also sell them together as a discounted "pack".

A few questions:

  1. Do you have feedback from other companies doing this? How do they
    typically model a bundle. As a dedicated Stripe Product with its
    own Price, or as a promo code / coupon applied at checkout? Is there
    a recommended pattern?

  2. My concern with the dedicated bundle Product approach: I run price
    A/B tests on the individual ("child") products, so their unit_amount
    varies per variant. If the bundle is its own fixed Product/Price, its
    price doesn't correlate with whatever variant a user is seeing for
    the individual products, the displayed discount becomes
    inconsistent. Is there a clean way to handle this?

  3. My concern with the coupon approach: as far as I understand, a
    Checkout Session only accepts one coupon. So if I also run a flash
    sale on top of the bundle discount, the two discounts can't stack —
    I'd have to compute a combined coupon on the fly before creating the
    session. Is that correct, or is there a way to apply multiple
    discounts to a single Checkout Session?

Thanks!

modern hull
#

Thanks for the clarification. So indeed we do not have a native bundle support and product A/B testing is always a bit tricky. We don't have a good idea of how other companies solve this, since we don't natively support this and they basically have to come up with their own flow. Especially A/B tests can be very individual or tailored to requirements that we can't cover all.

#

And to answer your question about what is the right approact is really depending on what you want and need.
You bascially have multiple options:
Option A — Dedicated bundle Product with a single fixed Price

One Product, one Price, one line item at checkout. Clean dashboard, simple fulfillment.

Downside: Bundle price is decoupled from individual product variant prices. If you advertise "save 30%", that claim becomes mathematically incorrect depending on which A/B variant the user is in.

Option B — Two line items + percent_off coupon

Both products as line items, coupon applied at session level.

Downside: Checkout accepts only one coupon — flash sales can't stack. Coupon abuse requires server-side enforcement. Receipt shows two prices plus a discount line, which can undermine perceived value.

Option C — price_data inline

Bundle price computed server-side from active variant prices, passed inline at session creation.

Downside: Creates a new Price object on every checkout. Over time your bundle Product accumulates hundreds of throwaway prices in the Stripe dashboard.

Option D — Saved prices per cohort combination

One saved Price per variant combination (2 variants × 2 products = 4 prices). Server selects the correct price at session creation based on the user's active cohorts.

Downside: Price count grows as N×M across variant combinations. Requires discipline when adding new variants.

#

I personally would probably go with Option D. It's the only approach that satisfies all three constraints simultaneously: dashboard stays clean (saved Price objects, not throwaway ones), bundle discount is always consistent with the variant prices the user actually saw, and you're not fighting Stripe's one-coupon limit. The N×M growth concern is real in theory but trivial in practice for a standard 2-variant A/B test — 4 prices is not a maintenance burden.