#rahal-transfers

1 messages · Page 1 of 1 (latest)

fiery crane
#

then you probably are not an Administrator on your Stripe account

river timber
#

Ok, and this setup is common between prod and test mode? as my transfert is in test mode for now

fiery crane
#

that setting is shared between test and live mode yes

#

if that' a problem you might want to create a new account just for testing with

river timber
#

Ok, grat thanks, it's done

#

I don't know if I'm doing the transfert the right way.. I way to transfert money to this conecter account from my current balance

fiery crane
#

presumably you don't have any balance then!

river timber
#

Oh.. I made paiements in test mode and they were successful.. but that doesn't mean the money is available

fiery crane
#

no, they take a few days to clear. There's a test card to skip that period

river timber
#

I used test sepa account for my test

#

ok, well.. I'll add some founds then try again, thanks

river timber
#

The error changed, I'm a little confused.. it says that sepa_balance is too low. I guess it's because I used 'source_type' => 'bank_account',

fiery crane
#

hmm. I think you should use source_type:card instead(or just omit it). yes I know that's confusing.

river timber
#

I removed source_type' => 'bank_account' and it worked.. but I don't understand... in prod mode, we are supposed to be working exclusively with sepa_mode , will the "card" have founds?

fiery crane
#

source_type:bank_account only contains balances from US ACH payments, for some legacy reasons, everything else goes to card. I've never seen this "Your SEPA balance is too low" error before though, maybe something is special about your account. But try it with just removing source_type

#

yes card will have funds

river timber
fiery crane
#

the way it works is if you do payments with US ACH payments, those funds go to bank_account. Everything else(inlcuding SEPA) goes to card

#

yes

#

as a side note usually you use source_transaction or destination charges, is there are reason you're not? It creates a lot of work to do it the way you're doing it since you have to keep track of your balance.

river timber
#

ok, thanks for the clarification.. So no need to setup source_type

river timber
#

we do this as I create invoices on the behalf or our partners with the exact paid "services" before initiation the transfert ( so the balance should be enough... althought, i think I need to pay attention to stripe fees )

#

I don't know if in this setup, I can you source_transaction

#

maybe we are not doing it right.. I'm trying to keep the "developpement work low" and not throw away existing code

fiery crane
#

makes sense. I do think you can probably use source_transaction though, don't see why not. You'd just set it to the Charge from the successful PaymentIntent that you ran(multiple transfers can use the same source_transaction for instance)

river timber
#

mutliple transferts can use the same source_transaction, that's good.. but can multiple paymentintent use the same source_transaction too? what if a paiment fails?

fiery crane
river timber
#

Guess I don't understand what you meant with this ( You'd just set it to the Charge from the successful PaymentIntent that you ran ) . and I already listen to the webhooks to make sur the paiments are successful.. but I think, it's not enough.. I still need to make sur all the founds are available

#

or listen for webhooks to make sure funds are received for those payment intents

#

if I understand correctly, payment_intent.succeeded doesn't necessary mean the money can be transfered

fiery crane
#

but I think, it's not enough.. I still need to make sur all the founds are available
so when you get the payment_intent.payment_succeeded event the payment was successful and the funds are added to your pending balance. A few days later(depends on your country, I linked to payout timing earlier), those funds become available.

If you want to transfer the funds to connected accounts you either :
a) wait until you have enough in your available balance and then call the transfer API
b) use source_transaction https://stripe.com/docs/connect/charges-transfers#transfer-availability , which you can in fact do before the funds are available "By using source_transaction, the transfer request succeeds regardless of your available balance and the transfer itself only occurs once the charge’s funds become available."

river timber
#

I don't undestand how to use source_transaction as I use PaymentIntents for the paiements, do I just need to set an arbitrary value?

fiery crane
#

it's the ID of the charge from the PaymentIntent

#

intent.charges.data[0].id

river timber
#

but I have multiple PaymentIntents... maybe 100 Payments for 10 transferts ( for example ) , how can I set the source_transaction for my case

fiery crane
#

that depends on your business logic and how you connect these payments being made to customers to the money your partners make

river timber
#

we have multiple parteners collaborating for the same customer ( so they have a defined percent of their monthy paiement ) , and an affiiliate ( wich we'll also consider as a partners that will have a small percet too ) ... So we have connected accounts for parteners ( businesses ) and affiliates ( individuals ) . and every month, we charge all our customers, et "when all transferts" are in , we make transferts to the connected accounts. I don't know if I explained correctly the business logic

fiery crane
#

makes sense I suppose

#

I don't have any input for you! As you said, it's business logic. You'd probably make life easier from an accounting and auditing perspective to link the transfers to appropriate payments in whatever way makes sense for your business.

#

from the technical perspective all that matters in the API call is the charge you use as the source_transaction has enough pending funds for the amount of the transfer

river timber
#

Sorry, I'm really having a hard time understanding this " is the charge you use as the source_transaction has enough pending funds for the amount of the transfer"

haughty sonnet
#

Hey, taking over from @fiery crane – let me catch-up

river timber
#

sure

#

Thanks

haughty sonnet
#

Ok, yeah. So if you're creating a transfer with amount: 999 and you pass the source_transaction parameter then that Charge/PI must be >= 999

river timber
#

my confusion is about the source_transaction "value" , where to get it? as I explained, I may have 100 paymentIntent and I'll have only 10 transfers ( I need to make sure all the 100 paymentIntent funds are available before initiating the 10 transfers )

haughty sonnet
river timber
haughty sonnet
#

I mean, you don't need to use the source_transaction parameter

#

If a transfer does not correlate directly with a single payment then it's probably not useful

river timber
#

So I just need to make sure all payments are sucessful and more importantly that the funds are available. how can I be sure that all Payments are "Available" ?

haughty sonnet
#

That'll ensure there's sufficient funds to cover the transfer

river timber
#

ok, that's one way.. is there a way to make sure every single Payment Intent is available?

haughty sonnet
#

Not really, no. The state of subsequent balance isn't managed on the PI object

river timber
#

there is no weebhooks that I can listen to when the available balance changes then I can know what PI became available?

haughty sonnet
#

But that won't contain any details about which PI became available

river timber
#

I saw.. but I'll now that every PI is available when pending = 0 ( if we stick to only one paiment cycle per month )

haughty sonnet
#

I'm not sure I understand

river timber
#

while listening to the balance.available event, I can still read the pending balance, and if it is = 0 , it should mean than all the PI are available

haughty sonnet
#

Yes, but more importantly you want to ensure the available balance is enough to cover the transfers

river timber
#

Ok, gotcha.. I'll juste check my available balance before running all my transfers, Thanks for the feedback

haughty sonnet
#

Sure, np!