ironbeard_api | Stripe Developers | Page 1

molten joltBOT Dec 13, 2024, 4:01 PM

#

👋 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/1317159514746650667

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

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.

ironbeard_api, 3 days ago, 52 messages
ironbeard_api, 3 days ago, 35 messages

pallid flower Dec 13, 2024, 4:02 PM

#

So if someone checks out with both a newsletter and a forecast, I'll be sending two client_secrets to the Card Element and looping through them.

#

So my questions are:

When does a PaymentIntent have a client_secret?
What determines if Subscription.latest_invoice.payment_intent is null or not? aka what are the allowable status values for an Invoice if it does/doesn't have a PaymentIntent?
What happens if I send a client_secret associated with a paid Invoice to a Card Element? e.g. If latest_invoice is paid in full, do I need to be careful to not send it's PI's client_secret to the front end? Only send the secret if invoice is..status=open?

unique cosmosBOT Dec 13, 2024, 4:18 PM

#

odd crescent Dec 13, 2024, 4:20 PM

#

Hi there 👋

When does a PaymentIntent have a client_secret?
All Payment Intents have a client secret

What determines if Subscription.latest_invoice.payment_intent is null or not? aka what are the allowable status values for an Invoice if it does/doesn't have a PaymentIntent?
If the Invoice is $0, payment_intent is null since there is no payment to be processed, otherwise it's populated.

What happens if I send a client_secret associated with a paid Invoice to a Card Element? e.g. If latest_invoice is paid in full, do I need to be careful to not send it's PI's client_secret to the front end? Only send the secret if invoice is..status=open?
I suspect you'd see an error when you attempt to confirm the payment, but I don't think I've personally tested that so I'm not 100% confident. I think you'd be able to test it fairly quickly and confirm that though.

pallid flower Dec 13, 2024, 4:29 PM

#

My checkout process has a few steps (create user/account or log in to existing account, add/update contact info, finally show CardElement and accept payment).

I already have checks against someone putting an item in their cart that they're already subscribed to, but I just want to be thorough.

On step 3, when I show the CardElement, the Subscription(s) have been created in the backend and client secrets sent to the Card Element front end (which then collects payment info and submits using stripe.js).

If the user is already a customer / already subscribed to a product, I fetch their existing subscription instead of creating a new one. I then add / remove SubscriptionItems from their existing subscription to do the upgrade/downgrade and then fetch latest invoice > payment_intent > client secret to send to front end. this seems to work properly.

However, the edge case I'm unsure about is if someone has gotten to this step before but, for whatever reason, didn't finalize the transaction. So they'll already have a Customer object and a Subscription object (with status != active). I suppose in this case it's possible that they have different items in their cart than when the subscription was originally created, so it's possible I'm doing the add / remove thing. In this case, is grabbing the latest_invoice > pi > client_secret still the correct flow?

I guess worded another way: regardless of whether I'm creating or updating a Subscription, what values of latest_invoice.status should I use to say "okay, send relevant client secret to front end"?

odd crescent Dec 13, 2024, 4:34 PM

#

It kind of depends on what you want to happen there. In the edge case you described, it sounds like your customer will have one unpaid Invoice, and then you're updating the Subscription which will generate a new Invoice. Resulting in them having multiple open Invoices for the Subscription.

Does that align with what you're seeing in your testing? Do you want the Customer to have to pay both (or all) of those Invoices?

pallid flower Dec 13, 2024, 4:35 PM

#

Oh hmm, good point

#

I don't think I want them to pay for both, only the latest

#

I guess, if the cart hasn't changed, they should pay the original invoice. But if they do change their cart, they should pay the new one

odd crescent Dec 13, 2024, 4:37 PM

#

Gotcha, then yeah, using latest_invoice sounds like what you likely want.

pallid flower Dec 13, 2024, 4:38 PM

#

assuming latest_invoice.status != 'paid' or would latest_invoice.status == 'open' be better?

odd crescent Dec 13, 2024, 4:39 PM

#

open would probably be better, just in case you somehow have voided or paid Invoices returned. Though it's pretty unlikely you'd see any status other than open if you aren't creating $0 Invoices, if I'm recalling all those possible states correctly 😅

pallid flower Dec 13, 2024, 4:40 PM

#

Yeah, draft, open, paid, uncollectible, void. 🙂

#

This has been very helpful, thank you so much. l think I have one last question, trying to figure out the best way to word it.

odd crescent Dec 13, 2024, 4:42 PM

#

Always happy to help!

pallid flower Dec 13, 2024, 4:43 PM

#

If someone has an existing subscription (so latest_invoice.status = 'paid', among other things), and they have items in their cart that upgrade/downgrade the subscription, then when I made a request to Stripe to edit that Subscription with different Items (having set billing_cycle_anchor=now, proration_behavior=always_invoice), that will generate a new open invoice, so now latest_invoice.status will be open?

#

(and when I send the Subscription update request, I have expand='latest_invoice.payment_intent')

molten joltBOT Dec 13, 2024, 4:45 PM

#

odd crescent Dec 13, 2024, 4:49 PM

#

Yup, that all sounds right

pallid flower Dec 13, 2024, 4:57 PM

#

Great!

One other thing, a bit unrelated: I see there's a new Invoice.create_preview method, should I be using this instead of Invoice.upcoming to display prorated prices to the upgrading/downgrading Customers during checkout?

Previously I would send e.g.

stripe.Invoice.upcoming(
  customer=<customer_id>,
  coupon=<coupon_id>,
  subscription=<sub_id>,
  subscription_proration_behavior='always_invoice',
  subscription_billing_cycle_anchor='now',
  subscription_items=[
    {'price': <price_id>, 'quantity': 1}
    for price in add_prices
  ] + [
    {'price': <price_id>, 'quantity': 1, 'deleted': True}
    for price in remove_prices
  ],
)

But I noticed that create_preview doesn't take subscription_proration_behavior, subscription_billing_cycle_anchor, subscription_items, etc. It looks like it takes subscriptio_details, so should I be passing those last three key/values into

subscription=details = {
  'proration_behavior': 'always_invoice',
  'billing_cycle_anchor': 'now',
  'items': [ ... ],
}

?

odd crescent Dec 13, 2024, 5:00 PM

#

The difference between them is that retrieving an upcoming Invoice only returns what the Invoice will look like, whereas creating a preview Invoice actually generates an object that can be interacted with.

And yes, you should be using subscription_details to pass in those values if you're creating a preview invoice.

pallid flower Dec 13, 2024, 5:03 PM

#

In my use case, displaying what the invoice would be if they decide to upgrade/downgrade, instead of "here's your next invoice" makes it feel like I should use preview instead of upcoming?

odd crescent Dec 13, 2024, 5:06 PM

#

They're effectively very similar. The key deciding factor is whether you need to be able to reference the preview invoice again, like to retrieve it's line items or something similar. If not previewing the upcoming Invoice is likely sufficient, but if it's not then you can create the preview Invoice instead. (I wish the names we made for those were a little more distinct 😅 )

pallid flower Dec 13, 2024, 5:11 PM

#

Hmm. But using upcoming wouldn't actually create that invoice, right? I can ask for an upcoming invoice and then if the user doesn't decide to do the upgrade, then it's not like their next invoice (e.g., in a year when the billing cycles) will have the upgrade items?

#

Although, it does look like using upcoming for this purpose might become depreciated?

limpid thistle Dec 13, 2024, 5:15 PM

#

FYI I'm taking over for toby, catching up on the thread now

pallid flower Dec 13, 2024, 5:16 PM

#

all good. Really just need a final clarification on upcoming/preview invoice, I'm solid on all the payment intent stuff now 🙂

limpid thistle Dec 13, 2024, 5:26 PM

#

Yes, neither of them will actually create an invoice or change what the customer will receive, they're just used to see what the invoice will look like. Using preview will create a record of that preview that you can re-access for 72 hours. Upcoming will just give you an instantaneous view of what the upcoming invoice will look like in the response body.

pallid flower Dec 13, 2024, 5:28 PM

#

For upcoming, does subscription_* being Depreciated mean I should use preview instead?

limpid thistle Dec 13, 2024, 5:35 PM

#

Yep! That is correct

pallid flower Dec 13, 2024, 5:43 PM

#

Sounds good. Thanks!

#ironbeard_api