#frankcastle_payout-event-details

1 messages ¡ Page 1 of 1 (latest)

lean cloakBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1346899307068002335

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

warm nymph
pallid flicker
#

Before we go down the route of the payouts objects. Let's double check on the embedded component angle.

So your team doesn't want to use the Payouts list embedded component we describe here? Is the issue around styling or functionality?

warm nymph
#

It's around styling and functionality.

pallid flicker
#

Can you be more descriptive of what the shortcomings are?

warm nymph
#

Our app has lots of index pages. They want them to all look the same. We also integrate with another data source and they want some of that other data shown in each line item.

pallid flicker
#

Okay. The first part I think we could address through modifications with the appearance options. But we don't allow you to modify components within the rendered element from your code so that second part wouldn't be possible

#

I just wanted to make sure we didn't abandon the Payouts list (since it does a lot of useful things out of the box) unless we were sure it wouldn't work for you

#

In that case, the arrival_date is our best guess at when the payout will post to the external bank account.

#

As you said initially, it's not the 100% source of truth (that's the bank itself), but we try to factor in things like regional bank holidays and other reasons the payout might be delayed in posting to the exernal account.

warm nymph
#

I realize the arrival_date is your best guess. Our concern is whether there is a chance that the arrival_date could still be in the future when the payout.paid event arrives. If it is a future date, do you update the arrival_date when you send the payout.paid event so the arrival_date is just the date the payout.paid event was sent?

#

The concern is it would be confuisng to show a payout posted but it posted at some future date.

pallid flicker
#

Yes, that makes sense. I'm not 100% certain, let me check some internal references.

#

Okay I found somet internal docs that are interesting. Banks do not make this easy!

So here's how it works:

  • We send the payout to the ACH system and transition the payout to in_transit
  • When the arrival_date is reached and we have not received a failure notification, we consider it a success and trigger the payout.paid event
  • If the ACH system tells us the transfer failed we send payout.failed

The reason for this? The banks never send a confirmation of success. We will not send a payout.paid before the arrival_date because we use the arrival_date to determine when to fire the payout.paid. However, the end user may see a posting date with their bank before/after the arrival_date.

warm nymph
#

Ok. Thank you for this. It was very helpful.

pallid flicker
#

Sure thing! It was eye-opening for me too. Building Fintech on top of legacy banking systems sometimes means we have to deal with sub-optimal behaviors.