#mattcomroe_api
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1389954052254601267
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Actually, I think i might have just answered my own question. It looks likie the "confirm" call is what causes the descriptor_code. I see that here: req_Y3BoxIfsE8fdqP
Hi there ๐ I don't think we have any resource that provides insight into when we are likely to use two amount-based deposits vs one description-based deposit.
Ah, are you looking to understand which verification approach is being used after the intent has been confirmed? (I read your initial question as looking for insight in general about which flow a customer is likely to see)
If so, yes, you're on the right path. The next_action hash will show you the type of microdeposit being used, so you can advise your customer about what they should be looking for and provide to you.
Hi toby! no, you were right the first time. I'm trying to understand behind the scenes which verification method is likely to be first used under which circumstances.
i know two amounts is the fallback, but i don't know when descriptor code is attempted.
i think it's when .confirm() is called on either a setupintent or payment intent for a new us_bank_account payment type
Gotcha, I'm not seeing anywhere we expose that insight currently, and I don't have it myself either. Can you help me understand how that would benefit you, so I can file feedback with our teams to have them consider documenting this?
this is purely from a testing standpoint so we can test both flows. i'm just adding support for the descriptor_code verification in our application now, so I want to be able to give test cases to QA of how to try both types of verification.
Hm, I'm not sure how strictly we enforce the microdeposit verification in testmode. Are you seeing an error when you try to use amounts to do microdeposit verification there?
no; in test mode it looks like it allows me to use either type of verification even if the next_action hash is telling me that it's descriptor_code. That's ok; i am working on logic that looks at that next_action to see which type of form we should be showing the user.
i think i have what i need, toby! thank you for the help and I hope you have a great rest of your day!