#tobewisebeforeiamold_code

1 messages ยท Page 1 of 1 (latest)

bright coralBOT
#

๐Ÿ‘‹ 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.

โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1488949555838849367

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

empty iron
#

Here's a py_1THRmaD6h2U84xyAX2BpPl0U that is a destination_payment that was created using a payment_intent that had on_behalf_of set that has no customer, and here's the pi_3THROEDYgrK1cJzV2qETRfZF that started it

rustic orchid
#

hi there

#

So you're trying to persist the cus_123 id from the PaymentIntent on the platform onto the destination payment on the connected account that the payment is on behalf of, right?

empty iron
#

Basically. The ID doesn't need to be the same, but the name/email should be. This is to support an embeeded app from you guys.

#

<ConnectAppViewport app='com.example.acodeistripeapp' />

rustic orchid
#

Let me see what's possible here. I find this flow difficult to work with in a lot of ways

empty iron
#

They tell me they can only see the payment to the connect account, and that has customer: null, even with on_behalf_of

Let me see what's possible here
Thanks!
I find this flow difficult to work with in a lot of ways
Interesting! Which flow is that? Not using a checkout session?

rustic orchid
#

Destination Charges, because you have a mix of objects on two Stripe accounts that you're concerned with and there are some links between them, but lots of objects aren't connected, and things that exist on the Platform only exist on the platform and same for the connected account

#

though you can access things on the connected account using Stripe-Account header on requests

empty iron
#

Ya, that make sense to me as well. When I tried to do it via the webhook and looked at https://docs.stripe.com/stripe-apps/embedded-apps it looked like I needed to create a new customer on the connect account and update the source charge maybe to have the connect account customer? But if the same customer makes two payments then am I creating two customers with the same email on the connect account? So I'd need to first try to find the customer and use that, otherwise create...but the documentation for on_behalf_of seemed to indicate that Stripe would do that for me...

#

But maybe that's what I have to do?

  1. listen for charge.succeeded
  2. look for customers in the connect account matching the email address of the platform customer
    • if found, update the platform charge to have the connect account customer?
    • otherwise make a new customer in the connect account, and again update the platform charge to have the new connect account customer?
#

And then I'd have to figure out the flow for refunds and disputes...how I would have to swap customers manually between platform and connect account customers?

rustic orchid
#

Sorry for the delay there

empty iron
#

No worries! I always have something to occupy myself, however good or bad that may be ๐Ÿ˜„

rustic orchid
#

Okay, so I think you have to do this via webhooks - probably you want to listen for the payment.created event on your Connect webhook endpoint and then update that with the information you need after tying it to the PaymentIntent/Charge on the platform. If you want you can create a Customer with the same information on the connected account and update the destination payment with that Customer

#

Or you could just update the destination payment's metadata