yan014

[naive zinc]

hi! hmm, well there's not really a native way.

I would just do a Destination Charge using Connect and send the 1000 to the connected account, and then on the platform you keep the remaining 300(minus Stripe fees) and mark with metadata or other accounting that it represents two separate 'things'

unless you're willing to process multiple separate PaymentIntents/Charges against the customer's payment method(which is not a good idea anyway due to increased risk of declines etc ), you can't create 3 separate transaction objects in the API in the way you describe

[dull spruce]

For the 1st, yes, that's what we tried, but it didn't meet our accounting expectations.

For the 2nd, yes we had imagined going through setup intents and making 3 transactions on it, are you talking about the same thing?

[naive zinc]

1 fair enough
2 something like that yes. But it's a bad idea I think since doing e.g. 3 separate charges against the same card all immediately together in the same minute has the possibility of looking like fraud etc to the customer's bank, so usually you prefer to batch payments. But it's an option

[dull spruce]

Yes, we also thought it might be a problem.

No other option unless the first so ?

[naive zinc]

I can't think of one no

[dull spruce]

for the 1st solution, what do you mean by " or other accounting that it represents two separate 'things'"

What other things could there be?

[naive zinc]

like an entry in your database outside of Stripe that says "payment pi_xxx connects to these two different rows in my Transactions table"

or adding metadata:{orderID:"123456"} to the PaymentIntent, and in your database you have a breakdown of multiple line items and transaction details for an 'order' with that ID, in your business logic

[dull spruce]

Okay thanks yes something besides Stripe