#CodyL

1 messages · Page 1 of 1 (latest)

slim magnetBOT
tulip surge
#

Hello, can you tell me a bit about the behavioral bug you are seeing here?

rich jungle
#

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

tulip surge
#

Are you using SetupIntents here? SetupIntents are stateful so you should be able to check their status to see if they have succeeded

rich jungle
#

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

tulip surge
#

So you can look that up backwards for PMs you have already tried to migrate this way

rich jungle
#

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

tulip surge
#

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?

rich jungle
#

Right, this is the problem

#

I didn't create those payment methods

tulip surge
#

Do you have an example Payment Method ID that was created this way?

rich jungle
#

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)

tulip surge
#

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

rich jungle
#

correct

#

second one was migrated with a setup intent

#

seti_1LtupeKUbaLgbekLnnLiBQvk

#

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

tulip surge
#

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?

rich jungle
#

but I don't have any proof of that.

tulip surge
#

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

rich jungle
#

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)

tulip surge
#

So was some SetupIntent created for ba_1LtuREKUbaLgbekLh01ZWJEl but it failed here?

rich jungle
#

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

tulip surge
#

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.

rich jungle
#

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

tulip surge
#

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.

rich jungle
#

right, maybe there is an underlying reason

tulip surge
#

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?

rich jungle
#

but maybe it is just an oversight 🙂

tulip surge
#

I can grab the email and get back to you

rich jungle
#

will do. I'll dm it to you shortly

tulip surge
#

Thank you. I am also interested to see if this is intentional or oversight

rich jungle
#

thanks. I have a larger google doc that explains the issue that I'll include in the email

tulip surge
#

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?

rich jungle
#

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

tulip surge
#

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

rich jungle
#

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

rich jungle
#

can you let me know if you are able to find it?

tulip surge
#

Grabbed it, thank you