#MarcusStripe
1 messages ยท Page 1 of 1 (latest)
Hi ๐
Unfortunately we make no guarantee of order or timing of webhook event requests.
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
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.
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?
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.
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?
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.
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?
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
ok thanks
Happy to help ๐
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
That's outside of my domain of knowledge (API, code integrations). That's another good question for Support.
ok
person.updated - do I need to listen to that event, too, or is account_updated enough?
what would I check on person_updated?
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
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?
I'm sorry but the actual question here is not at all clear. Can you please rephrase what you are asking?
We also have a subset of our FAQs specific to Refunds: https://support.stripe.com/questions/refunds-faq
But that might not address your question
ok. let me give an example -
Also, in my test integration I just refunded a charge from December 2021
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
but if they can get bck the money from stripe or their bank for instance, on their own
What does this mean?
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
That is why the Stripe dashboard allows you to handle resolving disputes
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
What does customer B have to do with this?
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
How do you send the commission to customer B?
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
That is not an answer to my question. How do you send the funds?
?
What is the mechanism?
What action do you take to move funds from your Stripe Account to their Stripe Account?
Transfer.create(TransferCreateParams.builder()
.setAmount(amount)
.setCurrency("USD")
.setDestination(stripeConnectId)
.build(),
requestOptions);
Okay, you create a Transfer
Yes, that is what that code is doing
thats a payout, right?
No
A payout is a different thing
A payout moves funds from a Stripe Account to a connected external account
no? So what should I use then, a transfer or a payout?
But for the purpose of my question forget the payout
and... I was listening to "payout enabled" so far, for the purpose
we are only concerned with the transfer here
so I need to check a different field maybe???
why would I want to reverse a transfer? you mean in case of a refund?
Isn't that what you were concerned about?
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?
Why are you creating refunds?
for how long? forever?
That is something you would control
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
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
yeah sure
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
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?
yes a string
found it - >One of {@code active}, {@code inactive}, or {@code pending}
so I check for "active" I asssume
yes
could this ever be empty / null also?
some can be null. Best to always be safe and check if null really
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
I don't know sorry, you'd discuss this with our support team