#si_docs
twin marlinBOT
đź‘‹ 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/1461674544036184161
đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.
summer monolith
Hi! I'm also wondering if we need to do this:
(Optional) If the connected account is the settlement merchant, include payment_intent_data[on_behalf_of] with the value of the connected account ID.
rose badger
đź‘‹ happy to help, what can I do for you?
the difference between the 2 integrations is the type of charges https://docs.stripe.com/connect/charges#types
twin marlinBOT
rose badger
for marketplaces we recommend using destination charges
brisk sedge
Taking over from my colleague. Let me know if you've any follow-up questions
summer monolith
Hi @brisk sedge , thanks @rose badger
So our payment flow is this:
The customer is on our website and browsing music. They click to buy a song. They then get taken to a Stripe checkout page that belongs to the musician.
I thought we were using Destination charges, but from the diagram on the charges page, it looks like we're actually using direct charges? And that direct charges are the ones that use the stripeAccountId as an option?
And so we should switch from direct charges to destination charges, and use the Tax steps for that type of charge?
(because Tax stuff doesn't work that way for direct charges?)
brisk sedge
Do you happen to have an example Checkout Session ID for how you're creating them now?
And so we should switch from direct charges to destination charges, and use the Tax steps for that type of charge?
It depends, really. You need to use the charge type that best suits your business and your users. I'd recommend reading the link my colleague shared above which explains the critical differences (e.g. refund/dispute liability, who pays the fees, etc)
summer monolith
I think this one works? cs_live_a1a5xQGx0HD2TIDSWTPaFTj9VQkHaUMTrZzITwSuETNh9xvBxpNRaoIAIr
brisk sedge
OK, so you're currently doing direct charges (via the Stripe-Account header) with standard accounts. That's this. Critically:
You create a charge on your connected account, so the payment appears in the connected account’s balance, not in your platform’s balance.
The connected account’s balance increases with every charge.
Funds always settle in the country of the connected account.
Your platform’s balance increases with any application fees you collect for a charge.
Refunds and chargebacks reduce the connected account’s balance.
You can choose whether to have Stripe debit fees directly from connected accounts or from your platform account.
Going back to your original Q, why is it you want to transition to destinatioin charges? What's not working in your current flow?
If you switch to destination charges now you'll likely to reonboard all the connected accounts as they're not really configured for destination charges
summer monolith
Aha, that last bit is crucial hah
And I'm not sure how feasible it would be (except I guess if it has to be :/)
We're looking to switch because of what we're reading here: https://docs.stripe.com/tax/tax-for-marketplaces?charge-type=destination-charges
Many countries and US states require marketplace operators to collect sales tax and VAT on their facilitated sales. The US refers to these businesses as marketplace facilitators, while other regions, such as Europe, might refer to them as deemed sellers.
As a marketplace operator, your tax collection requirements differ depending on the country or state. However, if your electronic interface enables transactions between buyers and sellers and you directly or indirectly collect customer payments, you might need to fulfill tax collection responsibilities.
We think we qualify as a marketplace in this context
brisk sedge
But you're not doing destination charges, so that's irrelevant to you as a platform. You're not the merchant of record for the payment – the connected account is with direct charges
summer monolith
Okay
brisk sedge
The onus is on the connected account merchant to calculate and collect tax. See here, you're the 'software platform' in your current setup
An e-commerce platform like Shopify or Squarespace that enables businesses to build their own online stores to sell directly to customers.
That's essentially what you're doing in the example you shared with me
summer monolith
Cool. I think we had a little bit of a jump scare with this one
brisk sedge
If you switch to destination charges, then you become the merchant of record and are then liable for tax, refunds, disputes, etc for all payments yes
summer monolith
Okay, thanks for clarifying!
brisk sedge
I will caveat this by saying we/I are not tax experts so I'd check all this with a tax advisor. But in your current setup you are not the merchant of record, your connected accounts (users) are