zperkins

[quasi bay]

Depending on what you use for onboarding (e.g. OAuth versus Account Links) you might be able to specify that you want to collect eventually_due, which will prompt the user for all the verification info possible: https://stripe.com/docs/api/account_links/create#create_account_link-collect

That being said, you still need to build a system that monitors requirements and re-prompts the user for them, as these aren't always perfectly linear. For example: often when an account has processed $3k, Stripe will ask for more verification info. So you'll want to set yourself up to monitor for that type of thing

[torn totem]

Hi! Appreciate the response.

Yes, we're set up with webhooks to monitor for requirement changes and we currently notify users when this occurs in real time. However, we are concerned based on this documentation that this solution might not work long term, as we're only monitoring the requirements hash, not the future_requirements hash.

If a requirement were to exist in future_requirements.currently_due, then immediately transition into requirements.past_due, this would be an issue because our users accounts would be disabled with no notice. However, if we can't use onboarding to collect future requirements, there's no point in monitoring future_requirements because it won't work anyways.

The solution of specifying eventually_due, by my understanding, only works to collect requirements.eventually_due, and not future_requirements.currently_due. I'm not entirely clear what the difference is between what gets put into which category, but I am aware that they are separate.

Let me know if this makes sense, thanks!