#AngelosBlue
lime thicket
unkempt aspen
hi, that's expected
it didn't used to be, but it changed in an API version such that the PI is only created later
deep pulsar
but we have a fixed API version 2022-11-15
in the other Stripe accounts we have, this is not happening
unkempt aspen
but we have a fixed API version `2022-11-15`
yes and that is after that version where it changed, so it's expected that you will not get a PaymentIntent
unkempt aspen
in the other Stripe accounts we have, this is not happening
those accounts must be using older versions
deep pulsar
is there a possibility that the old accounts migrate to the new version?
deep pulsar
ideally we wouldn't want that as it would break our impl. my real question was if there's a possiblity that the old accounts change to the new API without warning
unkempt aspen
no
only the owner of the account can change the default API version
if you are writing software that you intend to run against multiple Stripe accounts, I highly highly recommend pinning your code to an API version so it works on all accounts (https://stripe.com/docs/api/versioning)
deep pulsar
we have a pinned version, but we didn't receive the change in the old accounts
but sounds clear, thanks!
unkempt aspen
we have a pinned version, but we didn't receive the change in the old accounts
maybe you're talking about receiving webhooks and not API responses? webhooks have their own complexity with API versioning
deep pulsar
no, I am refering to the checkout API response. Although we shouldn't be getting a paymentIntentId we still do.
unkempt aspen
I'd need to see an example of that happening and I could likely tell you why
deep pulsar
this is an example from a different account
we use the same API version, but payment_intent has value in the response
unkempt aspen
that particular account has an account-specific setting applied to it by us that forces the PI to be created
that's a setting we could apply to help with merchants who are doing migrations or who want the new API version but can't handle that aspect, or have certain use cases explained to us for needing the PI initially , probably they talked to support or their account manager and got that setting applied
deep pulsar
can we downgrade for the new account? so as to have the same setting as the old ones
unkempt aspen
what is your software by the way? why don't you use Connect, or identify as a plugin? https://stripe.com/docs/building-plugins#setappinfo
unkempt aspen
can we downgrade for the new account? so as to have the same setting as the old ...
no, if you create a new account, it uses the latest version as a default. If you write to support we can technically downgrade but there's no reason for needing that, since you can force an API version on your requests, as described previously
deep pulsar
that would add complexity in our stack
I suppose we could try and ask our account manager
until we upgrade our implementation to be in sync with the new API
unkempt aspen
that would add complexity in our stack
you say that but you're already doing it?
in the two requests you've shared with me, you are already explicitly passing a Stripe-Version, which is all good and what I'd recommend
your confusion is likely just that on the account you have for that second example, what happens is that even though you use the correct API version, the PI still gets created, which is because that specific Stripe account has a specific internal settting on it that basically opts it out of that specific behaviour and gives them the legacy 'create-PI-when-CheckoutSession-is-created` behaviour