#MarcusStripe

1 messages ยท Page 1 of 1 (latest)

storm glacierBOT
stark socket
#

Hi ๐Ÿ‘‹

Unfortunately we make no guarantee of order or timing of webhook event requests.

charred moat
#

well in this case it is necessary.. or how should i know the current state if you dont even guarantee an order here?

#

and there is an order. Its just that I was processing it in reverse

stark socket
#

As I said, the order is not guaranteed. Just because it has always proceeded in that order does not mean it always will.

In that case you could always use the account ID in the event and query the API to double check the most current status of the Account object.

charred moat
#

so you are saying.. I do receive an event.. and then for EACH, I would check the CURRENT state again..? that would be a lot of overhead I guess?

#

why do you then at all send along all this data, that might not even be up to date anyway?

stark socket
#

It is the current state of the account at the time of the event. You can also use the event.created timestamp to evaluate which event occurred prior.

charred moat
#

ok thanks.
Something else.
If an account is PAST_OVERDUE of information - can I just create a new onboarding link and update the account to get the account back into good state?

stark socket
#

Yes, you can create a new Account Link with the account_onboarding type and collect all details in the currently_due and past_due sections of the requirements property.

charred moat
#

Finally... what about eventually_overdue.. So far I was planning to just ignore it, and to just let my customers add info as it comes in as NOW required... the worst that could happen is that payout is blocked for a few days.. but on my end I would still collect the payment, so nothing is lost anyway.. that would maybe simplify things for my customers..
But I was just told by another customer here that could risk my account to be BLOCKED by stripe if I would have too many accounts disabled in parallel?

stark socket
#

I'm not familiar with the various aspects of Connect Account risk evaluation. But I could see that kind of behavior getting flagged as potential fraud. I'm sure you can see how a platform that just "let" all their Connect Accounts wind up with payouts disabled and still collected funds could appear kind of shady.

#

But your best bet to get a clear explanation of the kinds of behaviors that might get your account flagged is writing into Support at https://support.stripe.com

charred moat
#

ok thanks

stark socket
#

Happy to help ๐Ÿ™‚

charred moat
#

is there one or more pges with the actuall thresholds?

#

like money paid out over which period, max

#

I saw for instnce somwhere 1000 USD / month?

#

if I'd know the thresholds, I could show my customers, so they could judge if they need to bother or not

stark socket
#

That's outside of my domain of knowledge (API, code integrations). That's another good question for Support.

charred moat
#

ok

#

person.updated - do I need to listen to that event, too, or is account_updated enough?

#

what would I check on person_updated?

stark socket
#

person.updated is to track changes to a Person record: https://stripe.com/docs/api/persons

Connect Accounts can be associated with Persons where we need to tie an account to actual individual(s)

#

So if you wanted to keep track of an individual updating things like their dob, email, or address you could listen to person.updated

#

But if all you care about is the Account and it's state you can just focus on account.updated

charred moat
#

ok

#

something else now... losely related -

#

subscriptions - (not connected) - and their payments -

#

how long can a customer with their bank / with stripe - get a refund?

#

or a chargeback or credit or whatever

#

because... my connected account logic is a comission for subscriptions... so I would not like to pay a comission for a subscription feee that I never received / paid back

#

I heard of 60 days somewhere?

stark socket
#

I'm sorry but the actual question here is not at all clear. Can you please rephrase what you are asking?

charred moat
#

ok. let me give an example -

stark socket
#

Also, in my test integration I just refunded a charge from December 2021

charred moat
#

I have a customer, signing up for a subscription service, montlhlu

#

monthly

#

and they pay me lets say 100 usd / month

#

now I give 30% comission to an affiliate referal

#

but if they can get bck the money from stripe or their bank for instance, on their own

#

they could steal money from me or at least get me in trouble

#

ok i will take a note that I myself can give a refund even longer

#

but I guess that is somewhat in control

stark socket
#

but if they can get bck the money from stripe or their bank for instance, on their own
What does this mean?

charred moat
#

but I want o at least avoid the stuff out of my control

#

that for instance they go to their bank and say - no I never bought that. get back my money

#

so now the 100 usd paid to me leave me 2 days later for instance

stark socket
#

That is why the Stripe dashboard allows you to handle resolving disputes

charred moat
#

now of course I cant give 30 USD of a comission for that

#

I am talking about subscriptions not related to connect

#

just normal stripe subscriptions

#

customer A has a subscription

#

customer B has a connected acccount

#

customer B gets a comission because customer A has a subscripton and pays me

stark socket
#

What does customer B have to do with this?

charred moat
#

An Afiliate program

#

they would have a link on their website recommending my saas

#

with an affiliate code

#

so now I pay out money to them whenever a customer they send me pays me

#

but if the customer gets a credit / refund... then they cant get their commission either

stark socket
#

How do you send the commission to customer B?

charred moat
#

the connected account

#

who ever wants to be an affiliate, opens up an affiliate account with me

#

so I create a connected account for the

#

them

stark socket
#

That is not an answer to my question. How do you send the funds?

charred moat
#

?

stark socket
#

What is the mechanism?

#

What action do you take to move funds from your Stripe Account to their Stripe Account?

charred moat
#

Transfer.create(TransferCreateParams.builder()
.setAmount(amount)
.setCurrency("USD")
.setDestination(stripeConnectId)
.build(),
requestOptions);

stark socket
#

Okay, you create a Transfer

charred moat
#

I create a transfer to the connected account

#

Right?

stark socket
#

Yes, that is what that code is doing

charred moat
#

thats a payout, right?

stark socket
#

No

#

A payout is a different thing

#

A payout moves funds from a Stripe Account to a connected external account

charred moat
#

no? So what should I use then, a transfer or a payout?

stark socket
#

But for the purpose of my question forget the payout

charred moat
#

and... I was listening to "payout enabled" so far, for the purpose

stark socket
#

we are only concerned with the transfer here

charred moat
#

so I need to check a different field maybe???

stark socket
#

because you can reverse a transfer

charred moat
#

why would I want to reverse a transfer? you mean in case of a refund?

stark socket
#

Isn't that what you were concerned about?

charred moat
#

Well ideally.. if the refund is done within 60 days.. I would not have paid out anything yet at all

#

and you mean.. after 60 days, for a transfer.. I would just call the reverse transfer?

stark socket
#

Why are you creating refunds?

charred moat
#

for how long? forever?

stark socket
#

That is something you would control

charred moat
#

well not specifically

#

e.g a client complaints

stark socket
#

A Refund yes.

#

Those are Disputes

#

different thing

charred moat
#

eg I had a technical outage on my end

#

then I would give back money to the customer, full or partial

#

and yes, the customer might request the money back from their bank also yes

stark socket
#

So if a customer goes to their bank and says "I didn't buy X". You have a change to provide evidence that they did buy X.

#

So starting with that is a good place to go. Because I assume you don't want customers taking advantage

charred moat
#

yeah sure

stark socket
charred moat
#

but still it might be cheaper to let them go

#

because of the amount is 30 USD -

#

it might not be worth discussing

#

but I would like to avoid to give a commision on top ๐Ÿ™‚

#

ok thanks I will check on disputes also

#

need to wrap up sooon.. bed time long overdue...
One more -
so if I do transfers and not payouts

#

where in the event do I check if transfer is ok to use?

#

I was checking the fields - currently due, eventually due, and payout enabled

#

and errors

charred moat
#

cool thanks

#

capabilities.transfers string

The status of the transfers capability of the account, or whether your platform can transfer funds to the account.

#

a string?

wooden flame
#

yes a string

charred moat
#

found it - >One of {@code active}, {@code inactive}, or {@code pending}

#

so I check for "active" I asssume

wooden flame
#

yes

charred moat
#

could this ever be empty / null also?

wooden flame
#

some can be null. Best to always be safe and check if null really

charred moat
#

ok

#

is it "harder" to get transfers or payouts.. legally / rule wise.. just for some background understanding

#

I mean in regarfs to info needed an thresholds

wooden flame
#

I don't know sorry, you'd discuss this with our support team

charred moat
#

ok

#

ok thanks guys

#

I am done for the day

#

have a good weekend