#taylorcooney
half atlas
Can you share a request id where this error happened?
crude wing
@half atlas Here is the request in test mode, req_rJfafxE0RxFYEL, and here is the request in live mode, req_4gSqLzfmHEhS4h
half atlas
Ok. Make sure Bank Transfer is enabled in your live mode payment method settings
For Connect Requests as well
crude wing
The Bank Transfer payment method is not enabled for test mode, so why would the SetupIntents work in test mode and not in live mode?
It is extremely concerning why this is working in test mode. It becomes virtually imposible to build an integration if a different response is returned in the test mode and the live mode...
I would expect to have gotten the same error message in test mode
half atlas
Sorry I mispoke us_bank_account is the ach direct debit payment method not bank transfer payment method
crude wing
Thanks @half atlas, but my point and question still remain; us_bank_account is not enabled for test mode, so why would the SetupIntents work in test mode and not in live mode?
I would expect to have gotten the same error message in test mode
half atlas
Hm not sure. Juggling too many threads at the moment. Let me ask a colleague
crude wing
Do you understand how it becomes nearly imposible to build an integration if a different response is returned in the test mode and the live mode?
floral abyss
Yes and that is why we try to keep behavior as close as possible between the environments. I will raise this as appropriate once we've determined the cause
crude wing
Thanks @floral abyss, just to fully understand, should I expect a response back here shortly?
floral abyss
Apologies that took a bit. It looks like this is a live vs test mode difference. Basically we don't enforce payment method capabilities in test mode, so you'll need to request the us_bank_account_ach_payments capability on this connected account in order to enable it to save and charge ACH DD payment methods https://stripe.com/docs/connect/account-capabilities#requesting-unrequesting
One question I have is if you have a specific reason for using our direct charges flow with these Custom accounts. Direct charges can cause difficulty with disputes, handling negative balances, and a couple of other things. So we typically recommend using our Destination charges flow for Custom connect accounts like yours, where the payment intent is created on the platform and funds are automatically transferred to the connect account.
crude wing
We are in the process of transitioning, but we've been held up for the past nine (9) days while we tried to figure out why a different response was being returned in test mode and live mode
"Basically we don't enforce payment method capabilities in test mode"
Seems like the above goes against the prior sentiment of trying to keep behavior as close as possible between the environments
Is there a reason that payment method capabilities aren't enforced in test mode, @floral abyss?
floral abyss
I'm not privvy to why that decision was made unfortunately. We do strive to keep behavior as close as possible, not sure why this difference exists.
But it does, so we have to work with it here. Any info I can give you to help move forward on enabling your accounts to take ACH payments?
Also to be clear, direct vs destination is a separate thing from transitioning to the PaymentMethods API
crude wing
Yes, I'm aware. Was more touching on your previous question re: specific reason for using direct charges flow
floral abyss
So on top of moving to Intents, you also plan to move these charges to your platform account?
crude wing
The specific reason is because examples used in the documention on Stripe is unclear; it states that if you're using a similar model as Shopify then to use Direct Charges
floral abyss
Do you know what doc you saw that in?
crude wing
"An e-commerce platform like Shopify or Squarespace"
Would be great to have better alingment between what Stripe employees recommend, and the documentation
It's not only confusing but frustrating having to explain why we are on Direct Charges so many times. Why do we use them? Well, look at what your docs recommend
floral abyss
Yep, I see that that doc talks about account type being part of the decision later but it could be made clearer up at the top of the doc as well
crude wing
Yup. Would be nice to see that made clear one day. I'm sure it would save a lot of other companies from this headache
crude wing
But it does, so we have to work with it here. Any info I can give you to help mo...
Nope, nothing on that front. I'm familiar with how to enable the different payment methods. I was most concerned about the different responses as the expected behaviour would be to have gotten the same error message in test mode
floral abyss
Gotcha, apologies the docs and test mode behavior have been frustrating. Any further questions at the moment?
crude wing
Do you know how the on_behalf_of parameter on SetupIntents might factor into this transition from Direct to Destination Charges?
carmine epochBOT
floral abyss
Yes, on_behalf_of specifies the merchant of record for the payment. If specified, your connected account would show up on the bank statement for the charge. It also affects a couple Stripe side things like how currency conversion works when settling funds. We talk about it more here https://stripe.com/docs/connect/destination-charges#settlement-merchant
crude wing
This mainly models PaymentIntents, but I see that the on_behalf_of parameter is also for SetupIntents
floral abyss
Yep, you will want to use on_behalf_of for your ACH setup intents, that also affects the ACH mandate
crude wing
Is there any infomation about how specify that on a SetupIntent affects anything on Stripe side?
Okay -- and how are we to test this exactly?
Seems like I can make calls with or without the on_behalf_of parameter and get the same outcome in test mode
floral abyss
For the SetupIntent confirm? That makes sense as you should be able to set the mandate up for either account
The errors would come about for PaymentIntents if you do or don't have a mandate for the right account
Let me double check how that works
crude wing
The errors would come about for PaymentIntents if you do or don't have a mandate...
Yeah, again, I'm not seeing that enforced in test mode which is the entire crux of this issue
It sounds as though we're being recommended to figure it out in live mode
floral abyss
For PaymentIntents you are not seeing errors based on mandates?
No, mandates are enforced in test mode
I may have been mistaken about how they apply then. Like I said, double checking how they work.
crude wing
For PaymentIntents I am not seeing errors based on mandates that were made without the on_behalf_of parameter for the SetupIntent
floral abyss
Can you send me the ID of a successful payment intent like that?
crude wing
In other words, you make a SetupIntent and skip on_behalf_of and then when you make the PaymentIntent and specify on_behalf_of everything works fine
Sure, let me pull that information for you
floral abyss
From our docs it sounds like that may be expected, I think there may be another bank debit payment method that I was confusing this with. I will consult my colleagues on this.
https://stripe.com/docs/payments/ach-debit#payment-method-and-mandate-cloning
crude wing
From the docs, it sounds like that is not expected when you read your linked article:
"You can’t use a mandate authorized for a PaymentIntent or SetupIntent on_behalf_of of a connected account with a different connected account."
floral abyss
"connected account" both times is the key, your platform isn't a connected account.
I think that this would be more like the cloning scenario above, but that doesn't directly apply to your situation, so I want to confirm the same cloning applies with on_behalf_of payments.
Okay confirmed how this works:
If you create a mandate without OBO, that mandate is for your platform account and its PaymentMethod can be used for charges on the platform or OBO the connected account.
If you create the mandate with OBO, the mandate is for that connected account specifically, the PaymentMethod can only be used for that account, not for the platform account or other connected accounts.
Except for some reason the OBO mandate is not erroring for me now either for the platform or other connected accounts.
My apologies, looks like a few things need correcting here. I think I need to file with the eng team to figure out how this works. Would you mind writing an email in to support so I can follow up with you?
crude wing
I'm expericing the same thing re: OBO mandate not erroring, so in terms of transitioning previously collected Bank Account objects to the PaymentMethods API and moving towards Destination charges flow for Custom connect accounts it's unclear how to proceed.
Do we create a mandate for previously collected Bank Account objects without OBO so that the PaymentMethod can be used for the platform?
crude wing
My apologies, looks like a few things need correcting here. I think I need to fi...
I wrote a detailed case into support nine (9) days ago and haven't heard back. We are at a standstill in terms of next steps for migration so I've now had to turn to other support channels, such as Discord
I've also had to email our account manager re: the delayed response and they are also "looking into it"
Adam escalated this support case 12 minutes ago. A new team is taking a look now.
I just don't understand how a company can operate like this. Are we doing something so unique with our integration that nobody knows how to support this?
floral abyss
I'm honestly surprised at how many sharp edges we've run in to just today with this chat. I've helped other users with this kind of ACH migration and with destination charges. They are well supported and understood flows usually.
Sorry to hear about your support experience. Unfortunately I cannot push on that case, but I can get back to you quickly on the OBO angle if you write in to support so I can grab the email.
crude wing
I've got to step away for a bit. Been at this for over two hours and need a break
floral abyss
Alright I have filed about this internally and will make sure to follow up to calrify and fix the relevant docs. If you want a follow up on how OBO works with mandates, please write another quick support email and DM me your email address
carmine epochBOT
crude wing
Thanks @floral abyss -- I'm now learning that ACH records stored as payment method objects can’t be copied over [0] which causes a conflict with us trying to migrate bank account payment information to use with the Payment Intents API [1].
[0] https://stripe.com/docs/payments/account/data-migrations/pan-copy-self-serve?copy-method=partial-customer-selection#data-considerations
[1] https://stripe.com/docs/payments/ach-debit/migrations#bank-accounts-api
Going to need to look into this more now as all of the stuff we previously discussed is useless if the bank account object isn't copied over
somber island
👋 Pompey had to head out, so I'm hopping in
Are you asking about data migrations, or are you asking about cloning payments using connect?
crude wing
I'm asking about data migrations, as it pertains to this conversation and the transition to Destination Charges
Why are the bank accounts not being copied over? They are stored as Sources
somber island
Sorry let me be really clear- when I say data migrations I'm talking about Bank Accounts that you need stripe to manually copy over for you to another account. Are you instead referring to https://stripe.com/docs/payments/ach-debit/migrations#bank-accounts-api (migrating from using the Bank Accounts API to using Payment methods)?
crude wing
No, I'm referring to Bank Accounts that need to be copied over for us from another account. This should be self-serve https://stripe.com/docs/payments/account/data-migrations/pan-copy-self-serve
The documents are extremely unclear. Can you please look into this for me @somber island?
somber island
If you're talking about data migrations then you're right, ACH records stored as PMs can't be copied over
crude wing
But they are saved as sources
`stripe_customer.source = payment_method_id
stripe_customer.save
response = stripe_customer.sources.retrieve(stripe_customer.default_source)`
It even fires a customer.source.updated webhook event when verifying the microdeposits
somber island
From what I understand, BankAccount objects (with no mandate) would be copied over, but PaymentMethod objects representing ACH accounts wouldn't
So if you were already working with BankAccount sources then those should be copied over
somber island
What do you mean that they aren't copied over? That the migrations team never moved them to another account?
crude wing
The data migrations is not involved here. This is a self-serve feature
Please check this article that I shared earlier https://stripe.com/docs/payments/account/data-migrations/pan-copy-self-serve
And I'm not sure how to elaborate on the fact that the bank accounts aren't copied over
Like...they are not copied over. It's very black and white to me
somber island
I understand what you're saying and I know it's frustrating, but this is purely a data migrations issue and that team needs to look into for you. Your Account Manager needs to be pushing on them on your behalf and askng why the self-serve migration didn't behave as you expected