#jz-1_code

1 messages · Page 1 of 1 (latest)

glad flareBOT
#

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

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

leaden pebble
#

From my research in docs it seems like it is best practice to pass in our customers connected account id into checkout session creation (since that's the whole purpose of Stripe Connect)

so I'm confused why I can't take the returned secrets and render the embedded form on my site

tranquil oracle
#

Hi there

leaden pebble
#

👋

tranquil oracle
#

Taking a step back, I see you're using Express accounts. For Express accounts, we recommend using destination charges or separate charges and transfers. By passing a stripe_account header when creating the Checkout Session, you're using direct charges instead

leaden pebble
#

I see, I did see that recommendation but for step one we thought direct charge will pass through funds and is easier to set up, and we can always migrate later and direct the funds ourselves. Is that the root of the issue?

tranquil oracle
#

Not exactly.

leaden pebble
#

we also thought that since direct charges allow for application_fee, this would work for our usecase if we wanted to take a fee on top

At the core though we just need a way to manage the checkout sessions for our customers, which is why we decided on express - would you recommend a different setup?

tranquil oracle
leaden pebble
#

ah yeah ok thats definitely something that's missing for us

#

why is it recommended to not go with direct charges for express accounts btw? does this cause problems down the line for us?

tranquil oracle
#

It could. If you go with direct charges, it'll make reporting harder since all charge details (including declines and conversion rate metrics) will be distributed across each individual account vs. on your own platform. Also, since refunds for direct charges come directly from the connected account's balance and Stripe fees are not returned, it's more likely that a connected account will end up with a negative balance. Since platforms are responsible for their Express (and Custom) accounts' negative balances, we'll have to hold a reserve from your platform's available balance

#

Also, disputes will be difficult to manage. Since each charge will live on individual Express accounts if you use direct charges but Express accounts can't address disputes from their own limited dashboard, you'll need to manage disputes on their behalf by navigating to each account directly from your own platform dashboard.

leaden pebble
#

got it! that's very helpful thank you 🙂

#

of the 2, is there a general recommendation on preferred for something that is relatively straight forward on the dev side and risk side?

#

we definitely want to lower chargeback risks on our part but our customers can get paid via ACH or credit card today

tranquil oracle
leaden pebble
#

Helps a lot! thank you for this - was getting confused jumping between 50 different docs that are all slightly different

I will take a review and compare it to our business use case, appreciate the guidance!