#esset-capability-requirements

1 messages · Page 1 of 1 (latest)

stuck quailBOT
deft grove
#

There isn't a straight-forward answer to that as that field can contain a string pointing to any required field on the Account or Person object that needs to be completed.

real fossil
#

As in a path to an account property?

#

Could you provide 1-2 examples?

deft grove
#

Some examples can be seen in the example Capability object on the right side of the page that you linked to.

real fossil
#

so, it could be something like "company.address" (if there's a verification issue with the company address)?

#

What I'm trying to do is figure out why some capability is missing.. perhaps requirements.errors is better ?

#

As I intepret things; the requirement.errors gives a description of the problem, and currently_due points to the specific fields?

deft grove
#

No, if there is a problem with an address there will be an additional reference pointing to the part of the address that has issues (or multiple pointers if more than one part of the address is problematic).

For instance, below are a couple of the address fields from the sample object:

    "alternatives": [],
    "current_deadline": null,
    "currently_due": [
      "business_profile.product_description",
      "business_profile.url",
      "individual.address.city",
      "individual.address.line1",
      "individual.address.postal_code",
      "individual.dob.day",
      "individual.dob.month",
      "individual.dob.year",```
#

requirements.disabled_reason I believe will be a better field for identifying why a capability is disabled, and errors is better for getting specifics about what is wrong with a provided input.

real fossil
#

OK, so if there's a "disabled_reason", will there also be one or more requirements.errors?

#

Follow-up;

What does "Disabled" refer to? That the Account is disabled?

#

... and is that the state of the account if it fails the 1st KYC check, and an additional document is needed (e.g. to verify someone's SSN)?

deft grove
#

Excerpt from our API spec regarding what disabled_reason represents:

If the capability is disabled, this string describes why. Can be requirements.past_due, requirements.pending_verification, listed, platform_paused, rejected.fraud, rejected.listed, rejected.terms_of_service, rejected.other, under_review, or other.
rejected.unsupported_business means that the account’s business is not supported by the capability. For example, payment methods may restrict the businesses they support in their terms of service:

Afterpay Clearpay’s terms of service
If you believe that the rejection is in error, please contact support at https://support.stripe.com/contact/ for assistance.
This is on the Capability object, so just because this capability is disabled doesn't necessarily mean the Account is.

If you're trying to get an idea of the current state of the Account, then charges_enabled and payouts_enabled give you a good grasp of whether the Account can process payments and payouts.
https://stripe.com/docs/api/accounts/object#account_object-charges_enabled

So maybe we should take a step back. Are you working on this because of a particular scenario that occurred that you're trying to guard against, or what is that you're trying to have this process accomplish?

real fossil
#

Thank you, that helps. I think it's the mix of "disabled" and "inactive" that made it a bit confusing.

#

I'll outline the steps to help you get the context

#
  1. We create custom connect accounts using the API
  2. We upload KYC documents we already have (from an existing KYC process) to increase chances of a speedy approval with Stripe

After (2), we need to display a state to our users (whether their Connect account is ready).

To do this, we check the capabilities we require (card_payments + transfers). If both are "active", all is good.

If both are not "active" because of KYC issues, we want to let the user know and create an AccountLink they can use to fix the issues.

#

I was assuming that there's a state where the capabilities may not be active, but no action is (yet) required from the user. E.g. when Stripe is reviewing the already provided documents.

Is this true? If so, what's the best way to identify that state based on the Account object?

#

... it sounds like the best way is to just look if "requirements.errors" has any items (?)

obsidian swift
#

esset-capability-requirements

deft grove
real fossil
#

OK, thanks. Is "pending" the value when Stripe is performing some kind of review, e.g. it's "pending a decision from Stripe"?

And "inactive" when it's been rejected, and there's an error to resolve?

obsidian swift
#

pending means we're in the process of verifying the info. It will then switch to active or inactive (or rejected) after that

#

and yes inactive usually means that requirements would list details about what's blocking it from being active

real fossil
#

OK, thanks, that helps. Then I think it's enough for us to just check if any capability = inactive, and in that case share an AccountLink with our users.

obsidian swift
#

I think so yes

real fossil
#

Alright, last question (I think): for how long is an AccountLink valid? Can it be configured?

obsidian swift
#

those are only valid a few minutes and one-time use

real fossil
#

thanks

#

bye!