#atanas
distant moon
karmic bone
Hi 👋 sounds like you're working on setting up a flow with Connect, have you already selected the type of charges and accounts that you plan to use and if so can you share that?
charred pulsar
Yes we are using connect - Up until now we've only had credit cards enabled, but we'll be moving towards a model where we're going to allow both CC and ACH. I'm not quite sure which details you'd like, but when creating a PI we set the following fields,
on_behalf_of: stripeAccountId
application_fee_amount: someAmount
transfer_data: {
destination: stripeAccountId,
},
Generally once a PI is created, we save the ID and retrieve it on any further attempts. The total amount does not change, and by saving a specific PI we use it a source of truth in the interim period between webhooks arriving.
karmic bone
Alright, so it looks like you're using our destination charges approach [0]. With that approach, there is not a way to adjust the application_fee_amount after the payment is made, so you would need a way to determine the type of payment method that your customer would like to use before processing the payment. The Payment Intents that you're using shouldn't be exposed to multiple customers simultaneously, which avoids that race condition that you mentioned.
Another approach, but please keep in mind this is not a small undertaking, is to switch from "destination charges" to "separate charges and transfers". With the latter you manually create the Transfers to your connected accounts after payment, but doing so allows you to inspect the type of payment method that was used and adjust how much you transfer accordingly.
https://stripe.com/docs/connect/charges-transfers
charred pulsar
Oh interesting, we'll definitely take a look at that. As far as not exposing the PI to multiple customers, I don't see a way around it. Each "item" being paid is unique, and can be paid for by any relevant user. It can only be paid once, and cannot have its amount change. We have stringent checks in place to ensure that no double payments of any kind can happen. We could potentially "lock" things such that if one user is in checkout mode, another one can't be, but decided that that is a worse option. Since we save and retrieve a PI once created, there's no risk there as far as we can see (I know the idempotencyKey only lasts for 24 hours).
karmic bone
Ah interesting, it sounds like you're using the Payment Intent as a way of managing inventory limits, and I believe it's the first time I've seen such an approach. You will need to be very cognizant of race conditions throughout your flow with that approach.