#rasrules_transfer-questions

1 messages ยท Page 1 of 1 (latest)

tame minnowBOT
open vergeBOT
#

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.

tame minnowBOT
#

๐Ÿ‘‹ 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.

glass marsh
#

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?

grizzled umbra
#

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.

glass marsh
#

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

grizzled umbra
#

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.

glass marsh
#

. 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

grizzled umbra
#

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 ?

glass marsh
#

i thought you were saying they were the same transfer

grizzled umbra
#

nope different transfers

glass marsh
#

if these are different transfers, then please share both id's yes

grizzled umbra
#

sometimes we get the failed event right after transfer created. sometimes we get the failed after the paid event came

glass marsh
grizzled umbra
#

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
glass marsh
#

Yeah please send id's for transfer y and z

#

So i can see what's going on

grizzled umbra
#

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

glass marsh
#

Yeah please share id's so i can take a look

grizzled umbra
#

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.

glass marsh
#

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

grizzled umbra
#

acct_1GBgypE4dteV55eR

glass marsh
#

No i need transfer id's not account id. Need specific examples of what you're referring to

grizzled umbra
#

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)

glass marsh
#

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

grizzled umbra
#

from our db.

glass marsh
#

Do you have a more recent example

grizzled umbra
#

We are looking for at least one.

tame minnowBOT
grizzled umbra
#

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

elfin hornet
#

@grizzled umbra yes

#

rasrules_transfer-questions

grizzled umbra
#

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?
elfin hornet
#

Sorry you lost me

grizzled umbra
#

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

elfin hornet
#
  1. 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
  2. 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
grizzled umbra
#

We are using legacy api.

#

evt_1PYi7eB98mtO5YVYIfjBccBg transfer.created, but object id is a payout id po_1PYi2nB98mtO5YVY8jGjJbuN

elfin hornet
#

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

grizzled umbra
#

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?

elfin hornet
#

yes you can easily confirm by checking the po_123 in the Event

grizzled umbra
#

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?

elfin hornet
#

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

grizzled umbra
#

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?

elfin hornet
#

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?

grizzled umbra
#

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.

elfin hornet
#

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

grizzled umbra
#

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.

elfin hornet
#

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?

grizzled umbra
#

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.

elfin hornet
#

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?

grizzled umbra
#

yes my bad wrong term used really sorry.

elfin hornet
#

totally fine, vocabulary is tricky but in cases like yours it's so important unfortunately

grizzled umbra
elfin hornet
#

yes if you are on manual Payouts you do create a Payout explicitly (and we don't retry)

grizzled umbra
#

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.

elfin hornet
#

yes it will still work the same (though you really should work on upgrading your code to a recent API version)

grizzled umbra
#

I will suggest that to our Software Architect. I am truly thankful for all you patient and support. you do rock Koopajah !!!

elfin hornet
#

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 ๐Ÿ™‚

grizzled umbra
#

it is quite scary hehe. again thanks a lot man !!!