#ameenoacid

1 messages · Page 1 of 1 (latest)

tender riverBOT
meager wing
#

hi there!

inner summit
#

Hi 🙂

#

Err, can I share a screenshot instead?

meager wing
#

no I need the request ID in string format

inner summit
#

req_Qkzi9CuMFTEaH6

meager wing
#

thanks! give me a few minutes to look into this.

inner summit
#

np!

tender riverBOT
umbral lichen
#

Hey! Taking over for my colleague. Can you try passing the PaymentIntent pi_3OmCfUD8qeYdUep7065hIArW as a source transaction and not the charge ?

inner summit
#

I can give it a try

#

But I think I have tried that

umbral lichen
#

I think the issue is that the PaymentIntent status was processing

#

and not succeeded

#

You need to wait until the payment_intent status become to succeeded and then create the transfer

inner summit
#

I mean, the docs say that if a charge/payment intent is pending, the transfer will assume pending too, and at the bottom it mentions asynchronous payments

#

Nothing states in the docs the payment needs to be succesful

#

To make the transfer object

umbral lichen
inner summit
#

Yep

umbral lichen
#

I think the issue is that you are using a very old Stripe API version

#

2018-02-06

#

While the docs points to the latest version of Stripe API

#

I inivte you to upgrade your Stripe API version to the latest one, in order to take advandage of all the new features

inner summit
#

In this request req_Qkzi9CuMFTEaH6 I made just now

I pretty much did this:

  const clientCharge = stripe.paymentIntents.create(params)

  const transfer = stripe.transfers.create(
   // other params,
   source_transaction: clientCharge.id
)

Which should use the id of the payment intent, but it failed as "No such charge: 'pi_3OmEaaD8qeYdUep71lOfprhp'" ... ? Interesting

inner summit
umbral lichen
#

Honestly can't tell for now, you can check all the changelog between (sorry Discord is a bit busy)

#

but for sure you are using a very old API version (2018)

inner summit
#

I've just tried using the latest version of the api, still the same issue:

req_AfYxTosbBQ79wa

umbral lichen
#

Thanks for testing, checking...

inner summit
#

np

alpine wren
#

Hi @inner summit, at the time when the Transfer was made (2024-02-21 12:36:34) the payment py_3OmF2LD8qeYdUep70EPCgb9U hasn't succeeded yet, therefore it wasn't possible to use it as a source_transaction

#

You would need to listen to payment_intent.succeeded/charge.succeeded webhook event and create a Transfer then.

inner summit
#

I understand that, but it says in the docs if payments are pending, the transfer will also be pending suggesting that what 'm trying to do should work? There's also this on the docs page which describes what I am trying to do:

https://docs.stripe.com/connect/separate-charges-and-transfers#:~:text=The transfer takes on the pending status of the associated charge%3A if the funds from the charge become available in N days%2C the payment that the destination Stripe account receives from the transfer also becomes available in N days

At the bottom of the page it says I can use source transactions with asynchronous payments (that could fail) which suggests that they don't need to have succeeded ... ?

alpine wren
#

I think it's rather talking about pending balance and not pending Charge. The Charge needs to be successful in order to initiate the Transfer.

tender riverBOT
inner summit
#

I mean, here they say

When a payment used as a source_transaction fails, funds from your platform’s account balance are transferred to the connected account to cover the payment. To recover these funds, reverse the transfer associated with the failed source_transaction.

which kinda suggests that balance is used only when the initial charge fails.

Surely needing to have a charge settle would defeat the purpose of source transaction param to tie a transfer to a charge (which is supposed to let you make transfers using a charge amount without having it settle first into your account)?

#

If the above you suggest is true

alpine wren
#

The payment is not completely settled when it's succeeded, that's why it takes a couple of days to be available in your account. But you can already create a Transfer before this happens, thanks to source_transaction param.
Here's a timeline

  1. Charge is confirmed.
  2. Charge succeeds. (here you can create a Transfer with source_transaction)
  3. Balance is available.
#

If you do create a Transfer with s_t, at the time of step 3 the balance is available already on the destination account, and not the Platform.

inner summit
#

It doesn't quite match up though I think:

I'm looking at when other direct debit charges I have they take 5 days before the payment is charged and we get a balance transaction on the payment.

The docs don't say that I need to necessarily wait until a charge.succeeded event, and that i can initiate a transfer for asynchronous payments with source transactions which may or may not fail, which suggested to me what I want to do is possible:

Asynchronous payment methods, like ACH, can fail after a subsequent transfer request is made. For these payments, avoid using source_transaction. Instead, wait until a charge.succeeded event is triggered before transferring the funds. If you have to use source_transaction with these payments, you must implement functionality to manage payment failures.

I can see in stripe that direct debit destination charge transfers occur automatically at the same time the charge succeeds. Why is this not possible for separate charges and transfers? (where the user needs to act as a marketplace?). Otherwise there is a lot more work needed on our application side to manage transfers (compared to destination charges)

#

The above snippet suggests that it is possible to make transfer object before the charge succeeds i.e. the language uses "fails"

When a payment used as a source_transaction fails, funds from your platform’s account balance are transferred to the connected account to cover the payment. To recover these funds, reverse the transfer associated with the failed source_transaction.

lone orbit
#

Yeah I think BACS is a little different in this regard, and the documentation doesn't do a good job of highlighting that

#

We don't create the Balance Transaction for BACS payments until the payment succeeds. The Transfer is dependent on the existence of the BT, as per the error

inner summit
#

So is the only way to get stripe to make both charge and transfer in one action (i.e. not subscribing to a stripe webhook and doing things at a later date) to use destination charges instead of separate charges and transfers? This is suboptimal as per transaction we want to make 1 charge but multiple transfers, however as with destination charges we would have to make 1 charge per transfer

#

For BACS

lone orbit
#

Yes you can either:

  • Use destination charges
  • Create the transfer(s) separately on receipt on charge.succeeded event