#rasrules_transfer-questions
1 messages ยท Page 1 of 1 (latest)
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- rasrules_code, 1 hour ago, 4 messages
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1260966106571477083
๐ Have more to share? Add details, code, screenshots, videos, etc. below.
One of them is the transfer.failed this could happen before the transfer.paid event or after that one. I need a little more details about the transfer.failed event please
What do you mean? What details do you need?
we have seen the event transfer.failed. to happen before the transfer.paid comes in, and also after the we got the transfer.paid webhook. so my concern is actually. if we didn't get the transfer.paid and we got a transfer.failed yet will the transfer will be retried because we have created the connect account with default payout as daily? now the other scenario is: after we got the transfer.paid when we got the transfer.failed is this the end on the transfer? Probably the transfer finishes when we get the transfer.failed just want to validate that with you guys please.
Can you share the transfer id where this happened?
So I can see what you're talking about
For reference, we don't guarantee webhook event order, and your app shouldn't rely on events in order
I don't have access to dashboard on prod to share that transfer id. I will request json event response we got from you api. I understand the event order cannot be guaranteed, for sure. My big interest is with current connect user parameters, transfer.failed event does mean transfer is finished and no more event for the transfer will come.
. I will request json event response we got from you api.
That's fine as long as it has transfer id in it
I just need the id so I can look it up and see what you're talking about
so just to be sure. do you mean the transfer id for a transfer that got transfer.paid event and later got another transfer.failed ?
i thought you were saying they were the same transfer
nope different transfers
if these are different transfers, then please share both id's yes
sometimes we get the failed event right after transfer created. sometimes we get the failed after the paid event came
i don't understand what you mean if these are separate transfers
I am just talking about different transfer that do get transfer.failed
- transfer X transfer.created => transfer.failed
- transfer Y transfer.created => transfer.paid = > transfer.failed
- transfer Z transfer.created => transfer.failed = > transfer.paid
that is the reason about asking if transfer.failed means transfer is done. I believe no more events should come for the same transfer after it got failed
Yeah please share id's so i can take a look
sure I am asking my boss. Have you guys received a similar report as transfer Z before?
BTW, we are using mostly STRIPE_API_VERSION = "2019-12-03"
but our dashboard has an older version as default: 2015 something.
api version shouldn't matter
I'm not sure off-hand if this is expected or not, but if you share the id's i can look deeply to see what's going on
And check with colleagues
acct_1GBgypE4dteV55eR
No i need transfer id's not account id. Need specific examples of what you're referring to
There's a transfer for 177.52, and I see a transfer.created, transfer.paid, transfer.failed, transfer.created, transfer.paid
tr_1Ir7e4JtilTwfgTJ408kFlGw
Events:
evt_1IrZsJE4dteV55eRdAIbM5ne (transfer.created)
evt_1Is0M0E4dteV55eRgwPoyJgD (transfer.paid)
evt_1IsMP5E4dteV55eR961Gzwml (transfer.failed)
evt_1Isfd0E4dteV55eR6VgjEdOA (transfer.created)
evt_1It2EOE4dteV55eRG9nw0BeJ (transfer.paid) (edited)
Hm did you copy and paste those event id's? None of those are coming up as valid on my end
Oh the transfer is from 3 years ago that's why
Events are deleted
from our db.
We are looking for at least one.
quick question:
is current behavoir this one=>
hi there!
if you manually created the Transfer and it failed, then it's up to you to re-create a Transfer. that won't be automatically retied
if we turn the connect Account settings interval to manual:
- will that mean that the transfer won't be retried and just failed or paid ?
- if it is on manual, will the payout to the connect user' bank account happen on its own, or do we need to trigger it somehow?
Sorry you lost me
if we turn the connect Account settings interval to manual:
right now the connect user accounts are created with default values. so payouts have a daily interval
- A Transfer moves money from your platform Stripe account's balance to a connected account's balance. It does not leave Stripe. You create those and if they fail you just get an error on creation, nothing is retried
- A Payout moves money from a Stripe account's balance outside of Stripe like a bank account. Those can be either automatically created by Stripe or created by your own code if you use Manual Payouts. If you do Manual Payouts, they are never retried, you own this
We are using legacy api.
evt_1PYi7eB98mtO5YVYIfjBccBg transfer.created, but object id is a payout id po_1PYi2nB98mtO5YVY8jGjJbuN
Gotcha, would be great to upgrade, this change was made over 7 years ago ๐
But the answer is similar in that flow except that for you it's not Transfer vs Payout but po_123 vs tr_123
so this:
Events:
evt_1IrZsJE4dteV55eRdAIbM5ne (transfer.created)
evt_1Is0M0E4dteV55eRgwPoyJgD (transfer.paid)
evt_1IsMP5E4dteV55eR961Gzwml (transfer.failed)
evt_1Isfd0E4dteV55eR6VgjEdOA (transfer.created)
evt_1It2EOE4dteV55eRG9nw0BeJ (transfer.paid) (edited)
is probably not the same transfer but multiple payout created, right?
yes you can easily confirm by checking the po_123 in the Event
I think that I am gonna send you a starbucks if you help me a little more pls ๐
So by following the example above, to avoid that happening we could set the connect user settings interval to manual?
if that is right. as we are only creating transfer, we do need to create also a payout for the money to move from connect user to their default bank account or any external they have there, right?
If you have a connected account on automatic Payouts then all you need to do is put money in their Stripe account's balance and then we will automatically attempt to pay out funds to their bank account on file
we prefer not to see multiple payouts for the same transfer.
or how can we keep this: connected account on automatic Payouts then all you need to do is put money in their Stripe account's balance
without having multiple payout when any of them failed?
So what do you expect? You send them $100, we try to pay out, it fails and then we do what? We never pay them again?
Payout retries are logical if there's an issue with their bank no?
I see your poiint and it does make sense. Right now when we catch a payout failed we are refuding it manually on the stripe dashboard.
so user will see the refund. and if needed will retry later or fix his bank account details probably before that.
Right now when we catch a payout failed we are refuding it manually on the stripe dashboard.
Gotcha, then if you do that nothing will be retried because that connected account doesn't have a balance anymore right?
Honestly to me it doesn't make sense to refund the end customer who paid just because the Payout to the person who offered the service failed
Right now when we catch a payout failed we are refuding it manually on the stripe dashboard.
Gotcha, then if you do that nothing will be retried because that connected account doesn't have a balance anymore right?
Exactly
we are making a transfer to them, requested by them. if it fails we refund it so they can use their cash the way they want to.
Okay, I must be missing something about your flow of funds. Why would they have cash in your own platform that they paid?
Feels like maybe another vocabulary issue and you say "refund" when really you meant that you reverse the Transfer which pulls the funds back in your platform?
so think about this way: Koopajah has money on our platform, He wants to use it in another place. So Koopajah request a transfer. We ask stripe to do so. if it fails we refund the cash back to them on our platform sure.
Gotcha. You likely want to talk to our support team about your business model. Holding cash for end users in your balance comes with stric compliance rules and regulations and you really should make sure this is even allowed.
But yes you meant reversing a Transfer, not refunding because Refund means returning the money from your own account back to the Customer (the person who paid for a service, has a Charge in your account, etc.).
So I guess that means I answered your question and the Payout wouldn't be retried if you reversed the Transfer right?
yes my bad wrong term used really sorry.
totally fine, vocabulary is tricky but in cases like yours it's so important unfortunately
if that is right, the interval manual setting on connect user account. as we are only creating transfer, we do need to create also a payout for the money to move from connect user to their default bank account or any external they have there, right?
yes if you are on manual Payouts you do create a Payout explicitly (and we don't retry)
we will follow the changes with all your advice that fit our flow:
1 interval manual setting on connect user account
2 create transfer
3 create payout
on last question please. with the above changes. can we keep listening only the transfer event webhooks? as we are already doing now.
yes it will still work the same (though you really should work on upgrading your code to a recent API version)
I will suggest that to our Software Architect. I am truly thankful for all you patient and support. you do rock Koopajah !!!
Yeah upgrading is not easy especially when you are many years behind! We're happy to help here and if you do decide to upgrade in the future feel free to come back and ask us questions ๐
it is quite scary hehe. again thanks a lot man !!!