#justin.mcmanus-clone-bankaccount
obsidian cosmos
req_H9Mc3JoVLZX7ui and req_hdja4HEGxUpJEa are a couple of examples
I considered updating the setup intent call to pass in payment_method_data for us_bank_account but I'm not sure why that would be necessary, and also it has the downside of creating a new payment method, I believe, but I've already cloned the payment method using the method described in the cloning payment methods doc, which is supposed to work for cards and us_bank_accounts
cerulean elbow
looking
taking a step back, what doc are you following? and what integration are you building?
at first I thought you were just doing US bank account payments but you might be doing something else?
obsidian cosmos
I need to use a connect account for my subscriptions. I'm cloning customer payment methods to that connect account. This works for card payment methods, but I get the error I mentioned for us_bank_account payment methods.
I'm creating a setup intent as described in these docs, to attach the cloned payment method to the customer. This is the part that fails for us_bank_account payment methods
https://stripe.com/docs/api/payment_methods/attach
https://stripe.com/docs/api/setup_intents/create
elfin flax
@obsidian cosmos I'm quite confused here. Why are you passing flow_directions. Like which doc are you following that tells you to do that?
Overall the problem is that your connected account does not have https://stripe.com/docs/api/accounts/update#update_account-capabilities-us_bank_account_ach_payments set
obsidian cosmos
I don't know the answer to that one actually. Might've gotten that from somewhere random / or copy/paste. Is that the problem?
Ok, let me try that.
Looking at the doc, I think we do want flow direction inbound since this is intended only for payments for customer subscriptions. Is it recommended not to use that param?
elfin flax
no reason to use that param + you're missing the capability.
Also if you use Custom accounts, there's absolutely no reason to do anyo of what you are doing really
Everything should happen in the platform account
obsidian cosmos
This is a weird use case. It's a requirement that we segregate funds for our subscriptions, so we're doing direct charges on the connect accounts, and automatic payouts from those to siphon off the subscription revenue
elfin flax
This is likely a misunderstanding still, you can do that with Subscriptions on the platform still and it would make a drastically easier integration.
But yeah overall remove that param + add the capability and it should work
obsidian cosmos
Oh, really?? We haven't launched this yet. Would appreciate input on how to make this work leaving the subscriptions on the platform, while still being able to segregate the funds. It has turned into a pretty complicated integration.
We're currently creating the products / prices / subscriptions on the connect account, and needing to maintain a mapping of customer ids between the platform and connect account to make this all work.
elfin flax
being able to segregate the funds
the problem is that those words mean completely different things to people in general. With a destination charge, funds flow from the platform to the connected account synchronously and don't touch your balance directly (other than paying the Stripe fee and taking a cut if you want)
obsidian cosmos
yeah that's what we want here. So we could do this all on the platform account (subscription config / payment / etc), but with destination charges to push the funds to the connected account?
🤦♂️ Dang that simplifies things a lot: https://stripe.com/docs/connect/destination-charges
elfin flax
You likely also will want on_behalf_of to make the connected account the merchant of record. This exists but is in "beta". You likely have a contact at Stripe though so ask them to give you access to it
and make sure to chat through the flow of funds and that it fits your requirement