#some1ataplace_api

1 messages ¡ Page 1 of 1 (latest)

latent kelpBOT
#

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

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

runic terrace
#

Hi, let me help you with this.

#

Why do you need to update all instances?
You usually create a Checkout Session and use it for one payment, or collection of a payment method, and then it expires.

latent kelpBOT
rocky hearth
#

I was hoping to keep the data consistent with the author name in my database and what stripe has

#

If not, if you could help me think of a way to refactor this so I would not have to do that, I would appreciate that as well.

#

I also played with the idea of creating a dedicated product ID for author tips. However, each author connect id is different, which is why I use their author id and name in metadata. I figured adding product data showing the user in stripe billing who they tipped was nice as well.

runic terrace
#

When you create a new Checkout Session it will pull the new name.

runic terrace
rocky hearth
#

That is true. If the user updates their name in the database, then the names will be different in the metadata on stripe versus what my database has though. I do have the author id on stripe metadata though which is how I can find the right author. I am just worried let's say an author changes their name on my site, and someone tipped to them with their old name. Now when the customer tries to lookup who they tipped, they will no longer see the original name they tipped. The customer who tipped might get confused and say "Who is author B?" "I thought I tipped author A"

runic terrace
#

Business logic shouldn't rely on names, but rather on object IDs. In addition, I wouldn't want to change anything about old transactions, but it must have a permanent ID that links to some page with the current information about the resource (author in your case). However, this goes beyond Stripe integration, and into your own business logic territory, so I will leave it to you to solve.

rocky hearth
#

okay, unless I just remove the name completely from product data and just keep it as "Author Tip". But if a customer tips multiple authors when they check their stripe generated billing page, they will see Author Tip and they won't have any idea who they tipped either.

#

But hopefully you were able to understand. What I am allowing customers to do is tip author connect ids either on a one time payment or subscription basis. I am using the code in the dpaste now. I am not using product IDs to classify author tips (but maybe I should?). I figured from a checkout and stripe billing standpoint, it would be nice if customers could see the name of who they tipped and when the author updates their name on my site, the stripe data would be changed to reflect the name change so it is all consistent.

random hill
#

Is there a specific piece of this you're still looking for guidance on in terms of the Stripe API?

rocky hearth
#

Curious how you would handle it mainly. Use a product id or keep what I have? Remove the author name from the product data? Or if I should really update all previous stripe api data when a customer changes their name.

#

Also, a portion of the author tip would go to my platform. Forgot to mention that.

random hill
#

I would think author-specific name in product data would be too specific but it really depends on your implementation details. If you use stripe generated invoices you might not have much choice, but for your own payment intents then i would think this is easier to manage in your own system and displaying according to your own requirements.

rocky hearth
#

So in other words, you would keep the same structure as what I have in the checkout session code but remove the author name from the product data and keep the product data as "author tip"? Is that what you are saying?

random hill
#

If you want to re-use that across session, yes, but if you really want to sow the exact name in checkout you'll need to include it there and manage a product for each (or use product_data each time).

rocky hearth
#

oh so each author would get its own product id? I wouldn't use just 1 product id for all authors?

random hill
#

If you wanted the author name in the product name, then yes

rocky hearth
#

But if I did not want the author name in the product name, I could use 1 product id for all the authors?

random hill
#

yes

rocky hearth
#

interesting, so would you recommend I do something like:

                    line_items=[{
                        'price_data': {
                            'currency': 'usd',
                            'unit_amount': converted_amount,
                            'product': settings.STRIPE_AUTHOR_PRODUCT_ID,
                        },
                        'quantity': 1,
                    }],

Instead of this:

line_items=[{
'price_data': {
'currency': 'usd',
'unit_amount': converted_amount,
'recurring': {
'interval': interval,
},
'product_data': {
'name': 'Author Tip ',
},
},
'quantity': 1,
},],

random hill
#

Honestly they are very similar

#

in both cases you'll create an ephemeral price ad hoc (auto-archived as single use), in the latter case you'd also be creating an ad hoc product for each usage

#

Assuming Product STRIPE_AUTHOR_PRODUCT_ID has name=Author Tip the customer-facing result should be identical

#

the only different would be on the back-end if you were to list Products via the API and include archived products, there would be lots of duplicate products

#

but the latter case also gives you the flexibility of dynamically injecting the author name if customer feedback suggests you should do that

#

(i assume using price_data is required because this is a customer-defined dynamic amount)

rocky hearth
#

hmm very interesting

#

yes, the amounts are customer defined