#some1ataplace_api

1 messages · Page 1 of 1 (latest)

daring sphinxBOT
#

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

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

ruby sapphireBOT
surreal osprey
#

Hi 👋 what is best for your flow is going to be dependent on your specific use case and needs.

deft sinew
#

Hi. Yes that is true. Shall I explain to you the different use cases? Because I am so confused now that I discovered that you can do the same thing it looks like in different ways.

#

Give me some time, I will type it all out for you. It may take me a while to type it all, because I have a lot going on.

surreal osprey
#

If you have a clear question I can try to help with that, but if you just want to explore the different approaches and how they play out I'd recommend running some tests and see which approach works best for your needs.

deft sinew
#

I did run the tests but I am still confuseed

surreal osprey
#

What's confusing?

deft sinew
#

Give me a moment, typing it all out and computer freezing.

#

Use case 1: Membership subscription payments.
This is a recurring monthly or yearly payment for courses
I am using a product id to categorize it
The prices barely change unless in situations like inflation occurs.

Use case 2: Donation one time and subscription payments.
This can either be a recurring or one time payment that goes directly to my platform.
Prices get passed into a form by the user and can be any amounts.
I am using a product id to categorize it.
But I have price IDs being created beforehand.

Use case 3: Author Tip one time and subscription payments.
Customer IDs can pay either one time or subscription payments that go to an author connect id.
The author connect id gets a portion of the payments, while the platform gets a portion.
Prices get passed into a form by the user and can be any amounts.

Use case 4: Cart payments
A user could buy one or more items forever in their shopping cart.
This is a one time payment only.
I have a product ID for this.
Amounts are all randomized depending on how much the sum of the cart items are.

#

Basically I would love to know your recommendation for each of those use cases how to setup my checkout sessions, since there are multiple ways to define them all, I get confused which is the preferred way.

surreal osprey
#

I don't have specific recommendations based on that. That doesn't give me much insight into your requirements or what you're hoping to be able to do downstream. Do you have questions based on the testing you've done? Do you have examples of behavior you saw that you wanted to adjust to better suit your needs?

deft sinew
#

Yea I outlined a bunch of situations in the dpaste.

Why should I create a Price ID beforehand and pass that into the checkout session?

Why would I not create a Price ID beforehand and not pass that into the checkout session?

Why would I use product_data over product id or vice versa?

In which situation would I have duplicate price ids and why is that bad?

Why in the dpaste when I do not create a price ID beforehand nothing gets sent back to the Product Catalog dashboard page?

surreal osprey
#

It's largely whether you need to create something in an adhoc fashion or not. Using price_data and product_data still create Price and Product objects, it just creates them when creating the Checkout Session.

#

If you repeatedly use price_data and product_data, you'll end up with a large number of Price and Product objects, which may or may not cause reporting problems depending on your needs.

#

You will never have duplicate Price IDs, each Price object will have a unique ID.

#

Why in the dpaste when I do not create a price ID beforehand nothing gets sent back to the Product Catalog dashboard page?
I'm not too sure what is being asked here. What is "dpaste"?

My best guess at answering what's being asked, is that using price_data causes the Price to be archived so you can't/won't reuse it, and I'm pretty sure the dashboard doesn't show archived Price objects by default, but my teammates and I here are more familiar with our APIs than the dashboard flows.

deft sinew
surreal osprey
#

Hard to say, there's several session creation requests in there. I'm pretty sure my answer above fits.

deft sinew
#

Yes, I wanted to show you the different ways of creating checkout sessions, but now I am confused at which of those use cases I would use for some of those different ways of creating checkout sessions

surreal osprey
deft sinew
surreal osprey
#

Not sure what you mean, I see that active is false for the Price that Subscription uses.

#

So far the only requirement you've shared is that you want to create a Checkout Session to either accept a payment or create a Subscription, and all of the approaches you've shared will work fine for that. It's hard to be more precise with guidance without understanding what your requirements or concerns are.

deft sinew
surreal osprey
#

I mean the active field on the Price object is set to false:
https://docs.stripe.com/api/prices/object#price_object-active
(which I do believe correlates to the Price being archived)
When we talk about things in this forum, we're almost always talking about within our API and almost never talking about the dashboard, since within this forum we specialize in helping developers with their questions about the behavior of our API.

deft sinew
#

Okay makes sense. I just want to use the dashboard as a confirmation too.

#

So I kind of like that archiving or false thing now that I think about it? So you think that is good or bad for reporting? Because previously I was doing this for donations:

https://dashboard.stripe.com/test/products/d/prod_HuhjcdKhnVmN8A?active=true

As you can see, I have a ton of random price IDs in there that the user puts in a form a custom amount. But I am creating the price IDs before the checkout session and placing them in the line_items price field.

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

surreal osprey
#

I don't know without knowing what your reporting requirements are.

We have Price objects that are designed for letting customers choose what to pay though:
https://docs.stripe.com/payments/checkout/pay-what-you-want?dashboard-or-api=api
rather than needing to use your own form.

Those don't work with Subscriptions though, you can't create them as recurring Prices, and would need to use a different appraoch if you are offering the ability to choose what to pay for Subscriptions.

Let customers decide what to pay

Accept tips and donations, or sell pay-what-you-want products and services.

deft sinew
#

That pay what you want thing is nice, but what I made in the form tries to fix those limitations mentioned.

#

I will try to make another dpaste for you, give me a few minutes.

deft sinew
#

Sorry for the hold up, got distratced with something at work lol.

#

Here is an example dpaste using the different donation scenarios. Author tips is very similar to this as well.

https://dpaste.org/sWyMG

So seeing all of these different ways of coding a checkout session, which of these would you recommend I use?

surreal osprey
#

Whichever one best suits your needs. Sorry, but you still haven't shared any details about your requirements or why any of these approaches don't work for you, so I still don't have any context to base suggestions off of. I'm already familiar with how to create Checkout Sessions, you don't need to show me how to do that. Unless you can articulate why some of these approaches don't satisfy your needs, I'd suggest continuing to test them out and work on fitting them into the rest of your flow to see if any problems arise.

deft sinew
#

They work for me, but the creating price IDs beforehand seems sloppy, would you agree or disagree?

surreal osprey
#

I think it depends on whether you would ever reuse those Prices.

deft sinew
#

I would probably never reuse them again, especially since they are so random when the user fills out a form with a custom amount. But is that good or bad for reporting? I just want to report and see stuff like for this donation product id this month, here is all the payments made.

surreal osprey
#

I don't know, run through some and see if you can generate the reports you're looking to.

deft sinew
#

I will, but if you were to do reporting on donations or tips for a business you had, what would you do as a stripe developer? Who cares about my situations.

surreal osprey
#

I don't know. Reporting isn't my forte and I don't know what would be important for a business to report on.

deft sinew
#

Okay, so I am a bit confused by these stackoverflow answers: https://stackoverflow.com/questions/70133656/stripe-create-checkout-session-only-with-total-price

When using a price ID with Checkout Sessions you get access to more features.

As described in API reference, the field line_items.price_data.product_data still creates new price and product objects along with the checkout session , the cons might be your Stripe account will end up creating many of duplicate product / price objects . Note that currently price object can be deleted ONLY in Dashboard , so it is frustrating to clean up all the duplicates

Stack Overflow
Stripe create Checkout session only with total price

I'm currently working in a (small) project where we want to create a shop but we aren't selling anything yet.
We are storing our products that we want to sell in our own database.
However I wanted to

#

Is those valid statements? Duplicates sounds bad. I do not want to have to have those I don't think.

surreal osprey
#

Prices can't be deleted once they've been used.

deft sinew
#

Can't 2 price IDs get created and then archived? Even if the same amounts?

surreal osprey
#

Multiple Price objects can get created, they won't have the same IDs though. But that leads to the duplicates that seemed to worry you.

deft sinew
#

Duplicates in the sense of same amounts? As long as they have different price IDs then that seems fine

surreal osprey
#

I don't know what the SO post is talking about, so I assumed they're talking about duplicate amounts. You can test this to be sure it meets your needs.