#rafaelbaptista-connect

1 messages · Page 1 of 1 (latest)

keen marsh
#

hi! hmm, not really.

the frequency of the payments from the plaform to the connected account
that's not what the setting is for. That setting is for, for the money that is already in the connected account, what schedule is that money paid out at.

#

how often your platform sends money or processes payments with the connected account is something directly controlled by your actual business logic and code.

weary basin
weary basin
keen marsh
keen marsh
#

that frequency is not a setting in Stripe, it's defined by how you actually process the payments.

weary basin
#

what you mean is not a settings in stripe, that payment is processed from the platform to the connected account, so needs to exists a place where the platform can change how often that transfers should be done

keen marsh
#

that's not how it works. Not sure how I can explain it really, I don't know how familiar you already are with Connect.

#

for example if you use https://stripe.com/docs/connect/destination-charges, the way it works is everytime you process a payment with an end-customer, some portion of that is transferred to the connected account. That money then gets paid out to their bank account according to the settings you linked. But the actual transfer of money is controlled by you since you control when you create the payment/charge the end-customer.

weary basin
#

yap i'm using destination charges

#

i tought that the destination could be hold if we set that settings like we can do with the accounts schedule payouts

keen marsh
#

no. The transfer happens when you process the payment. That sends the money to the connected account's balance.

#

you can hold the funds in their balance by adjusting their payout schedule so the money stays there instead of being paid out to the bank account.

weary basin
#

hm understood, the platform have any costs when the payouts of the connected accouns are processed to their associated bank accounts?

keen marsh
weary basin
#

alright, thanks for the help understand this two concepts

#

regarding the express onboarding have some questions

#

when onboarding a express account we have to allways do the create account, and then the generate link?

keen marsh
#

yes

weary basin
#

because for exmple if
John clicks to onboard, but then dont complete the onboarding

i will have the create again an express account and then generate the link with that account

keen marsh
#

true! you could store the account ID acct_xxx in your database entry for "John" and then when comes back and logs in to your system again, redirect him to a new AccountLink for that account instead of creating a new one.

weary basin
#

but when we do the create account the account is actually created on the platform or is like a temp account generated?

#

but how to procced in the case of the user already have a standrd account, we need to create a new one with type express right?

keen marsh
keen marsh
weary basin
weary basin
# keen marsh it's a full account created

rn we are using oauth legacy, witch i think is not recommend but is supported still by stripe ;
exists another days of do the onboarding beside the oauth legacy and the createaccount/createlink?

graceful sluice
#

If the user already has a Standard account, you will still probably want to create a new Express account for them. You can technically have both Standard and Express accounts connected to the same platform but it would be very cumbersome.

weary basin
graceful sluice
#

I'm not sure I understand the question, can you rephrase?

weary basin
#

yes
so basically our system is using the "oauth legacy" (i think stripe called this name), and since we are implementing the stripe express i wanted to know what the options avaible to onboard express accounts

#

i know that we can keep using stripe oauth legacy adding /express on from of the ouath/express
but wanted to know what are the other ways besides this one

#

was talking with karllekki about the accounts links , but that requires to create the account first and then generate that link for the account ( but we needed to store first the account id, in the case we need to generate again the onboarding link

graceful sluice
#

The two methods would be using OAuth or those Account Links. We typically recommend using the account links but you can use either

#

Is there some issue that you have with the two existing methods that you are looking to work around?

weary basin
#

can you provide the doc for that oauth so i can check if is what i think

graceful sluice
weary basin
graceful sluice
#

It looks pretty different from the URL in the doc, if you follow the doc you can build a URL that will work for this

weary basin
#

that is the url that we are using for the current stripe integration for several years, the only thing that i added was the /express in order to be able to onboard express accounts

graceful sluice
#

The Express URL needs to be a bit different unfortunately as far as I can tell. Are you saying that you have tested that URL with Express and it works?

weary basin
#

yes, thats why i wanted to confirm with you

graceful sluice
#

I am unsure why that works, it may be a legacy flow or something. If that works for your purposes you can use it but I would err on the side of using the most up to date info in that doc

weary basin
#

alright, i'm planning on migration to the flow of createlinks

#

but have a question on that flow

#

when i do
$stripe->accounts->create(['type' => 'express']);
should i store new acct, so if i then need to regenerate the link

using
$stripe->accountLinks->create(
[
'account' => 'acct_1032D82eZvKYlo2C',
'refresh_url' => 'https://example.com/reauth',
'return_url' => 'https://example.com/return',
'type' => 'account_onboarding',
]
);

i dont have to create the account again?

#

what is the best approach were?

graceful sluice
#

Yes, it would be best to save that ID and create another link with the same ID if you want the same user to continue onboarding

weary basin
#

if the user for some reason dont fisnish the onboarding an exit
and later on clicks the button and a new link is generated, the information that he entered before is saved or the user will have to enter that info again?

graceful sluice
#

I think it should be saved but I have not checked in a bit. You may want to use an account_update link in that case

#

I am not currently able to test, do you currently have a setup with that code to check on this behavior quickly?

weary basin
#

rn no, i have the oauth implemented

naive adder
#

Hello. Taking over here. One moment while I catch up

#

If the user doesn't finish onboarding, I don't believe the info is saved actually

#

You can try this out in test mode to confirm

weary basin
#

alright, regarding the approach that our system have currently implemented for onboarding accounts, can you please confirm if i can still use this? i was told yes and that yes called oauth legacy but really need to confirm this since is the only thing missing

"https://dashboard.stripe.com/express/oauth/authorize?response_type=code&client_id=" .
                clientid.
                "&scope=read_write&state=" .
                base64_encode($this->encryption->encrypt(json_encode($state_base))) . "&redirect_uri=" . urlencode(base_url() . "Stripe")
naive adder
#

You should be good to continue using that approach

#

We have no plans to get rid of oauth

weary basin
naive adder
#

Oh I didn't catch that bit

#

That is working for you currently?

weary basin
#

yes

#

but because i'm not awere of this was a standard when was implemented want to confirm

#

i just added /express before oauth in order for us being able to onboard now express accounts

naive adder
#

Ok.. not sure why this is currently working. Could be a legacy flow. Going to check with my colleagues about this and get back to you

weary basin
#

ok, perfect .. thank you

weary basin
#

any news on this @naive adder?

naive adder
#

Still waiting to hear back. Will update you

weary basin
#

okok, thank you

naive adder
#

Ok just heard back. So dashboard.stripe.com is the legacy URL for OAuth, so that's why it is working.

#

That being said, we highly recommend to migrate from OAuth to creating the Express account via the API

weary basin
#

ah ok, so thats why ...
from what i saw to convert my url to the new auth url i just need to replace the

https://dashboard.stripe.com/express/oauth/authorize?response_type=code&client_id=" .
                clientid.
                "&scope=read_write&state=" .
                base64_encode($this->encryption->encrypt(json_encode($state_base))) . "&redirect_uri=" . urlencode(base_url() . "Stripe")

with

https://connect.stripe.com/express/oauth/authorize?response_type=code&client_id=" .
                clientid.
                "&scope=read_write&state=" .
                base64_encode($this->encryption->encrypt(json_encode($state_base))) . "&redirect_uri=" . urlencode(base_url() . "Stripe")
naive adder
#

Our recommendation is to actually move off of OAuth entirely as it really is a legacy approach

weary basin
#

and use what approach?

naive adder
#

The one I linked above

weary basin
#

so what stripe recomend is insted of using the ouath replace with the create account/createlink ?

naive adder
#

Yes, exactly

weary basin
#

alright,
i previusly asked the other support member what would happen if the user leaves the onboarding in the middle how then should i approach it?

#

should i
1 - create an account express with the accounts api
2- store the id on the db
3 - generate the link using the createlink endpoint

3a - if the user leaves the onboard and then after some time clicks again i generate the link again with the createlink

#

is this correct?

naive adder
#

Yeah you got it

#

If they leave you can always generate a new link

weary basin
#

and the previusly information that they insert will be on that new onboarding or the user will have to insert it again?

naive adder
#

I believe they will have to enter it again if they exit before submitting anything

#

You can test this out in test mode to confirm though