#Paris-subscription

1 messages ยท Page 1 of 1 (latest)

proper phoenix
#

Hello!

#

Subscription items are ordered by creation timestamp, not be updated timestamp, so you should lget them back in the same order as they were created (reverse-chronological)

cloud bramble
#

what happens if i create all the items in the same call (initial subscription create)

#

ah ok i see what you mean, they come back by the time i added that price item /subscription on dashboard

#

is that correct?

#

hmm the timestamp on created is the same on both items ๐Ÿ˜„

proper phoenix
#

Backing up for a second - is there a specific reason/integration requirement that needs you to be absolutely sure of this ordering?

cloud bramble
#

i thought for a second i could actually use this information to deliver better pricing report for the customer. and wanted to see if i can do it without checking on the front the price id on each one

#

since it seems like every time i get the same order as i set it up initially

#

just wanted to be sure if that is indeed how it works

proper phoenix
#

Gotcha - let me just double check really quick

cloud bramble
#

e.g. user press on the subscribe button. i calculate on the server the quantities and create the subscription on the back. then on the front it requests the subscription, i check latest_invoice to get payment intent and client secret in order to proceed with the payment.
at the moment i also send the quantities from the server to the front, to say eg item 1* 5 times item 2* 3 times etc. but i thought i can use the quantities from the subscription item

proper phoenix
#

So I was wrong about the reverse chronological - I believe we order the subscription items in chronological order (so the one that was created first will be first in the list).

#

So you're basically trying to skip a step where you confirm which quantity matches with which subscription item, correct?

cloud bramble
#

yep ๐Ÿ˜„

#

since i create them like this
customer: customer.id,
items: [
{ price: process.env.STRIPE_PRICE_ID, quantity: quantity },
{ price: process.env.STRIPE_UNHAPPY_PRICE_ID, quantity: unhappy_quantity }],
payment_behavior: 'default_incomplete',
expand: ['latest_invoice.payment_intent'],

#

i know the order i passed them on that array

proper phoenix
#

Yeah, I see what you mean - personally, I'd still want that extra reassurance that the quantity matches with the subscription item just to be safe