#dicit53809 - most recent customer
1 messages ยท Page 1 of 1 (latest)
customer_email = 'a@a.com'
customers = stripe.Customer.list(email=customer_email).auto_paging_iter()
for x in customers:
print(x.id)
Let's say that returns a ton of customer ids
Our List APIs always return reverse chronological order
which one is the most recent?
So the first response is the most recent
ok you are right about that. So element [0] ?
If that's the first one, that'll be it. You can also specify limit=1 when you make the request to reduce the payload size.
https://site-admin.stripe.com/docs/api/customers/list
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
ok i am trying to think
i was thinking instead of storing the customer id in my database lookup everything for the customer
from the api
but then i realized if someone deletes their account from my site, they still have their old stripe customer ids and if they signup again they have a new customer id
I have multiple payment options not just stripe on my site so not everyone wants a customer id from stripe
so i am not sure what to do. i want to not have everyone's email go to stripe who signs up if they dont pay with stripe
Okay I understand that, but this sounds like a more general problem you will need to figure out about your integration. What Stripe API specific questions do you have?
if i do the limit by 1, then how will i know for a fact that the most recent customer id is the right one
so i am not sure what to do if i do the limit by 1 or keep the customer id in the database
someone who uses the stripe dashboard might make a customer id that way versus someone on my site signing up for the service and then maybe lose access to their paid product maybe
How would someone on the dashboard "make" a Customer ID?
like if i have some employee in my billing dept. make it via stripe
i am just trying to think of ways this limit by might not work versus storing the id in the db
i imagine the api lookups might be less performance efficient than db lookups?
or maybe they are the same, idk
Likely less performant
yea that is what i think too so idk
storing the id in the db means my site will be more dependent on stripe versus the other payment providers. I want to keep some separation.
If I did stripe.Customer.list(email=customer_email, limit=1) how do I get the id in a single line?
['data'][0]['id'] ?
The response will be an array with one item. How you choose to get the value is up to you
ok thanks. any ideas about what i should do with the db versus api situation?
To me that is a question about the overall architecture of your application. Without knowing the full scope of all the different components it is difficult to be certain how to advise you.
dicit53809 - most recent customer
ok
i guess i will just have to change my code and see what happens and test it myself
In general, we advise you to not rely solely on Stripe APIs. There are rate limits on how many requests you can make and if your application grows you can end up hitting them
because i think it would be great if i could get rid of the stripe id in the db because i would imagine crypto people won't be happy lol
So cutting down on the number of API requests will help improve the speed and reliability of your application
yea true
so tough to decide.
even if you lookup by 1 customer id each time?
what if they refresh a lot or there is a ddos attack?
Especially. Since looking up 1 at a time would mean a new request for each Customer
hmm did not think of that. so you would say i would have a high % (what %) of getting rate limited?
Well it depends. In Test mode you are capped at 25 rps (requests per second). In Live mode its 100rps
This is actually a lot for most web applications since many have other bits of blocking code that are not Stripe related
whoa
yea but if i have a lot of users one day it might be a problem 100 doesn't sound like a lot
You'd be surprised how many people think it's an issue but in reality barely break 10 rps.