#ironbeard_api

1 messages ¡ Page 1 of 1 (latest)

grizzled orchidBOT
#

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

📝 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.

snow perch
#

Is create_preview a relatively new method in the Stripe API? I didn't know about it and I've been using Invoice.upcoming to generate previews

sand warren
#

The upcoming Invoice endpoint is older, and the Preview Invoice endpoint is its newer replacement. We recommend you use the Preview Invoice approach unless there's a specific feature only the upcoming Invoice approach supports.

snow perch
#

Gotcha. Should I use Preview to generate the different invoice amounts for my shopping cart?

sand warren
#

That depends on the specifics of your integration. Without knowing more I'd have to say the answer is "maybe".

snow perch
#

And I suppose I can detect invoices created this way by examining if the id starts with upcoming_?

#

All my products are subscriptions. It is possible to upgrade a subscription (which is the only time that I can't just calculate the amount due from information I have locally)

sand warren
#

Ah, yeah, when showing what upgrading a Subscription is going to look like using a Preview Invoice is what you want.

#

And one way you can tell is by the upcoming_ prefix, yep.

grizzled orchidBOT
snow perch
#

Looks like my version of python Stripe lib doesn't have stripe.Invoice.create_preview, any idea when that was added?

#

Ouch, looks like the latest version is 11.3.0 and I'm on 7.12.0.

sand warren
#

For full support you'd need 11.3.0 though, looks like some Invoice preview stuff was added in that version as well.

snow perch
#

Am I right in my understanding that the version of Stripe API and the version of Stripe Python lib one uses are unrelated?

#

that is, do I have to upgrade the Stripe API versioin I'm on in order to upgrade this python lib?

old axle
#

Hi taking over here as Rubeus has to step away

#

So as of v6 of the stripe-python library, we started pinning the api version to the latest at time of sdk release

#

So requests made by the python sdk will use whatever the latest api version was at the time that sdk version was released

#

Regardless of what your account's default api version is set to

snow perch
#

So..if all my API requests are made via the Python SDK... I don't need to worry about the "API versions: <upgrade available>" tag in the Developer Dashboard?

old axle
#

If they all are, yes

#

But client-side requests, for example, would continue to use your account's default

#

If you have any of those

snow perch
#

Oh right

#

Like from Card/Payment elements

old axle
#

But the above ui in the dashboard you screenshotted is a great tool to see where your requests from each version are coming from

snow perch
#

The 2020 requests being from e.g. card elements on the client side. And 2023 being from the Python SDK

#

Cool. So I shouldn't anticipate any hiccups from just updating the Python SDK (maybe I check out major version change logs?)

old axle
#

So yeah you'd need to check changelogs and thoroughly test in test mode before deploying anything to prod

snow perch
#

Is it considered poor design to rely on e.g. Invoice.create_preview to display checkout information such as subtotal, taxes, total, prorations, etc? Vast majority of the time I would really only need to use create_preview when an upgrade is happening (which is rare), but it would be nice to simplify the code too and just rely on create_preview.

Oh, I guess: Does create_preview work without a Customer ID? for e.g. a brand new subscription.

old axle
#

I wouldn't say that's bad design really. Why wouldn't invoice be created though when customer is on checkout page?

#

Does create_preview work without a Customer ID? for e.g. a brand new subscription.
It does

#

But if using automatic tax: then one of customer, customer_details, subscription, or schedule must be set.

snow perch
#

Well, not necessarily checkout page. Checkout "starts" by going to the ShoppingCart page, which displays a summary invoice. Then the user can click "Checkout" which takes them through a few steps: 1: Create User, 2: Contact Info (POST of this form creates the Stripe Customer), and 3: Payment Info (the GET request for Step 3 creates the Subscription and passes client_secret to the Card element).

#

So, I guess I'm wondering if having an external HTTP request (to Stripe) when someone is viewing the cart and each time they add or remove an item is good design or not

old axle
#

This could contribute to rate limiting

snow perch
#

So I guess, when the GET for Step 3 happens, I have a "real" invoice, but before then I'm just kind of winging it

old axle
#

Which wouldn't be great

snow perch
#

Yeah, agreed

old axle
#

I would limit the amount of times you make a request to us where possible

snow perch
#

Yeah, maybe I just display a "naive" invoice (with a note) until the Subscription is created, at which point I'll have the real invoice and any prorations etc

#

but I can calculate 99% of invoices just using the information I have on my server with Prices and PromotionCodes/Coupons

old axle
#

Yeah that could work

snow perch
#

Hmm. Okay, thanks again for your help!