#lukeKu-funds-available

1 messages · Page 1 of 1 (latest)

icy finch
#

Hello! Instead of waiting for the funds to be available in the platform account, you can create the transfer using source_transaction to transfer pending funds that will be made available on the connect account when the original funds will be made available in the future

slender cloud
#

Ok, can you give me the events of a successful flow in that case?

Also, I think we may have to stick with the customer -> platform -> connect account flow (though our team is still discussing if this is a necessity)

icy finch
#

The transfer flow I mentioned would still be doing customer -> platform -> connect account

slender cloud
#

I understand. But we are considering offering an option where a customer can make a payment for multiple Connect Express users at once and/or we can hold the funds in our platform account until agreed upon work is done.

#

if we use the source_transaction, would we just create the Transfer as soon as the payment_intent succeeds?

icy finch
slender cloud
#

so if we offer ACH next (which is on the project roadmap), it says to avoid using this until charge.succeeded is fired

#

is that what we should use instead of payment_intent.succeeded?

#

and then again, what is the flow for webhooks we should be listening for if we do use the source_transaction param in our transaction? Is there anywhere that lists the order of webhooks being triggered?

icy finch
#

I believe charge.succeeded and payment_intent.succeeded would trigger around the same time so you could use either

#

The general flow would be that you listen for payment_intent.succeeded and in that webhook handler you'd create the transfers you need

slender cloud
#

what about when funds are being held before being released? It looks like payment_intent.succeeded happens long before the funds are actually available to the platform

icy finch
#

Are you specifically concerned about the ACH flow here?

slender cloud
#

well, our hope is that we can set up one flow that will work for either case, as we do not want to have to re-engineer this in 2 months when ACH is added

#

and we got bit already finding out that the first transaction on the live platform takes 7 days to be available

icy finch
#

Gotcha - the reason I call out ACH is that because it's as mentioned in the docs I linked to, ACH can fail asynchronously (within the first 5 days). However, once you get the charge.succeeded/payment_intent.succeeded event you have the guarantee that those funds will eventually become available. So it should be fine for both your ACH and card logic to wait for the payment_intent.succeeded event and trigger your transferring logic from there

wintry granite
#

I tried this, but ran into funds available issue. Had to do something like this:

const charges = await listCharges({
    transfer_group: event.Id,
    expand: [chargeExpandables.balance_transaction]
  });

  let balance_object = charges.data.reduce(
    (output, charge) => {
      const amount = charge.balance_transaction.amount;
      const fees = charge.balance_transaction.fee;
      const net = charge.balance_transaction.net;
      return {
        available:
          output.available +
          (charge.balance_transaction.status === "available" ? amount : 0),
        pending:
          output.pending +
          (charge.balance_transaction.status === "available" ? 0 : amount),
        fees: output.fees + fees,
        net: output.net + net
      };
    },
    { available: 0, pending: 0, fees: 0, net: 0 }
  );
#

...checking for available balances...

icy finch
#

Are you getting an error when making the transfer?

slender cloud
#

Got it. So from there, we just create the transfer to the Connect account, pointing to the source_transaction. What webhooks come next in the listener flow?

I assume we'll get a transfer.created, and then what indicates that the funds are available in the Connect account?

icy finch
#

You should be getting a balance.available event from the Connect account

slender cloud
#

but we can ignore that if we're listening for transfer.paid? Otherwise, we have to loop through all the outstanding charges/payment_intents to see which was paid out

Once transfer.paid fires, then if we want to automate the manual disbursement of funds, we can initiate a payout on behalf of the Connect account. We listen for payout.paid, yes?

#

(I realize there is an automated flow via Stripe for releasing the funds, but for the time being, we cannot implement in that way)

icy finch
#

You likely don't want transfer.paid - that's a byproduct of when Payouts + Transfers were the same thing (https://stripe.com/docs/transfer-payout-split). What is your goal here? To have a webhook event that would tell you when funds available so you can create a payout?

slender cloud
#

yes

icy finch
#

Can you give me more details about why balance.available isn't what you want? I imagine you'd just listen for that event, and then you'd create a payout for all the available funds.

slender cloud
#

Say we have 500 customers, 1000 Stripe Connect Express accounts, and then 50 payments per day. If we get a balance.available event, how do we know which of the payments it's indicating?

icy finch
#

Ah, just to clarify - is your question about knowing which connect account to payout to? Other than knowing which connect account to payout to, you don't necessarily need to know which exact payment you're paying out unless you have specific business reasons for it

slender cloud
#

So each payment from a customer will be owed to a connect express account. If business A wants to send $100 to connect account 33, we will get a webhook that $100 is available, but there may be 40 other outstanding payments

#

the balance.updated is only for the Stripe platform account, not for the individual Stripe Connect account, no?

icy finch
#

So a customer makes a payment to your platform account. The payment was successful so you get a payment_intent.succeeded webhook event on your platform's account webhook. From there you create a transfer with source_transaction for $100 to connect account 33.

At a later point in time the funds will become available, and so you have a separate connect webhook that retrieves webhook events that are happening on your connect accounts. You get a balance.available webhook event from Connect Account 33 so you know to trigger a payout to send those available funds

slender cloud
#

Ah, ok!

icy finch
#

the balance.updated is only for the Stripe platform account, not for the individual Stripe Connect account, no?
This is why we were talking past each other a bit - platform accounts can create connect webhooks that get notified of events that occur on connect accounts

slender cloud
#

Yep! Got it

icy finch
slender cloud
#

Ok, so I think this answers my questions for the evening. Thank you so very much!

icy finch
#

I'm glad we could get the cleared up!

slender cloud
#

Just realized I have one more question: we still need to be able to tie the incoming funds to the original transaction within our system. It looks like we would still need to loop through the Connect account's tied transactions to see which one was paid

icy finch
#

Can you describe the above the same way you did earlier (where you had connect account 33 that was transferred $100)?

slender cloud
#

Sure. I'll reference our internal transactions too as InternalTransaction

Business A sets up an InternalTransaction with Connect Express Account 33. This is InternalTransaction abc-111

They come to terms on a deal and Business A pays $100 + fees to the Stripe platform account. When we create the payment_intent, we are passing a meta data field: {internal_transaction_id: "abc-111"}

The same day, Business B sets up an InternalTransaction with Connect Express Account 33, with internal id def-222. They come to an agreement and Business B pays $100 + fees. We create the payment_intent, passing meta data: {internal_transaction_id: "def-222"}

When the charges succeed, we immediately create transfers to the Connect Account 33.

Now we get a single balance.updated event, but their balance is only $100.

How do we determine from which internal transaction (or payment_intent, or charge_id, all of which we persist) the balance update event triggered so we can mark it as "payout_pending" in our DB?

#

I have to step out, will check this shortly 😄

icy finch
#

Thanks for laying all of that - really helps give a lot more context. So it sounds like you want to be able to tie these transactions together to reconcile Stripe's status of the balance transaction with what you have internally

#

This a bit tricky to do since there isn't really a webhook event that tells you which specific balance transaction has been made available at that point in time