#phishy-connect
1 messages · Page 1 of 1 (latest)
@zealous pond do you have an example of the acct_xxx account you created which is then forced to pick USA? There's a few things this could be related to.
So the API docs mention that country defaults to US
but actually yeah I think I remember this is expected
if you specify the capabilities upfront you also have to pass the country (i.e. ask the user for it in your own onboarding first)
I'm pretty sure that's the case, I remember answering this before. I think it's because we can't know what the requirements are for the capabilities without knowing the country
like the requirements for card_payments in the US is different from NL, so we need that info too and if we don't have it, we default to the country your platform is in
currently I'm using on_behalf_of and destination charges, but I runs into all sorts of crap there
like subscriptions not supporting on_behalf_of and such.. all my customers, products, and sub are on the platform
before when i was doing it without on_behalf_of.. i couldnt use destination charges
am I safer just doing direct and using application_fee?
will I run into fewer edge cases?
yep subscriptions don't support on_behalf_of unfortunately, but I believe it is supported as a private beta if you can get access to that.
i heard that
i submitted a ticket
but I'm wondering if I should just change my whole approach
not sure what you mean by 'safer'. You can use Direct yes but it changes the model(you have less control over the connected accounts, they have to onboard as full merchants, they have to handle refunds/chargebacks and so on).
maybe we're talking abot different things
what's it called when you pass in stripe_account? can you not do that with express accounts?
also complicates things like having a customer be able to pay multiple connected accounts or do a 'shopping basket' with multiple items from different sellers
that's called Direct Charges yes
and you technically can do it with Express but you shouldn't
ah.
since as mentioned, it moves liability for refunds/disputes to the Express account, but they don't have any Stripe dashboard for managing that or seeing customer details, and so on
it's something that is technically supported and some platforms do it but it's not what we recommend
yeah.. that whole "I have a full dashboard for their express" and t"they dont" situation is confusing for sure
Ok then. So using on_behalf_of leaves the liability on me which is fine. Then I just want to have the least friction with taking our cut, which can either be application_fee or destination charges internationally
Before I was doing on_behalf_of I know i was runnning into international transfers issues
which would you recommend?
on_behalf_of and application_fee?
yeah on_behalf_of is generally the answer to working with cross border money movement(but it doesn't work for subscriptions). Or, if you're a US platform I'd highly suggest trying the recipient agreement as it lets you do this without on_behalf_of https://stripe.com/docs/connect/cross-border-payouts .
Doesn't help if you don't have a US legal entity/platform though.
There's unfortunately no simple silver bullet answer here, all the options have drawbacks/things to workaround. It's hard to answer without knowing your business but in general Destination Charges w/ on_behalf_of on Express accounts and taking application fees on those, is a standard and well-supported integration yes.
Totally. Thanks for the detailed answer. I know this stuff is tough. But this is what I was looking for.. general direction. So in essence, is application_fee and destination about the same when using on_behalf_of?
Our business is pretty basic. Enabling musicians a media platform for accepting subscriptions to content, with the least amount of work on them that works internationally.
yes, it doesn't change really that much!
Sounds like Destination + Express is a good fit then(since the musicians are probably not interested in running their own Stripe accounts and interacting with customers beyond just getting money)
recipient sounds like a game-changer too
unfortunately it's complicated if you're doing it internationally by regulations, and limitations in the Subscriptions product. And yes, as a US platform you'd have better options(you could omit on_behalf_of and not have to onboard the accounts with the card_payments capability), but it's US only for now.
so you're saying as a US company, i can ditch on_behalf_of, use recipient, and i wont even have to worry about the subscriptions on_behalf_of situaton
that's my understanding yes
so if i switch to recipient, it it possible to change the agreement type of existing customers?
rather existing accounts
ah, looking like no.
AFAIK it has to be set on new accounts yes, though https://stripe.com/docs/connect/service-agreement-types#choosing-type-with-api implies it can be updated but I think only for accounts that aren't fully onboarded yet(Changing the service agreement type will fail if the service agreement has already been accepted; in those cases, create a new account with the desired service agreement.)
you've been extremely helpful, thank you