#nova-astramentis_api

1 messages · Page 1 of 1 (latest)

feral shuttleBOT
#

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

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

marsh pawn
#

This is an integration we have tested for ~3-4 months now, working perfectly until we pushed from dev to prod.

merry umbra
#

hi there! give me a moment to take a look

marsh pawn
#

The upgrade to basil breaks our integration because of how parameters from the Invoice object have been removed. I tried upgrading to basil 2025-06, but this is a massive change

merry umbra
#

I see

marsh pawn
#

We want to use acacia with the beta header in live mode, I see nothing that says we can't (also your test modes still work just fine)

merry umbra
marsh pawn
#

acct_1HJ0jTKvrNqDdLmf

#

Thank you for your time and speedy reply here. My customer is on the verge of a panic attack 🙂

merry umbra
#

no worries. could you grant me access to the webpage shown in your screenshot that displays the error? I checked the api logs for acct_1HJ0jTKvrNqDdLmf but I'm not seeing any errors

#

any chance I can reproduce the error shown in your screenshot?

marsh pawn
#

The error was thrown when attempting to perform an oauth connection request

#

Give me a second to reproduce with a known account ID

#

One sec, I have to access the prod database to grant permissions since the person with admin is away

merry umbra
#

okay

marsh pawn
#

Okay cool. The test account ID is acct_1KkBo8Iw1p1PjYxm

#

Heres some more info from my own logging

#

event: PaymentEvent(account=acct_1KkBo8Iw1p1PjYxm, apiVersion=2022-08-01, connectEvent=true, id=evt_1RoaBbIw1p1PjYxmfESrmWGR, payload=<com.stripe.model.Application@266067128 id=ca_IVPIC1A4lHQReUY2sU1gNxzUfkd42Tum>)

#

Looks like the issue is actually the header/api version on the connected account?

merry umbra
#

it seems likely, in live logs for acct_1HJ0jTKvrNqDdLmf, I saw attempts to connect with connected accounts such as acct_1RoW9iRvZkRpdktk and acct_1RoWB7P9kZiX0jOQ which returned the error checkout_beta_header_not_permitted

marsh pawn
#

Okay cool. How do I force them to use the required API version?

#

For reference, the line 343 is what is failing

merry umbra
#

It is not possible to force upgrade another Stripe account's API version, unless the Stripe account owner upgrades the API version themselves. I would encourage you to update your integration to use at least 2025-03-31.basil so that the custom_checkout_beta=v1 is not needed

marsh pawn
#

I don't want to upgrade their version, just use my specified version when making requests

#

is that not allowed?

#

Im making requests on behalf of their account in this case (as you can see in the screenshot above)

#

Also, why would this work in dev mode but not live mode?

#

(For the record, 2025-03-31.basil is the problem child in API upgrades, specifically the following)

merry umbra
#

It is generally allowed to stay on your current API version but make request in another API version, whether or not it on another Stripe account.
But the issue here is the general availability of a feature — Custom Checkout is only generally available across all Stripe account from 2025-03-31.basil onwards

marsh pawn
#

But if we never use custom checkout with their stripe account ID in the header, the issue then becomes the fact that I added a default beta header to mine?

#

Specifically,

merry umbra
#

Your Platform account has access to pass custom_checkout_beta=v1 as a header, but the connected accounts that's trying to connect with acct_1HJ0jTKvrNqDdLmf does not.

marsh pawn
#

Ah, and this didnt matter in test mode because?

merry umbra
#

That's a good feedback that you can raise to our Support Team. Generally it should be the same

marsh pawn
#

Yeah that bit us really, really hard. Today was a go-live date

merry umbra
#

Also, is the Beta Version declared in the global scope currently?

marsh pawn
merry umbra
#

Yes, I mean when is it declared? When you initialize Stripe, or when you create the checkout session?

marsh pawn
#

When I initialize stripe

#

The java SDK requires that

#

I suppose I can override the stripe version on every connected account request...

#

Or can I just set the header when making the one specific session create request that needs it?

merry umbra
#

Yes you should be able to pass the beta version header only when you create the checkout session

#

but let me clarify, are you creating the checkout sessions on your connected accounts?

marsh pawn
#

No

#

We only create checkout sessions on the main account

#

We use direct charges and transfers on connected accounts

merry umbra
#

so the checkout session objects exist only on acct_1HJ0jTKvrNqDdLmf?

#

Okay

marsh pawn
#

Something like this?

#

We need a stopgap at the least, I can upgrade when we can breath

#

This appears to be what your sdk does internally

merry umbra
#

Yup you can try that

marsh pawn
#

Let me see if the magic sauce works

#

How do I raise feedback to the appropriate support team about the documentation landmine?

#

Ideally, you guys warn us when we add global beta headers that they also apply to connect calls, then provide a .withBetaFeature(beta, version) to RequestOptions and it becomes an us-problem

merry umbra
marsh pawn
#

Gotcha. Give me 5 minutes to test that i can still create a session

#

Okay, so the call itself worked. Would you be able to check that you see the right thing on your side?

#

Session ID is cs_test_b1XTlvyj4sY2og8yVczzfKg9pL8KYKkk6MYRGOr1uBZ4AgVx5k2ydwDy76

#

For customer ID cus_NoiqNrYitbnsxa

merry umbra
marsh pawn
#

Okay cool, I really really appreciate the concise answers here. Im going to punt this over to our QA dude, and hopefully this buys me time to get to 2025-06-basil

#

This won't work forever correct? Eventually that beta header dies?

merry umbra
#

Yes relying on the beta header does not future proof your integration, especially if the feature is already generally available in later API versions.

#

You can consider moving up to 2025-03-31.basil before upgrading to 2025-06-basil. There are a few major changes introduced in 2025-03-31.basil

marsh pawn
#

Do you happen to know offhand where invoice.application_fee_amount went wandering to?

#

I didnt see that anywhere in the basil migration docs

merry umbra
marsh pawn
#

So I can't see how much the application took?

merry umbra
marsh pawn
#

Ah, gotcha. Sorry, ill dip out for now so I don't make this a thread about 'where the heck did everything go'

#

I think the primary question has been solved 🙂