#josh_error

1 messages ¡ Page 1 of 1 (latest)

cunning tulipBOT
#

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

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

fossil frost
#

hello! I'm taking a look, gimme a couple of minutes

vital jungle
#

No worries

fossil frost
#

hmmm, okay, so looks like you were making a destination charge. For a destination charge, the related objects (e.g. that charge id included) all exist on the platform which in this case is acct_1QyNdE4DV5v9huRd

vital jungle
#

Okay that is my platform account. how do I make it such that the acct_1QyNtFQO0RUdDsWD can see / control those charges and perform refunds

vital jungle
fossil frost
vital jungle
#

Thank you so much, so if I do this You can set the on_behalf_of parameter to the ID of a connected account to make that account the settlement merchant for the payment. When using on_behalf_of. The connected account should be able to see the charges and payment intents, and be able to perform refunds via the payment-details embedded component?

fossil frost
#

ah, nope, so destination charges (regardless of obo) follows that diagram. The difference is just with who is the merchant of record

#

if you want to allow the connected account to see / control those charges, then you need to do direct charges