#marcial_a

1 messages · Page 1 of 1 (latest)

lean galeBOT
#

Hello! We'll be with you shortly. 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.

steep zealot
#

@ripe iron I'm sorry but I read the question a few times and don't really understand what you are describing at all right now

lean galeBOT
ripe iron
#

Here is a screenshot in case it helps. You'll notice there is a charge of 1412.13 initially at the very bottom. It is then refunded for the difference of one user, which doesnt make sense.

To hopefully make it more clear, say you went to a store and your kids both wanted candy. You as the parent paid for each of your children as they did not have the money to pay for their own candy.

In this situation the clerk charged you for both childrens candy in total, but then gave you back the money for one childs candy. And charged you again for the second childs candy.

image.png
inland root
#

Thanks for the explanation though I'm still not quite clear on your goal here. Are you trying to understand why one of the later transfers was created? Also is this a thing that consistently happens in your system, or is this issue more of a one-off

ripe iron
#

My goal is to have one user make a payment for multiple users. Our system allocates payments for each users cart based on these separate payments on the same card.

I am trying to see what we can do to prevent a large charge that is then refunded for the difference and charged again. If there is a way to do that so we do not have our payout affected by these constant refunds taking place. It seems to be a consistent issue

inland root
#

Is that to say that these refunds shouldn't be created at all in these scenarios?

ripe iron
#

Exactly, no refunds should be made. It is like charging someone and then refunding them, only to charge them again. It should be allocating it to each user instead of refunding and recharging

inland root
#

Can you send me the ID of one of the apyments that you have seen this happen on?

#

I can check how it was made if you are unsure

#

Stripe does not initiate those refunds automatically as far as I am aware (with the possible exception of disputes) but I'd need to take a closer look at this specific payment to know

ripe iron
#

pm_1OXs2VKxwNRvD9vzjKyVVCb9

Here is the timeline:

Successfully refunded $100.00 due to customer request. It may take a few days for the money to reach the customer's bank account.
View details
Jan 22, 2024, 5:08 AM
$470.71 captured, and released the remaining $941.42 to the customer
Jan 19, 2024, 6:10 PM
This payment successfully set up pm_1OXs2VKxwNRvD9vzjKyVVCb9 for future off-session payments
Jan 19, 2024, 6:10 PM
Payment authorized
Jan 18, 2024, 6:06 PM
Payment started

#

This example might be better: pm_1ObA7aKxwNRvD9vzWrgBRYZs

I checked this one and there are no actual customer refunds on our end

#

Hopefully to further simplify what is going on:

We do an auth for $1000 and then a day later we only capture $250 since the client changed their mind
We want the other $750 to release with it being a refund.

Right now Stripe is treating it as a refund which we do not want since it was never captured

inland root
#

Ah thank you for the example. It looks like what happened here is that you placed a hold for $132 but only captured some of that. So the refund was for the uncaptured funds
https://dashboard.stripe.com/logs/req_x6jdooiMD4qJ7X
Also for future reference, I was actually looking for a payment intent ID (pi_1234), pm_ IDs are for payment methods which there can be multiple payments for. So the ID that would have been easier to find this info from was pi_3ObA7aKxwNRvD9vz2sjd2HCt

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

#

Apologies, I did not realize that that was how we represent what happens to a hold's unused funds

ripe iron
#

Ahh, sorry I'll do that next time. Thank you. Yeah it makes payouts strange

#

Is there anything we can change on our end to change this behavior to avoid it being represented as a refund?

inland root
#

Not as far as I am aware from the API perspective at least. Our support team may know if you have another option here but I am not confident we would have this as a dashboard setting either unfortunately https://support.stripe.com/?contact=true

Stripe: Help & Support

Find help and support for Stripe. Our support site provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.