#ben-checkout-pricingmodels

1 messages · Page 1 of 1 (latest)

elfin sedgeBOT
#

Hello bensif88, we'll be with you shortly! Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
• https://discord.com/channels/841573134531821608/1163928534968963112, 1 days ago, 29 messages
• https://discord.com/channels/841573134531821608/1163885377510187108, 1 days ago, 47 messages
• https://discord.com/channels/841573134531821608/1162482535087997058, 5 days ago, 4 messages
• https://discord.com/channels/841573134531821608/1162405501578006528, 5 days ago, 14 messages
• https://discord.com/channels/841573134531821608/1162352877273100298, 5 days ago, 20 messages

hearty storm
#

You can do this when you receive that completed event

short crown
#

ah, so i need t ograb the hook and get the session id, then call the stripe API to et the full checkout object?

hearty storm
#

Yes, and explicit request the line_items for expansion, they aren't included by default

#

expand[]=line_items

short crown
#

right ok, I will give this a go. I need to rewrite that hook.

I have a seperate question too

hearty storm
#

got for it

short crown
#

I am trying to configure a session for a product that has 2 prices. the first price is a set fee for the first say 3 months, then the second price is a recurring price for period after.

So £300 one_time now
£125pm there after

I spoke to someone yestrerday and they advised a way of creating this scenario. I have one product, 2 prices as described above (one_time price and recurring price).

I attach the two 2 prices to the session at creation in the line times and apply a trial period to the second price (recurring) to meet my requirements of pay some money now, get a period at that fixed fee then pay recurring thereafter.

Tjhe problem I am facing is the checkout line items look odd as they both have the same descriptor

#

for context ^^

hearty storm
#

This is most because they use the same product which is where that name comes from

#

You likely want to set up a product specifically for the one-time setup/fee, with an appropriate name & description

#

similarly for the recurring price

#

Those details come from the underlying product

short crown
#

Hmmm this is difficult as our customer on our platform needs to be able to create this products as a single entity. E.g. they create one product (in their eyes) that encompasses these 2

#

Is there no way to replace this text whe. the session is created?

hearty storm
#

There is not, I'd suggest that you manage creating the separate products behind the scenes

#

ie, just reveal one but have the "initial setup" one for you to use for this, if thats your user flow

short crown
#

How would we link these tho?

hearty storm
#

Either trakcing in your own system, or potentially with a metadata reference

short crown
#

As my flow for these 'combination' products as we have called them, is for our users to assign this to a client (the users customer) and generate a checkout session for the customer.

The session should then contain both products/prices

#

hmmm OK

#

so I could do product->type = combination

Then if (type == combination) retreive price where price_id = product->default_price->metadata->initial_price_id

#

or something

#

christ... i ve refactored this so many times now lol

hearty storm
#

You could potentially create a single reusable "setup fee" product you share among customers, or define these inline

hearty storm
short crown
#

So that would result in a permanent new product rather than a one time use at checkout product?

hearty storm
#

Correct, but if i recall it gets auto archived

short crown
#

hmm i think i am better going with your other suggestsion of creating 2 products and linking them via meta

hearty storm
#

Yep makes sense, if those prices end up being used multiple times its much tidier

short crown
#

Thanks for your help

hearty storm
#

NP!

short crown
#

Hey, so this is quite problematic for a variety of reasons. Is this really the only way to achieve this? We woul dhave to compeltely redefine all of our current processes it seems due to how we display products to our customers for product management

hearty storm
#

Otherwise you can use that inline price_date/product_date option, if that works better

#

and just set things up for the recurring price with the user, the up front one time fee you generate on the fly

short crown
#

Both are. rather troubleshome for a viarety of reasons when you consdier the full picture

#

I know of other poeple doing very similar things, even one of our competitors, but I can't believe it had to be this difficult to acheive?

hearty storm
#

I've filed some feedback to this effect, suggesting we evaluate letting you set a description of some kind of each line item.

short crown
#

I think our problem is mucb wider than that

hearty storm
#

Can you elaborate?

short crown
#

it is this inability to create checkout sessions for subscriptions with an initial fee before the suvb kicks in. This is not an uncommon practise

#

It differs from a discounted initial period, in that the intial period enomcpasses a set up fee of sorts

#

We have faced a similar issue with attempting to provide pre-paid subscription periods, e.g. you can buy 3 months for X and then it ends

elfin sedgeBOT