#50an6xy06r6n

1 messages · Page 1 of 1 (latest)

broken windBOT
valid slate
#

are you trying to do this and encountering some kind of error?

#

Can you share a concrete example ba_123/pm_123 and what you're trying to do?

oblique warren
#

seti_1M3vLZJoa4Az1hv22b8g9jze/pm_1M3vOYJoa4Az1hv2aZXFPpgz

#

adding a bank account via the manual verification flow

#

attempting to detach the payment method from the account while in this state doesn't seem to remove it

raven token
#

Hi there! Just stepping in for my colleague and catching up

oblique warren
#

np

raven token
#

Ah, I found the failed attempt to detach. The request failed since the PaymentMethod isn't attached to a customer yet

oblique warren
#

it shows up as attached in the console though

#

or at least associated

#

is there a way to cancel the setupintent or something

#

also where can I find the failed attempt to detach? I don't see it on my end

raven token
oblique warren
#

ah ok i see there's a way to just cancel a setupintent

#

that would remove it from the console?

raven token
#

Oh, I see I was wrong. The detach request is for a different PaymentMethod altogether

oblique warren
#

there's likely to be a bunch of them because I've been cycling through a flow on our end

raven token
#

It's similar though: these are PaymentMethods that were collected as part of a SetupIntent but not yet attached to a customer

#

Got it

oblique warren
#

ok new question: why does the verification page show a successful verification when I enter the testing value for a timeout?

#

evt_1M4A1mJoa4Az1hv2KBQ6KlBN

raven token
#

Ah, looks like this is expected albeit a bit confusing. The SM44DD code is meant to simulate a 10-day timeout, so an error won't be showed to the end customer on this screen

oblique warren
#

why is that?

raven token
#

That's just the way it was built for this specific test case: banks taking some time to actually fail the verification

#

listening to the setup_intent.setup_failed event in this case is the correct way to test for this

oblique warren
#

I see.

raven token
#

since you'll receive this event if the microdeposit fails at a future date

oblique warren
#

yeah I'm handling the failed case but I was hoping to not have to display that error case to the user

raven token
#

ah I see

#

You'll need to in this case since you'll need the customer to provide new bank account details

oblique warren
#

yeah right now I'm just resetting to the new setup intent state

#

ok hopefully last question here: If we get a payment_method_microdeposit_verification_attempts_exceeded that means the bank account can't be used anymore?

#

will there be any stripe api error on future attempts?

#

also, does a timeout count as a failure?

#

oh also the page says that you get 10 attempts but the documentation says it's 3

raven token
#

what do you mean by 'failure' with regards to the timeout?

#

the SetupIntent status will change to requires_payment_method and will still be in a state that is not canceled

#

which documentation mentions the number of attempts?

oblique warren
raven token
#

Are you referring to this paragraph?

Verification attempts have a limit of three failures. If you exceed this limit, we can no longer verify the bank account. In addition, microdeposit verifications have a timeout of 10 days. If you can’t verify microdeposits in that time, the PaymentIntent reverts to requiring new payment method details. Clear messaging about what these microdeposits are and how you use them can help your customers avoid verification issues.