#o9d_api
sleek peakBOT
đ 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/1215215677200408618
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
solar domeBOT
errant hill
Can you share the request ID (req_xxx) with the same parameters that used to work before?
I managed to find one successful request: https://dashboard.stripe.com/logs/req_XEjJ6ZgCh5eVfn
Checking it now
fathom cairn
These are the parameters:
curl --request GET
--url 'https://api.stripe.com/v1/application_fees/fee_1OrQtwDCMLW38inI2prRHDAB?expand[]=balance_transaction&expand[]=charge.balance_transaction&expand[]=account&expand[]=charge.payment_intent'
--header 'Authorization: Basic xxx'
--header 'Stripe-Account: acct_xxx'
--header 'User-Agent: insomnia/8.5.1'
errant hill
fee_1OrQtwDCMLW38inI2prRHDAB in https://dashboard.stripe.com/logs/req_Scosmc4qgXjXxa belonged to acct_1MhVHjDCMLW38inI, but you tried to access it on another connected account acct_1L0o5YDJfPtGEIrX
If you change the Stripe-Account to acct_1MhVHjDCMLW38inI, it should work
fathom cairn
Our setup is quite unique. Revenew is an insights product for Stripe Connect platforms so we access the API on their behalf (since they're connected to us), not their connected accounts
The requests that are failing are for platforms doing Direct Charges to Standard Accounts.
errant hill
The problem here is that the connected account ID set in the Stripe-Account header is incorrect
fathom cairn
Are you saying it doesn't belong to the Stripe Connect platform?
If I don't expand application_fee.charge.payment_intent it works however
That's why I wonder if something changed in the permission model as it was working up to about 17:30 UTC yesterday and then we started getting flooded with these errors
errant hill
With Stripe-Account set, only the object under this specific connected account ID can be set.
In https://dashboard.stripe.com/logs/req_Scosmc4qgXjXxa,
- fee_1OrQtwDCMLW38inI2prRHDAB belongs to acct_1MhVHjDCMLW38inl
- However, the Stripe-Account header was set to acct_1L0o5YDJfPtGEIrX
Can you share the request ID (req_xxx) that successfully retrieved the same application fee when application_fee.charge.payment_intent was not expanded?
errant hill
Thanks for sharing! This is indeed strange! Checking it now
fathom cairn
To provide more context. In this case Visualsoft (the platform) are connected to Revenew via the Revenew Stripe App.
They use Direct Charges to Standard Accounts. The request in question is a payment on the account Gift and Wrap who are connected to Visualsoft.
The application fee belongs to Visualsoft (hence why we can access it via their ID in the Stripe-Account header).
As you say, the payment intent and furthermore charge belong to the standard account which is why we can't access those resources via the payment intent or charge APIs.
However, we can (and have been) able to access those details on behalf of Visualsoft (their ID in the account header) by expanding the charge.payment_intent field on the application fee.
Since yesterday we get the error:
{
"error": {
"code": "more_permissions_required_for_session",
"message": "You do not have the required permissions for rendering resource on account 'acct_1MhVHjDCMLW38inI'. Having payment_intent_read would allow this request to continue.",
"request_log_url": "https://dashboard.stripe.com/acct_1L0o5YDJfPtGEIrX/logs/req_axDoLZOrjFifaa?t=1709801536",
"type": "invalid_request_error"
}
}
But this succeeds if we only expand the charge. Since the charge belongs to the standard account (not visualsoft) in theory both should fail to expand but it's only the payment intent, which used to work before.
You might want to check with Rami Banna in the Stripe Apps team to see if anything changed here though I suspect this is something more broadly to do with Connect
errant hill
Was there any permission changes in your Stripe Apps recently?
fathom cairn
no
Also since we do use the payment intents API directly on behalf of our customers who use Destination charges these would be failing if we didn't have the payment_intent.succeeded permission in our app manifest (which we do)
It seems to only impact platforms using Direct Charges
FWIW I've just tested in test mode and have the same issue. Request req_OIA71YZScTonU7
dawn slate
hi! hmm, please open a support ticket at https://support.stripe.com/?contact=true so we can investigate more deeply and I'll flag internally too
in general I would say "connect on connect" is not allowed(the other account that is a CA of your CA has never given consent to your platfrom to see their data for instance) so maybe it was an oversight we closed, I don't know/have context so we'd need to investigate
fathom cairn
Fair enough. I've already dropped an email direct to the Stripe Apps team so I'll wait for a follow-up there