#phishy-connect

1 messages · Page 1 of 1 (latest)

stark quail
stark quail
#

@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.

zealous pond
#

So the API docs mention that country defaults to US

stark quail
#

but actually yeah I think I remember this is expected

zealous pond
#

but it doesn't if you dont request capabilities

#

or at least it prompts the user

stark quail
#

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)

zealous pond
#

I'm noticing this!

#

I guess I need to ask for country

stark quail
#

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

zealous pond
#

makes sense

#

so my next question is..

stark quail
#

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

zealous pond
#

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?

stark quail
#

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.

zealous pond
#

i heard that

#

i submitted a ticket

#

but I'm wondering if I should just change my whole approach

stark quail
#

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).

zealous pond
#

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?

stark quail
#

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

stark quail
#

and you technically can do it with Express but you shouldn't

zealous pond
#

ah.

stark quail
#

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

zealous pond
#

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?

stark quail
#

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.

zealous pond
#

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.

stark quail
stark quail
zealous pond
#

recipient sounds like a game-changer too

stark quail
#

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.

zealous pond
#

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

stark quail
#

that's my understanding yes

zealous pond
#

so if i switch to recipient, it it possible to change the agreement type of existing customers?

#

rather existing accounts

#

ah, looking like no.

stark quail
zealous pond
#

you've been extremely helpful, thank you