#codedmart-connect
fair sigil
@humble atlas I don't quite follow what a 'single use token" is. Can you share some code or API object IDs of what you do in that flow to help me understand?
my assumption is you mean you clone the card details to a connected account to charge(https://stripe.com/docs/connect/cloning-customers-across-accounts) ? but that is only for cards and not bank accounts(I assume you mean ACH debit), so I need a lot more clarity
humble atlas
Currently we call /tokens with either the card id or bank account id and the connected stripe account in the header. That does not work with ach credit transfer.
This is what we are doing: https://stripe.com/docs/connect/cloning-customers-across-accounts#creating-tokens
fair sigil
it doesn't work with anything except cards, yes
I'm surprised to hear it works with ACH Debit bank accounts(I really didn't think it did) but maybe there's a nuance I'm missing
so with that said you only have two options here
- continue doing Direct Charges by creating the ACH CT sources on the connected accounts and interacting with them there.
- for ACH CT , move to a Destination Charge model where you process the ACH CT payment on your platform and then transfer the funds to the connected account.
The first option probably makes more sense.
We don't want to copy payment methods over to our connected stripe accounts
unfortunately you have to (if by that you mean, creating the ACH CT Source on the connected account).
humble atlas
Hmm... 🤔. So there is nothing that works like single use tokens then?
Creating the ACH CT on the connected account will not work well for our use case. We are trying to only provide one source of ACH CT for our customers. If we create those on connected accounts they will then have multiple account numbers to remember.
Well not remember, but to wire money to which will provide more confusion.
So with that said our only option is if I am understanding correctly:
- for ACH CT , move to a Destination Charge model where you process the ACH CT payment on your platform and then transfer the funds to the connected account.
fair sigil
yep, that's all true!
we only support copying card details from one account to another(that's what cloning/single use tokens are doing), there's too much other context with other payment methods tied directly to the merchant account(like with ACH CT, the virtual bank account number and stuff) so we don't support moving them
so the only options are creating the Source on the connected account(as you say, can be messy if you want your platform customer to be a source of truth), or do the ACH CT payment on your platform and when it succeeds, transfer the funds to the connected account with an internal Stripe transfer with the /v1/transfers API
humble atlas
Is there any legal considerations here about how the money flows in this scenario?
fair sigil
I'm an engineer so I can't really answer that! the main thing is to understand the liability for refunds is on your platform in that scenario since you are the one interacting with the end-customer, and that cross-border transfers are generally blocked
remote bobcat
👋 @humble atlas
humble atlas
Oh thanks
So I am reading the docs. The goal just to follow up is to not have to save our customers payment methods on the connected accounts.
So https://stripe.com/docs/api/payment_intents/create if we pass the payment_method (ie the whole object) explicitly but not use setup_future_usage would that work?
The other thing I was thinking with using transfers if we went that route is what the impact would be to the connected accounts payout timeline.
remote bobcat
Sorry, what is your goal here exactly?
and what do you mean by passing the complete payment method object (rather than an id)?
humble atlas
So https://stripe.com/docs/api/payment_intents/create if we pass the `payment_me...
So we have been using the old /charges api with cards and bank_accounts. With that we use /token to generate (clone) single use of that card or bank account to process a payment on the connected account. Now we have added ach_credit_transfer but the create /token route does not work with ach_credit_transfer.
Yeah basically fetching the payment method from our account and passing that?
I assume it wouldn't work that way, but wanted to ask.
We just don't want to create/save the payment method's of the customers on our platform in the connected accounts.
remote bobcat
Yea, as Karl said the cloning/sharing is only supported for cards currently, for other payment methods you need to tokenize/colelct details using the account that will be taking payment
humble atlas
That is not true we use it with bank_account have been for months.
And it still works for us.
When you say tokenize/collect you mean recollect the information from the customer? Or I can fetch the payment method object from our stripe account and use that?
remote bobcat
I mean when you collect the details (typically via Stripe.js/Elements), its needs to be done such that the objects are created in the stripe account where you'll later create the payment
humble atlas
Well that is the thing this section of the code is from the backend. So not interacting with stripe.js. By this point these have already gone through that process and our just saved in our stripe account. So with that is us charging and transfers out only option?
Does that add to the payout days for the connected account?
I thought I tested all this and it was working too 🙁.
remote bobcat
Yes, if saved on your platform your use either destination charges or separate transfers to your connected account when taking payment using payment methods saved on your platform
The same pending time for a payment would apply if you used a destination payment, yes.
humble atlas
Sorry what does destination payment mean?
Direct payment is on the connected account right?
remote bobcat
Yes, a direct charge is a payment you create directly on the (standard) connected account: https://stripe.com/docs/connect/direct-charges
Destination payments are created on your platform with some or all of the payment ending up in a connected (custom or express) account: https://stripe.com/docs/connect/destination-charges
humble atlas
OK so doing a destination charge and creating a transfer does not increase the number of days a connected account will receive the money in their account/payout?
But in this case we also have to worry about refunds and stripe fees differently it seems.
humble atlas
And this is the only way to have one source of ACH CT right? Meaning we want our customers to only have one acct/routing number to wire funds to. If we create the ACH CT on each connected account those would be different per account. Am I getting this right?
Also do you know if https://stripe.com/docs/payments/us-bank-account applies the same here? Or could we use this with tokens?
remote bobcat
That's right, yes, those would be set up per account, and is at least part of why sharing isn't supported
humble atlas
Just want to be totally sure does that apply to this question as well:
Also do you know if https://stripe.com/docs/payments/us-bank-account applies the same here? Or could we use this with tokens?
Sorry for all the questions and restating some. Just want to be sure I fully understand.
All you help is very much appreciated.
remote bobcat
Just want to be totally sure does that apply to this question as well:
> Also do...
Correct, sharing/cloning is also not supported with the new bank account payment method integration as far as i know
humble atlas
OK thanks for your time.
remote bobcat
NP!