#deepumi_connect-refund

1 messages · Page 1 of 1 (latest)

deep sigilBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.

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

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

dusty badge
#

Your code is creating a Refund on a connected account but passing a Charge id ch_123 that exists on the platform so it's failing

#

deepumi_connect-refund

tawdry cosmos
#

I was sending without connected account previously for a different transaction, and I received the same error message.

dusty badge
#

I can only speak about that one request you gave details for really. Right now you are passing the connected account id and you should not so remove it and it will work

tawdry cosmos
#

for ex : req_tZc75GaXABrM7T

#

Can you check why this request was failing "req_tZc75GaXABrM7T"

dusty badge
#

That one is the complete opposite. You are refunding a Charge on the platform but that Charge was created on a connected account

#

Sorry you seem to be mixing up Connect entirely. Maybe you have multiple separate accounts with different integrations? Hard to say with just 2 request ids. But as the developer you should know which Stripe account a given Charge is created on

tawdry cosmos
#

Okay, so we have platform accounts and connected accounts.. And we have several connected accounts. And we always do the refund.

dusty badge
#

Really you, as the platform, need to know which account owns the Charge you are refunding. There's no way for us (Stripe) to magically know that.
If you are refunding Charge ch_1234 and it is created in the platform, then you refund it in the platform. If it's created on the connected account acct_ABC then you refund it on that connected account with the Stripe-Account header

tawdry cosmos
#

Transactions for the refunds are same approach. Platform gets the percentage and remaining $$ gets the connected account.

dusty badge
#

That's what you think, but that's not what happened to one of the two Charges and that's what got you all lost

tawdry cosmos
#

We have updated recently to the Payment API, and this might have created previously before using the payment API.

#

what is the best way to address this issue. Could you please tell me. May I am using the Payment Intent API incorrectly while creating the charge. Could you please confirm.

dusty badge
#

It's hard to say, you shared almost no information though. ?You just shared 2 request ids and they are all in Live mode.

tawdry cosmos
#

Could you tell me what information you required?

#

this is the connected a/c "acct_1KVeBxFJZnzXn3pb"

dusty badge
#

There are many different ways to integrate Stripe, especially with Stripe Connect. There are different flow of funds which change where and how the relevant payment objects (Charge/PaymentIntent) are created.
You are saying "my requests A fails and B fails differently and I changed things" but it's really vague and high level. Really what matters is where are the objects living.

Right now:

  • the first request you made tried to refund the Charge A that lives on the platform (where you created it) but told Stripe "refund it on the connected account". So that can't work
  • the second request you made tried to refund the Charge B that lives on the connected account (where you created it) but told Stripe "refund it on the platform". So that can't work either.

So you need to understand who creates the Charge, how the Charge is created, what the code does, which Stripe accounts owns the Charge, to be able to refund it.

In the first request (req_TFMzcJO6vE6XQO), the Charge was created 10 days ago in the platform using Destination Charges
In the second request (req_tZc75GaXABrM7T) the Charge was created yesterday using Direct Charges

Those flow of funds are completely different in the way funds flow between accounts, what objects are created and where they live.

tawdry cosmos
#

Could you share the API doc for these two transaction types. I apologize for the confusion, Previously I thing we used a different approach to send the transaction, now we are using PaymentIntent API.

#

How do I determine which one is a created using Destination Charge vs Direct charges?

dusty badge
#

How do I determine which one is a created using Destination Charge vs Direct charges?
You can't. You are supposed to know that upfront because you own code created that Charge and should know. It's unfortunately not possible to "know" after the fact easily.

tawdry cosmos
#

I believe we are using "Create direct charges" because of this "The payment appears as a charge on the connected account, not your platform’s account."

dusty badge
#

Maybe, but 10 days ago for the other Charge you were using Destination Charges

tawdry cosmos
#

We pushed the new code changes since May 19th 2024 which is using Payment Intent API. Sorry, but how do I fix this issue. Previously we were using "Create direct charges".
Would it be possible to switch back to "Create direct charges" via Payment Intent API?

dusty badge
#

You're using the wrong words unfortunately. You "switch back to direct charges" when clearly you already are doing Direct Charges with the most recent Charge.
Sorry it's really hard to help you, you seem a bit lost with your integration, the state of it and what type of flow you are really using unfortunately.

#

Charges and PaymentIntents work the same way and support the exact same flow of funds.

tawdry cosmos
#

Is it okay if I can get back to you later since I kind of understand little bit what you explained above?

#

I will do some investigation about the charge types.

dusty badge
#

Sure, but really right now the only issue is that you don't track what "type" of charge flow was used. You really need to track the exact account the Charge is created in, and once you do that, Refund will be easy

tawdry cosmos
#

Yes, I understood. Thank you, so much. Is it possible to take a print out of the chat conversation for my reference?

dusty badge
tawdry cosmos
#

matters

#

@dusty badge Could you please confirm the refund API endpoint is same for both type of charges?

dusty badge
#

yes it works the same way, what matters is passing the connected account id if the Charge was created on that account

tawdry cosmos
#

Okay got it.. Thank you again.