#rahuls1098_docs

1 messages ¡ Page 1 of 1 (latest)

gentle flumeBOT
#

👋 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. Thank you for your patience!

⏱️ We automatically close idle threads, which makes them read-only. Make sure you stick around to chat in realtime! If this thread is closed and you have another question you'll need to start a new thread.

🔗 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/1214959304810176535

📝 Have more to share? You can add more detail below, including code, screenshots, videos, etc.

twilit quartzBOT
#

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.

elder mortar
#

Can you tell me more about what you mean when you say split payment scenario?

cold fractal
#

Sorry I meant payment installments

#

Let's say a user is charged $400, but they will be paying a $100 monthly amount over 4 months

#

Are separate PaymentIntent objects created for each $100 charge, or is a single PaymentIntent created for the $400 transaction (but individual charge objects for each $100 payment)

elder mortar
#

Is this for a BNPL payment method like Klarna or Affirm? If so, yes it would only be one payment intent.

#

And I actually think that would only create one charge object for the full amount and the BNPL company would handle the actual individual payments. Would need to test that in test mode though

cold fractal
#

Yes, like Affirm

#

Okay got it, thank you

elder mortar
#

Also I just tested in test mode and confirmed that you will only get one Charge object for this

cold fractal
#

Perfect, thank you for confirming!

#

Last question - can there be multiple charges if there is an authorization, then capture step, or also if there are multiple attempts (if payment fails)

#

If there are multiple charges, I assume the last charge is what would be relevant to the final Payout

elder mortar
#

For manual capture there is also only one charge. The charge is created with an amount_captured of 0 and that is updated when you actually capture the funds

#

And yes, if there is a successful charge, it will be the latest one related to the payment intent. So it will be the only one that can be in the payout

cold fractal
#

Got it. I was only wondering because it is possible to do Stripe.Charge.list(payment_intent = ""), which implies there may be multiple charges for a single PaymentIntent. But it seems like either the Charge object is simply updated, or I would have to use the last one to tie to the Payout ID

elder mortar
#

Exactly. Listing charges like that would mostly be used to display the potentially multiple payment attempts on an intent, including the unsuccessful ones.

cold fractal
#

If a Charge object is created for a PaymentIntent that has failed, is there an attribute that indicates this (so that i am not just blindly pulling the last charge object assuming it ties to the payout - would need to verify it is a successful one)

elder mortar
#

Indicates that the charge had failed? The charge object itself would have decline info, or you can check the PaymentIntent's status

cold fractal
#

Also, to get from Charge to Payout ID, I was told to get the balance transaction ID from charge.balance_transaction, then the available_on attribute and list all payouts that occurred in the range gte available_on and lte available_on + next day. Is this an accurate way to get the payout ID?

elder mortar
#

Yep that will work, that is the best way to go from Charge -> Payout ID at the moment

cold fractal
#

And given that there may be multiple Payout IDs in that time range, would I then have to list the balance transactions associated with each Payout ID (and the payout ID with the balance transaction matching the original would be the correct payout ID)?

elder mortar
#

If there are multiple than yes, though my understanding is that that would be rare even for an account with daily payouts.

cold fractal
#

Okay perfect. I should be able to get Payout ID now, but Payout Trace ID is important too because that can be used by the client to verify that the payout has actually hit their bank account. I believe trace ID is a unique identifier that matches the bank statement / can be used to verify the deposit. Unfortunately, there is no support for getting this on Stripe API at the moment (I can only see it on the Stripe dashboard), but do you know of any alternate IDs that accomplish this?

cold fractal
# elder mortar For manual capture there is also only one charge. The charge is created with an ...

Actually have a follow up question to this. For manual capture, is relying on checking whether amount_captured = 0 enough to see the Charge is just an authorization charge at the moment? Not sure if there is a scenario where the capture charge amount is also 0. Would I have to refer to the status to confirm this? I assume the status would be pending if just an authorization and amount_captured = 0, and 'succeeded' if it is capture charge

elder mortar
#

amount_capturable on the payment intent or amount_captured being 0 means the funds have not been captured yet. You can only capture funds once, so after you do that amount will be higher

#

And the status will be requires_capture

#

I highly reccommend playing around with this flow in test mode, it will answer a lot of questions and make it much clearer how this works

#

For trace ID I would reccommend talking to our support team, they may be able to help you there

cold fractal
#

Okay thank you for the information, you've been very helpful

cold fractal
elder mortar
#

Not sure what you mean, the available on would still come between when two payouts happened right?

cold fractal
#

I will test in test mode, but do you have any suggestions for handling non-daily payout scenarios?

#

Yes, if payouts are more spread out then the payout will just be an aggregate of multiple balance transactions. I guess there just wouldn't be a payout listed when we list payouts for available_on to +1 day (the payout would only be listed if the date range captures the day in which the payout occurs)

elder mortar
#

Ahright, I forgot you were filterig on time like that. I think you would want to list their payouts without that filter and then find the payout that spanned the time that the balance transaction's available_on timestamp was during

gentle flumeBOT
cold fractal
#

I assume the earliest (closest to available_on) instance of a payout that occurred would be the payout ID for that balance ID transaction, and if there is no payout ID, then the payout simply hasn't been initiaited yet

buoyant burrow
#

Hello! I'm taking over and catching up...

cold fractal
#

Hi Rubeus

#

I have thought of that approach but haven't looked into implementing it. Is there a way to get from charge to PaymentIntent ID?

#

If so that could work

#

However, for PaymentIntents where a Payout hasn't occurred, we might have to say 'Payout Pending', and this isn't possible if we are starting from Payout (since the payout hasn't happened yet)

buoyant burrow
#

It might help if I knew more about what you're building. It sounds like some kind of status page where people can see what's going on with certain payments?

cold fractal
#

Yes one sec

#

I have a payment ledger for my client which tracks the transactions facilitated through Stripe. This ledger reports the PaymentIntent ID for each of their clients. However, they need a way to see that the Stripe transaction on the ledger has actually hit their bank account. Payout ID would be useful to see that the money has left the Stripe account

#

And Payout Trace ID is needed to verify that the money that has left the stripe account has hit their bank account

buoyant burrow
#

Is Stripe Connect involved?

cold fractal
#

Yes this is Stripe connect

buoyant burrow
cold fractal
#

This is great but we mostly need to work with the API at the moment, becausee we want to be able to export this ledger (download) and it should have the Payout ID and Trace ID

#

I was working with @elder mortar to find a way to get from PaymentIntent ID which we have on the ledger to Payout ID.

buoyant burrow
#

The Payment Intent will have up to one successful Charge. That Charge will have a Balance Transaction. You can then check to see if that Balance Transaction is included in a Payout or not.

#

If I were building something like this I would listen for payout.created Events, then use the expansion approach I linked to above to get all the Charges for the Payout and store that information locally. Then I could query my local data to see if a given Charge is part of an existing Payout or not.