#brittany-apikey-format

1 messages · Page 1 of 1 (latest)

twilit valleyBOT
humble sparrow
#

brittany-apikey-format

#

Hey @crisp elbow ! Most API keys start with pk_test_ or pk_live_. Some historical really old ones only have pk_xxxxxxxxx. Some even have no prefix

crisp elbow
#

Thanks! The old one should still work though?

humble sparrow
#

In most cases yes. There are a few exceptions where those keys don't work

#

We mostly recommend that people roll those keys and get new ones if needed

crisp elbow
#

ok do you have a resource i could send to our client for how to request a new key?

humble sparrow
crisp elbow
#

when we make a call to the v1/charges api, does the the old key vs new key make a difference in the return from the api, more specifically the "paid" vs "succeeded" status?

humble sparrow
#

/v1/charges is a server-side integration which would use a Secret API key.

crisp elbow
#

Ok, is it possible their secret key could also be old???

#

and then my question still stands but would be related to the secret key being old then

#

when we make a call to the v1/charges api, does the the old key vs new key make a difference in the return from the api, more specifically the "paid" vs "succeeded" status?

humble sparrow
#

no none of that matters

crisp elbow
#

hmmm okay so let me elaborate on our issue in case you have any ideas. we thought we solved it with another moderator last week but we are still having issues.

humble sparrow
#

paid vs succeeded means you're not handling API version properly

#

what this means is that you likely got extremely lucky for many years that your users only had recent enough API versions and now you have a really old accounts with an old API version

#

Really as a developer, your code needs to be explicit about which exact API version you want to use for every API request you are making

#

if you don't, then you use whatever is the default (and we have 12 years of changes) which could break your integration in many subtle ways

crisp elbow
#

ok, this wasn't clear when i was chatting with a moderator last week. we are always making a call to api.stripe.com/v1/charges. is the api version variable/managed on the stripe customer-level, the customer we are operating on behalf of? our assumption was that since we are always making a call to v1, the return object would be consistent with that version

#

for two different customer configurations we are making calls to api.stripe.com/v1/charges but one returns "succeeded" and one returns "paid" so that's where we were getting stumped

humble sparrow
#

yeah you're definitely misunderstanding how our API works entirely

#

everything is /v1. Over the past 12 years we have regularly made many changes to our API like changing the value of status. That is done with API versions

#

so as the developer, if you integrate in say 2018, you expect a refunds property on Charge. But in 2022 we removed it

#

so as the developer waht you need to do is clearly tell us "hey I am using that 2018 API version, please treat all my requests with that version"

#

if you don't do that, we use the default on the account. And I'm assuming you build a "connector" or "plugin" here where you collect API keys by end users and they each have their own Stripe account

#

does that make sense?

crisp elbow
#

yes that does make sense. thank you!