Stripe.Resources.Capability.FutureRequirements (tiger_stripe v0.1.10)

Copy Markdown View Source

Nested struct within the parent resource.

Summary

Types

t()

Types

t()

@type t() :: %Stripe.Resources.Capability.FutureRequirements{
  alternatives:
    [Stripe.Resources.Capability.FutureRequirements.Alternatives.t()] | nil,
  current_deadline: integer() | nil,
  currently_due: [String.t()] | nil,
  disabled_reason: String.t() | nil,
  errors: [Stripe.Resources.Capability.FutureRequirements.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 - Date on which future_requirements becomes the main requirements hash and future_requirements becomes empty. After the transition, currently_due requirements may immediately become past_due, but the account may also be given a grace period depending on the capability's enablement state prior to transitioning. Format: Unix timestamp. Nullable.
  • currently_due - Fields that need to be resolved to keep the capability enabled. If not resolved by future_requirements[current_deadline], these fields will transition to the main requirements hash.
  • disabled_reason - This is typed as an enum for consistency with requirements.disabled_reason, but it safe to assume future_requirements.disabled_reason is null because fields in future_requirements will never disable the account. 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.
  • past_due - Fields that haven't been resolved by requirements.current_deadline. These fields need to be resolved to enable the capability on the account. future_requirements.past_due is a subset of requirements.past_due.
  • 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.