#CodyL
1 messages · Page 1 of 1 (latest)
Hello, can you tell me a bit about the behavioral bug you are seeing here?
Sure. We are a company (Phone Company) that bills our customers each month for their service with many thousands of those occuring via ACH Debit. We are working to migrate out existing customers to the Payment Method API. As such we have many thousands of "Sources" bank accounts
I can see how the migration process is supposed to work, but it in practice it is not possible to know if a legacy bank account has been successfully migrated to the payments method api
This is because the payment method looks the same before and after it is migrated
It would seem that there should be a way to tell if there is a mandate attached to the payment method
but there is not
that would indicate that it has been migrated.
I worked though this migration quite a bit last year but was stalled but another bug which has since been resolved. At that time the bank account was not retured by the payment method until it had been migrated
Are you using SetupIntents here? SetupIntents are stateful so you should be able to check their status to see if they have succeeded
I guess my point is by querying the customer object
and looking at the resouces
it is not clear if I can use the payment method or not yet
You can list SetupIntents by customer or by payment method ID https://stripe.com/docs/api/setup_intents/list
So you can look that up backwards for PMs you have already tried to migrate this way
for ones going forward it is clear since the payment method has a different id prefix
but not for ones using migrated legacy bank accounts
I really should not have to look though and match setup intents to see if a payment method is valid
the payment method should only be created if the setup intent was successful
in that case
I'm still trying to line up your process with what I see in the docs. How are you creating these new payment methods with the SetupIntent but without confirming it?
Do you have an example Payment Method ID that was created this way?
they are a view of existing "sources" bank accounts
ba_1LtuREKUbaLgbekLh01ZWJEl
and yeah, it is confusing because it has a ba_prefix
the real problem is that this payment method while returned by the payment methods api is not usable
because it does not have a mandate
but it is also not possible to know that looking at the payment method
ba_1LtuVtKUbaLgbekLAtKS0RVz is an example of a legacy bank account which has been migrated
but it is also not possible to know what just by looking at the results of the payment methods api
if the payment method api returned the mandate id that would be enough to solve this
I think this is really just an oversight and I would be glad to talk to the team around this api and migration. I realize that this is a niche bit and not a ton of customers are doing lots of recurring ACH (or they haven't attempted migrating existing sources yet)
And the second one has been migrated with a SetupIntent?
Thank you for the clarification. I am still looking to see if we have something for this. Mandates can be annoying API wise but I thought there was an easier way to check if they've been migrated here
correct
second one was migrated with a setup intent
seti_1LtupeKUbaLgbekLnnLiBQvk
yeah the issue is just looking at the results of https://api.stripe.com/v1/customers/cus_MdArz0W2E5rjoX/payment_methods?type=us_bank_account it is not possible to know if the payment method is valid (in that it has a mandate)
I don't think it is an issue for newly created us_bank_Accounts as they won't get created as a payment_method until it the setup_intent succedes
but for these legacy where they report as a payment method before actually going through the setup intenet process to get a mandate it is an issue
Back in april I don't think they returned though the payment method api until they had gone through the setup intent
Yeah, I think I am understanding your situation better now. And out of curiosity, do you have the info to create these offline mandates for all of your real payment methods?
but I don't have any proof of that.
That kind of change sounds familiar, will check in to that too after looking in to the main state/mandate question.
Also as a quick question, I do see that you are setting metadata with migrated: true , is that something that you have happen automatically based on a webhook? That is a potential workaround I was thinking of if there isn't a good way to check this API-wise
All of the existing accounts were presented with the mandate langauge over the years on the website when they added their bank accounts.
the migrated=true is something I was playing around with this morning as a possible workaround
but it really feels wrong
but doesn't feel like something I should be having to set in the metadata
if the setup intent is successful and returns a payment method
final SetupIntent result = SetupIntent.create(setupIntent.build());
log.infof("Setup Intent %s -> %s status %s", result.getId(), result.getPaymentMethod(), result.getStatus());
PaymentMethod.retrieve(result.getPaymentMethod()).update(PaymentMethodUpdateParams.builder().putMetadata("migrated", "true").build());
(java)
So was some SetupIntent created for ba_1LtuREKUbaLgbekLh01ZWJEl but it failed here?
No I haven't done a setup intenet for ba_1LtuREKUbaLgbekLh01ZWJEl
I left that one just as a legacy bank account source
to show that it looks the same as a migrated one
from an API perspective
I really seems problematic that an invalid payment method returns from the payment method list
with no way to know that it isn't valid
I think that is the crux of the issue
invalid meaning it hasn't going through the seutp intent process yet and has no mandate
it just needs some indication that it is valid or has a mandate or whatever.
then we would know what to do with it
don't expect this to be resolved today. just trying to get the ball rolling
Yeah, still looking. If I don't see anything on this I can definitely create a feature request but I can't promise if/when this will be added. In that case it honestly may be best to include your own metadata indicator in the meantime.
Yeah, seems like once you know which PM needs to be migrated, you can just create and confirm the setupintent instantly so that is easy, but the issue is checking which have already been migrated.
yeah I mean we can move forward with that, but I would like to get some explanation on how they expect it to work from my perspective.
Feels like a hole and I get that those who haven't had to migrate their own may not have seen it
or maybe I'm wildly missing something
which would point to docs that need to be improved
but would like to see you guys get this nailed down correct
Yeah either way I think we need this to be specified in our docs. I'm also not immediately thinking of a reason that this works this way but sometimes there are constraints that make this kind of thing make sense.
right, maybe there is an underlying reason
I think I might need more time to look and reach out to colleagues here. Would you mind sending an email to us via https://support.stripe.com/?contact=true and then DMing me your email address?
Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.
but maybe it is just an oversight 🙂
I can grab the email and get back to you
will do. I'll dm it to you shortly
Thank you. I am also interested to see if this is intentional or oversight
thanks. I have a larger google doc that explains the issue that I'll include in the email
Awesome thank you
Also out of curiosity, is there a reason you can't "just" list existing bank accounts that were created before you started using the new API and just create a SetupIntent for each of those?
well we also have 20-30 accounts that will be in vertification process at any time
I suppose those could be upgraded after verification
Of course there are ways around it, but it doesn't seem clean right now
and going to be an ongoing point of frustration for those migrating
Ah thank you. Yeah those could be messy to handle in that case.
So yeah DM me once you've sent something in. I will clarify with colleagues what the intended path is and will get back to you
My migration plan was a little less big bang and more upgrading the customers over the month as they made payment
anyway I'll be in touch after I send the email
can you let me know if you are able to find it?
Grabbed it, thank you