# `Stripe.Resources.Capability.Requirements`
[🔗](https://github.com/jeffhuen/tiger_stripe/blob/main/lib/stripe/resources/capability.ex#L120)

Nested struct within the parent resource.

# `t`

```elixir
@type t() :: %Stripe.Resources.Capability.Requirements{
  alternatives:
    [Stripe.Resources.Capability.Requirements.Alternatives.t()] | nil,
  current_deadline: integer() | nil,
  currently_due: [String.t()] | nil,
  disabled_reason: String.t() | nil,
  errors: [Stripe.Resources.Capability.Requirements.Errors.t()] | nil,
  eventually_due: [String.t()] | nil,
  past_due: [String.t()] | nil,
  pending_verification: [String.t()] | nil
}
```

* `alternatives` - Fields that are due and can be resolved by providing the corresponding alternative fields instead. Multiple alternatives can reference the same `original_fields_due`. When this happens, any of these alternatives can serve as a pathway for attempting to resolve the fields. Additionally, providing `original_fields_due` again also serves as a pathway for attempting to resolve the fields. Nullable.
* `current_deadline` - The date by which all required account information must be both submitted and verified. This includes fields listed in `currently_due` as well as those in `pending_verification`. If any required information is missing or unverified by this date, the account may be disabled. Note that `current_deadline` may change if additional `currently_due` requirements are requested. Format: Unix timestamp. Nullable.
* `currently_due` - Fields that need to be resolved to keep the capability enabled. If not resolved by `current_deadline`, these fields will appear in `past_due` as well, and the capability is disabled.
* `disabled_reason` - Description of why the capability is disabled. [Learn more about handling verification issues](https://docs.stripe.com/connect/handling-api-verification). Possible values: `other`, `paused.inactivity`, `pending.onboarding`, `pending.review`, `platform_disabled`, `platform_paused`, `rejected.inactivity`, `rejected.other`, `rejected.unsupported_business`, `requirements.fields_needed`. Nullable.
* `errors` - Details about validation and verification failures for `due` requirements that must be resolved.
* `eventually_due` - Fields you must collect when all thresholds are reached. As they become required, they appear in `currently_due` as well, and `current_deadline` becomes set.
* `past_due` - Fields that haven't been resolved by `current_deadline`. These fields need to be resolved to enable the capability on the account.
* `pending_verification` - Fields that are being reviewed, or might become required depending on the results of a review. If the review fails, these fields can move to `eventually_due`, `currently_due`, `past_due` or `alternatives`. Fields might appear in `eventually_due`, `currently_due`, `past_due` or `alternatives` and in `pending_verification` if one verification fails but another is still pending.

---

*Consult [api-reference.md](api-reference.md) for complete listing*
