#cm

1 messages · Page 1 of 1 (latest)

median boltBOT
woven fulcrum
#

Hi. What questions do you have?

quartz prairie
woven fulcrum
#

Sorry Discord is crazy busy. Is there anyway you can summarize exactly what you need to know?

#

If not, I'll get to reading over those threads when I get some time

quartz prairie
#

Sure, no problem. Do you want me to repost my questions in this thread, or in the main channel?

woven fulcrum
#

In here would be great thanks

quartz prairie
#

(1/2)

Myself and @steady lintel are working to upgrade our org from the legacy Checkout experience to Checkout 2.0 and have a few questions:

According to the docs, you can create a Checkout Session with line items that either reference an existing Price object by ID, or you can pass a hash of price_data to create what Stripe refers to as an "inline Price".

  • Are we going to lose any functionality in our integration (thinking specifically about reporting) by solely using inline Prices in our Checkout Sessions? For example, right now we have several Product objects with Prices under each product, i.e. onetime price, annual subscription price, monthly subscription price. They're all "owned" by the Product object. Using inline Prices, would it be possible to ask the data questions like "how many users created a recurring Subscription to X product for a Price with an amount of $Y?"

  • Would using inline prices preclude us from eventually refactoring our integration to use something like Stripe Elements? Based on my cursory glances through the documentation, that doesn't seem to be the case, but I'd like to know if we're missing something here.x

#

(2/2)

It looks like the Checkout Session object can contain information about each line item's discount, under line_items.data.discounts. However, according to the API documentation , it doesn't look like we can actually attach specific discounts to specific line items; it appears as if discounts are Checkout Session-wide. It also doesn't look like we can use more than one discount per Checkout Session (why is the top-level discounts parameter an array of hashes then?).

  • It would be extremely valuable to be able to use more than one discount. We currently have a use case where we offer an additional discount (on top of any pre-existing discounts) if a user pays with a single, upfront payment instead of creating a recurring Subscription. At the moment, we have to calculate and "bake" both of those discounts into a single Coupon that gets expressed as a single line item on an invoice. It would be really nice if we could simply use two Coupons here such that the corresponding discounts get expressed as separate line items on an invoice, i.e. "$X upfront payment discount" followed by "$Y discount". Do you know if this will be possible in the future?
smoky plinth
#

Hey, codename_duchess has to step out soon but I can help. Catching up on your question...

#

Are we going to lose any functionality in our integration (thinking specifically about reporting) by solely using inline Prices in our Checkout Sessions?
As far as I know, no, you will still have IDs to identify the inline price by and you will be able to link subscriptions created this way to that product ID.

#

Would using inline prices preclude us from eventually refactoring our integration to use something like Stripe Elements? Based on my cursory glances through the documentation, that doesn't seem to be the case, but I'd like to know if we're missing something here.x
You will still be able to use Elements. We have this doc on working with Subscriptions + Elements if you have not already seen it https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements

#

I have to jump to another thread, will respond to the rest of your questions soon. Let me know if more come up

quartz prairie
#

You will still be able to use Elements. We have this doc on working with Subscriptions + Elements if you have not already seen it https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements

Got it, thank you! This doc is pretty interesting to me - the "Create the Subscription" section seems to imply a requirement re. knowing the price_id when setting up a Subscription. If we're using inline prices with Checkout 2.0 and want to eventually migrate to Stripe Elements, we wouldn't necessarily know this information, right?

Take req_W3Q2JOLyy62vxG as an example - we created a Checkout Session with an inline price for a specific product. However, after successfully completing the checkout process, that Price object doesn't show up if we call Stripe::Price.list({ product: '<product_id>' }).

Although I do see in the Subscription API docs that we can also use price_data when creating a Subscription to create inline prices there as well.

Disregard!

Build a subscriptions integration

Create and manage subscriptions to accept recurring payments.

#

Whenever you're able to swing back to this thread, I think we're good on 1/2, but still curious about 2/2

smoky plinth
#

Good catch, my apologies, I didn't fully think of what switching to Elements would look like here. You can still use price_data to create inline prices when creating subscriptions as well. If you modify the subscription create call in that doc to use price_data, the rest of the flow should still work. https://stripe.com/docs/api/subscriptions/create#create_subscription-items-price_data

Looking in to 2/2 there, I may have been mistaken about how inline prices work here.

Stripe API reference – Create a subscription – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

quartz prairie
smoky plinth
#

Gotcha, thought you were talking about retrieving inline prices. It looks like it will create a price object on the subscription itself but I don't immediately know if it is listable

#

Going to 2/2 questions now

#

Multiple coupons are on the roadmap and I know they are a commonly asked for feature. Unfortunately I don't know how far out they are at the moment but we do plan to support them. I am checking in to whether this is something that can be enabled for specific accounts yet or something

quartz prairie
#

Multiple coupons are on the roadmap and I know they are a commonly asked for feature. Unfortunately I don't know how far out they are at the moment but we do plan to support them. I am checking in to whether this is something that can be enabled for specific accounts yet or something
Awesome, thank you so much! At the end of the day, we can still use our approach of baking multiple discounts into a single coupon. That said, if there's an opt-in beta or something we'd be happy to guinea pig it 🙂

smoky plinth
#

As far as I can tell, there is not one at the moment unfortunately.

#

I thought working directly with Subscriptions could enable you to do this but at the moment it looks like that restriction is there as well.

quartz prairie
#

Alright, sounds good. Thanks for looking into it!