#Maurdekye

1 messages ยท Page 1 of 1 (latest)

old narwhalBOT
slow pier
#

regardless, i think the display is a little misleading... if there was a way to display the full price instead of just the unit price here, that would be preferable

pine nest
slow pier
#

hm... let me look for that

#

in the meantime, here's an example checkout session id, in case that might be useful: cs_test_a1n6q3BihwdDE5rky1NYGZWnlhDfpxbpgklA2evQMyI125qYuvrah7mANo

pine nest
#

Okay that will work too

#

Okay I see what you mean. The total listed in the returned Checkout Session object is still 500

#

I think it has to do with the price object. Let me dig a little further

slow pier
#

alright, thank you

pine nest
#

Okay I think I see the issue. This is a usage based price, correct?

slow pier
#

hm, no, this is a package pricing model

#

...is that different?

pine nest
#

Where do you see that defined? AFAIK that isn't a pricing model name we use.

slow pier
#

here's a screenshot i took the other day:

#

while defining the pricing details

pine nest
#

Oh oh oh

#

Prince $500 per 400 units. The quantity is less than 400 so the price is still $5

slow pier
#

huh...?

#

i thought that was units tendered per package

#

so a quantity of 2 would be 800, 3 would be 1200, etc.

#

is there a pricing model i can use to reflect something like that?

pine nest
#

That would be something you would need to set in the description of the Price. How you have defined it currently a quantity of 1-400 would cost $5, 401-800 would cost $10

#

The per unit model you are entering when creating the price is defining how Stripe should calculate the total for this Price based on the quantity. Not how many of your units a quantity: 1 should represent

slow pier
#

ah, hm, i see...

#

ok then

#

that clears things up

#

i think that answers my questions :)

#

thank you ๐Ÿ˜

pine nest
#

Great! I'm glad we could offer some clarity. You can also include the description that each quantity represents 400 tokens in the Product description and Product features. This will get rendered in the Checkout UI.

#

I would recommend doing some testing by saving this information in different places like the Product and Price records and then creating Checkout Sessions to test how this information is presented.

That way you can decide on which approach works best for you

slow pier
#

mhm, alright then