StripeAPI.Types.PaymentIntent

amount: Amount intended to be collected by this PaymentIntent. A positive integer representing how much to charge in the smallest currency unit (e.g., 100 cents to charge $1.00 or 100 to charge ¥100, a zero-decimal currency). The minimum amount is $0.50 US or equivalent in charge currency. The amount value supports up to eight digits (e.g., a value of 99999999 for a USD charge of $999,999.99).

amount_capturable: Amount that can be captured from this PaymentIntent.

amount_details:

amount_received: Amount that was collected by this PaymentIntent.

application: ID of the Connect application that created the PaymentIntent.

application_fee_amount: The amount of the application fee (if any) that will be requested to be applied to the payment and transferred to the application owner's Stripe account. The amount of the application fee collected will be capped at the total payment amount. For more information, see the PaymentIntents use case for connected accounts.

automatic_payment_methods: Settings to configure compatible payment methods from the Stripe Dashboard

canceled_at: Populated when `status` is `canceled`, this is the time at which the PaymentIntent was canceled. Measured in seconds since the Unix epoch.

cancellation_reason: Reason for cancellation of this PaymentIntent, either user-provided (`duplicate`, `fraudulent`, `requested_by_customer`, or `abandoned`) or generated by Stripe internally (`failed_invoice`, `void_invoice`, or `automatic`).

capture_method: Controls when the funds will be captured from the customer's account.

charges: Charges that were created by this PaymentIntent, if any.

client_secret: The client secret of this PaymentIntent. Used for client-side retrieval using a publishable key.

The client secret can be used to complete a payment from your frontend. It should not be stored, logged, or exposed to anyone other than the customer. Make sure that you have TLS enabled on any page that includes the client secret.

Refer to our docs to accept a payment and learn about how `client_secret` should be handled.

Constraints:

• Maximum length of 5000

confirmation_method

created: Time at which the object was created. Measured in seconds since the Unix epoch.

currency: Three-letter ISO currency code, in lowercase. Must be a supported currency.

customer: ID of the Customer this PaymentIntent belongs to, if one exists.

Payment methods attached to other Customers cannot be used with this PaymentIntent.

If present in combination with setup_future_usage, this PaymentIntent's payment method will be attached to the Customer after the PaymentIntent has been confirmed and any required actions from the user are complete.

description: An arbitrary string attached to the object. Often useful for displaying to users.

Constraints:

• Maximum length of 5000

id: Unique identifier for the object.

Constraints:

• Maximum length of 5000

invoice: ID of the invoice that created this PaymentIntent, if it exists.

last_payment_error: The payment error encountered in the previous PaymentIntent confirmation. It will be cleared if the PaymentIntent is later updated for any reason.

livemode: Has the value `true` if the object exists in live mode or the value `false` if the object exists in test mode.

metadata: Set of key-value pairs that you can attach to an object. This can be useful for storing additional information about the object in a structured format. For more information, see the documentation.

next_action: If present, this property tells you what actions you need to take in order for your customer to fulfill a payment using the provided source.

on_behalf_of: The account (if any) for which the funds of the PaymentIntent are intended. See the PaymentIntents use case for connected accounts for details.

payment_method: ID of the payment method used in this PaymentIntent.

payment_method_options: Payment-method-specific configuration for this PaymentIntent.

payment_method_types: The list of payment method types (e.g. card) that this PaymentIntent is allowed to use.

processing: If present, this property tells you about the processing state of the payment.

receipt_email: Email address that the receipt for the resulting payment will be sent to. If `receipt_email` is specified for a payment in live mode, a receipt will be sent regardless of your email settings.

Constraints:

• Maximum length of 5000

review: ID of the review associated with this PaymentIntent, if any.

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

shipping: Shipping information for this PaymentIntent.

statement_descriptor: For non-card charges, you can use this value as the complete description that appears on your customers’ statements. Must contain at least one letter, maximum 22 characters.

Constraints:

• Maximum length of 5000

statement_descriptor_suffix: Provides information about a card payment that customers see on their statements. Concatenated with the prefix (shortened descriptor) or statement descriptor that’s set on the account to form the complete statement descriptor. Maximum 22 characters for the concatenated descriptor.

Constraints:

• Maximum length of 5000

status: Status of this PaymentIntent, one of `requires_payment_method`, `requires_confirmation`, `requires_action`, `processing`, `requires_capture`, `canceled`, or `succeeded`. Read more about each PaymentIntent status.

transfer_data: The data with which to automatically create a Transfer when the payment is finalized. See the PaymentIntents use case for connected accounts for details.

transfer_group: A string that identifies the resulting payment as part of a group. See the PaymentIntents use case for connected accounts for details.

Constraints:

• Maximum length of 5000

enabled: Automatically calculates compatible payment methods

data: This list only contains the latest charge, even if there were previously multiple unsuccessful charges. To view all previous charges for a PaymentIntent, you can filter the charges list using the `payment_intent` parameter.

has_more: True if this list has another page of items after this one that can be fetched.

url: The URL where this list can be accessed.

Constraints:

• Maximum length of 5000

charge: For card errors, the ID of the failed charge.

Constraints:

• Maximum length of 5000

code: For some errors that could be handled programmatically, a short string indicating the error code reported.

Constraints:

• Maximum length of 5000

decline_code: For card errors resulting from a card issuer decline, a short string indicating the card issuer's reason for the decline if they provide one.

Constraints:

• Maximum length of 5000

doc_url: A URL to more information about the error code reported.

Constraints:

• Maximum length of 5000

message: A human-readable message providing more details about the error. For card errors, these messages can be shown to your users.

Constraints:

• Maximum length of 40000

param: If the error is parameter-specific, the parameter related to the error. For example, you can use this to display a message near the correct form field.

Constraints:

• Maximum length of 5000

payment_intent: A PaymentIntent guides you through the process of collecting a payment from your customer. We recommend that you create exactly one PaymentIntent for each order or customer session in your system. You can reference the PaymentIntent later to see the history of payment attempts for a particular session.

A PaymentIntent transitions through multiple statuses throughout its lifetime as it interfaces with Stripe.js to perform authentication flows and ultimately creates at most one successful charge.

Related guide: Payment Intents API.

payment_method: PaymentMethod objects represent your customer's payment instruments. You can use them with PaymentIntents to collect payments or save them to Customer objects to store instrument details for future payments.

Related guides: Payment Methods and More Payment Scenarios.

payment_method_type: If the error is specific to the type of payment method, the payment method type that had a problem. This field is only populated for invoice-related errors.

Constraints:

• Maximum length of 5000

setup_intent: A SetupIntent guides you through the process of setting up and saving a customer's payment credentials for future payments. For example, you could use a SetupIntent to set up and save your customer's card without immediately collecting a payment. Later, you can use PaymentIntents to drive the payment flow.

Create a SetupIntent as soon as you're ready to collect your customer's payment credentials. Do not maintain long-lived, unconfirmed SetupIntents as they may no longer be valid. The SetupIntent then transitions through multiple statuses as it guides you through the setup process.

Successful SetupIntents result in payment credentials that are optimized for future payments. For example, cardholders in certain regions may need to be run through Strong Customer Authentication at the time of payment method collection in order to streamline later off-session payments. If the SetupIntent is used with a Customer, upon success, it will automatically attach the resulting payment method to that Customer. We recommend using SetupIntents or setup_future_usage on PaymentIntents to save payment methods in order to prevent saving invalid or unoptimized payment methods.

By using SetupIntents, you ensure that your customers experience the minimum set of required friction, even as regulations change over time.

Related guide: Setup Intents API.

source: The source object for errors returned on a request involving a source.

type: The type of error returned. One of `api_error`, `card_error`, `idempotency_error`, or `invalid_request_error`

account: The ID of the account that the bank account is associated with.

account_holder_name: The name of the person or business that owns the bank account.

Constraints:

• Maximum length of 5000

account_holder_type: The type of entity that holds the account. This can be either `individual` or `company`.

Constraints:

• Maximum length of 5000

account_type: The bank account type. This can only be `checking` or `savings` in most countries. In Japan, this can only be `futsu` or `toza`.

Constraints:

• Maximum length of 5000

ach_credit_transfer

ach_debit

acss_debit

address_city: City/District/Suburb/Town/Village.

Constraints:

• Maximum length of 5000

address_country: Billing address country, if provided when creating card.

Constraints:

• Maximum length of 5000

address_line1: Address line 1 (Street address/PO Box/Company name).

Constraints:

• Maximum length of 5000

address_line1_check: If `address_line1` was provided, results of the check: `pass`, `fail`, `unavailable`, or `unchecked`.

Constraints:

• Maximum length of 5000

address_line2: Address line 2 (Apartment/Suite/Unit/Building).

Constraints:

• Maximum length of 5000

address_state: State/County/Province/Region.

Constraints:

• Maximum length of 5000

address_zip: ZIP or postal code.

Constraints:

• Maximum length of 5000

address_zip_check: If `address_zip` was provided, results of the check: `pass`, `fail`, `unavailable`, or `unchecked`.

Constraints:

• Maximum length of 5000

alipay

amount: A positive integer in the smallest currency unit (that is, 100 cents for $1.00, or 1 for ¥1, Japanese Yen being a zero-decimal currency) representing the total amount associated with the source. This is the amount for which the source will be chargeable once ready. Required for `single_use` sources.

au_becs_debit

available_payout_methods: A set of available payout methods for this bank account. Only values from this set should be passed as the `method` when creating a payout.

bancontact

bank_name: Name of the bank associated with the routing number (e.g., `WELLS FARGO`).

Constraints:

• Maximum length of 5000

brand: Card brand. Can be `American Express`, `Diners Club`, `Discover`, `JCB`, `MasterCard`, `UnionPay`, `Visa`, or `Unknown`.

Constraints:

• Maximum length of 5000

card

card_present

client_secret: The client secret of the source. Used for client-side retrieval using a publishable key.

Constraints:

• Maximum length of 5000

code_verification:

country: Two-letter ISO code representing the country the bank account is located in.

Constraints:

• Maximum length of 5000

created: Time at which the object was created. Measured in seconds since the Unix epoch.

currency: Three-letter ISO code for the currency paid out to the bank account.

customer: The ID of the customer that the bank account is associated with.

cvc_check: If a CVC was provided, results of the check: `pass`, `fail`, `unavailable`, or `unchecked`. A result of unchecked indicates that CVC was provided but hasn't been checked yet. Checks are typically performed when attaching a card to a Customer object, or when creating a charge. For more details, see Check if a card is valid without a charge.

Constraints:

• Maximum length of 5000

default_for_currency: Whether this bank account is the default external account for its currency.

dynamic_last4: (For tokenized numbers only.) The last four digits of the device account number.

Constraints:

• Maximum length of 5000

eps

exp_month: Two-digit number representing the card's expiration month.

exp_year: Four-digit number representing the card's expiration year.

fingerprint: Uniquely identifies this particular bank account. You can use this attribute to check whether two bank accounts are the same.

Constraints:

• Maximum length of 5000

flow: The authentication `flow` of the source. `flow` is one of `redirect`, `receiver`, `code_verification`, `none`.

Constraints:

• Maximum length of 5000

funding: Card funding type. Can be `credit`, `debit`, `prepaid`, or `unknown`.

Constraints:

• Maximum length of 5000

giropay

id: Unique identifier for the object.

Constraints:

• Maximum length of 5000

ideal

klarna

last4: The last four digits of the bank account number.

Constraints:

• Maximum length of 5000

livemode: Has the value `true` if the object exists in live mode or the value `false` if the object exists in test mode.

metadata: Set of key-value pairs that you can attach to an object. This can be useful for storing additional information about the object in a structured format.

multibanco

name: Cardholder name.

Constraints:

• Maximum length of 5000

object: String representing the object's type. Objects of the same type share the same value.

owner: Information about the owner of the payment instrument that may be used or required by particular source types.

p24

receiver:

recipient: The recipient that this card belongs to. This attribute will not be in the card object if the card belongs to a customer or account instead.

redirect:

routing_number: The routing transit number for the bank account.

Constraints:

• Maximum length of 5000

sepa_debit

sofort

source_order:

statement_descriptor: Extra information about a source. This will appear on your customer's statement every time you charge the source.

Constraints:

• Maximum length of 5000

status: For bank accounts, possible values are `new`, `validated`, `verified`, `verification_failed`, or `errored`. A bank account that hasn't had any activity or validation performed is `new`. If Stripe can determine that the bank account exists, its status will be `validated`. Note that there often isn’t enough information to know (e.g., for smaller credit unions), and the validation is not always run. If customer bank account verification has succeeded, the bank account status will be `verified`. If the verification failed for any reason, such as microdeposit failure, the status will be `verification_failed`. If a transfer sent to this bank account fails, we'll set the status to `errored` and will not continue to send transfers until the bank details are updated.

For external accounts, possible values are `new` and `errored`. Validations aren't run against external accounts because they're only used for payouts. This means the other statuses don't apply. If a transfer fails, the status is set to `errored` and transfers are stopped until account details are updated.

Constraints:

• Maximum length of 5000

three_d_secure

tokenization_method: If the card number is tokenized, this is the method that was used. Can be `android_pay` (includes Google Pay), `apple_pay`, `masterpass`, `visa_checkout`, or null.

Constraints:

• Maximum length of 5000

type: The `type` of the source. The `type` is a payment method, one of `ach_credit_transfer`, `ach_debit`, `alipay`, `bancontact`, `card`, `card_present`, `eps`, `giropay`, `ideal`, `multibanco`, `klarna`, `p24`, `sepa_debit`, `sofort`, `three_d_secure`, or `wechat`. An additional hash is included on the source with a name matching this value. It contains additional information specific to the payment method used.

usage: Either `reusable` or `single_use`. Whether this source should be reusable or not. Some source types may or may not be reusable by construction, while others may leave the option at creation. If an incompatible value is passed, an error will be returned.

Constraints:

• Maximum length of 5000

wechat

address: Owner's address.

email: Owner's email address.

Constraints:

• Maximum length of 5000

name: Owner's full name.

Constraints:

• Maximum length of 5000

phone: Owner's phone number (including extension).

Constraints:

• Maximum length of 5000

verified_address: Verified owner's address. Verified values are verified or provided by the payment method directly (and if supported) at the time of authorization or settlement. They cannot be set or mutated.

verified_email: Verified owner's email address. Verified values are verified or provided by the payment method directly (and if supported) at the time of authorization or settlement. They cannot be set or mutated.

Constraints:

• Maximum length of 5000

verified_name: Verified owner's full name. Verified values are verified or provided by the payment method directly (and if supported) at the time of authorization or settlement. They cannot be set or mutated.

Constraints:

• Maximum length of 5000

verified_phone: Verified owner's phone number (including extension). Verified values are verified or provided by the payment method directly (and if supported) at the time of authorization or settlement. They cannot be set or mutated.

Constraints:

• Maximum length of 5000

city: City, district, suburb, town, or village.

Constraints:

• Maximum length of 5000

country: Two-letter country code (ISO 3166-1 alpha-2).

Constraints:

• Maximum length of 5000

line1: Address line 1 (e.g., street, PO Box, or company name).

Constraints:

• Maximum length of 5000

line2: Address line 2 (e.g., apartment, suite, unit, or building).

Constraints:

• Maximum length of 5000

postal_code: ZIP or postal code.

Constraints:

• Maximum length of 5000

state: State, county, province, or region.

Constraints:

• Maximum length of 5000

city: City, district, suburb, town, or village.

Constraints:

• Maximum length of 5000

country: Two-letter country code (ISO 3166-1 alpha-2).

Constraints:

• Maximum length of 5000

line1: Address line 1 (e.g., street, PO Box, or company name).

Constraints:

• Maximum length of 5000

line2: Address line 2 (e.g., apartment, suite, unit, or building).

Constraints:

• Maximum length of 5000

postal_code: ZIP or postal code.

Constraints:

• Maximum length of 5000

state: State, county, province, or region.

Constraints:

• Maximum length of 5000

alipay_handle_redirect:

boleto_display_details:

card_await_notification:

display_bank_transfer_instructions:

konbini_display_details:

oxxo_display_details:

paynow_display_qr_code:

promptpay_display_qr_code:

redirect_to_url:

type: Type of the next action to perform, one of `redirect_to_url`, `use_stripe_sdk`, `alipay_handle_redirect`, `oxxo_display_details`, or `verify_with_microdeposits`.

Constraints:

• Maximum length of 5000

use_stripe_sdk: When confirming a PaymentIntent with Stripe.js, Stripe.js depends on the contents of this dictionary to invoke authentication flows. The shape of the contents is subject to change and is only intended to be used by Stripe.js.

verify_with_microdeposits:

wechat_pay_display_qr_code:

wechat_pay_redirect_to_android_app:

wechat_pay_redirect_to_ios_app:

acss_debit

affirm

afterpay_clearpay

alipay

au_becs_debit

bacs_debit

bancontact

boleto

card

card_present

customer_balance

eps

fpx

giropay

grabpay

ideal

interac_present

klarna

konbini

link

oxxo

p24

paynow

promptpay

sepa_debit

sofort

us_bank_account

wechat_pay

capture_method: Controls when the funds will be captured from the customer's account.

mandate_options:

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

verification_method: Bank account verification method.

capture_method: Controls when the funds will be captured from the customer's account.

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

verification_method: Bank account verification method.

capture_method: Controls when the funds will be captured from the customer's account.

reference: Order identifier shown to the customer in Afterpay’s online portal. We recommend using a value that helps you answer any questions a customer might have about the payment. The identifier is limited to 128 characters and may contain only letters, digits, underscores, backslashes and dashes.

Constraints:

• Maximum length of 5000

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

verification_method: Bank account verification method.

capture_method: Controls when the funds will be captured from the customer's account.

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

verification_method: Bank account verification method.

capture_method: Controls when the funds will be captured from the customer's account.

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

verification_method: Bank account verification method.

capture_method: Controls when the funds will be captured from the customer's account.

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

verification_method: Bank account verification method.

capture_method: Controls when the funds will be captured from the customer's account.

preferred_language: Preferred language of the Bancontact authorization page that the customer is redirected to.

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

verification_method: Bank account verification method.

capture_method: Controls when the funds will be captured from the customer's account.

expires_after_days: The number of calendar days before a Boleto voucher expires. For example, if you create a Boleto voucher on Monday and you set expires_after_days to 2, the Boleto voucher will expire on Wednesday at 23:59 America/Sao_Paulo time.

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

verification_method: Bank account verification method.

capture_method: Controls when the funds will be captured from the customer's account.

installments: Installment details for this payment (Mexico only).

For more information, see the installments integration guide.

mandate_options: Configuration options for setting up an eMandate for cards issued in India.

network: Selected network to process this payment intent on. Depends on the available networks of the card attached to the payment intent. Can be only set confirm-time.

request_three_d_secure: We strongly recommend that you rely on our SCA Engine to automatically prompt your customers for authentication based on risk level and other requirements. However, if you wish to request 3D Secure based on logic from your own fraud engine, provide this option. Permitted values include: `automatic` or `any`. If not provided, defaults to `automatic`. Read our guide on manually requesting 3D Secure for more information on how this configuration interacts with Radar and our SCA Engine.

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

statement_descriptor_suffix_kana: Provides information about a card payment that customers see on their statements. Concatenated with the Kana prefix (shortened Kana descriptor) or Kana statement descriptor that’s set on the account to form the complete statement descriptor. Maximum 22 characters. On card statements, the *concatenation* of both prefix and suffix (including separators) will appear truncated to 22 characters.

Constraints:

• Maximum length of 5000

statement_descriptor_suffix_kanji: Provides information about a card payment that customers see on their statements. Concatenated with the Kanji prefix (shortened Kanji descriptor) or Kanji statement descriptor that’s set on the account to form the complete statement descriptor. Maximum 17 characters. On card statements, the *concatenation* of both prefix and suffix (including separators) will appear truncated to 17 characters.

Constraints:

• Maximum length of 5000

verification_method: Bank account verification method.

available_plans: Installment plans that may be selected for this PaymentIntent.

enabled: Whether Installments are enabled for this PaymentIntent.

plan: Installment plan selected for this PaymentIntent.

count: For `fixed_count` installment plans, this is the number of installment payments your customer will make to their credit card.

interval: For `fixed_count` installment plans, this is the interval between installment payments your customer will make to their credit card. One of `month`.

type: Type of installment plan, one of `fixed_count`.

amount: Amount to be charged for future payments.

amount_type: One of `fixed` or `maximum`. If `fixed`, the `amount` param refers to the exact amount to be charged in future payments. If `maximum`, the amount charged can be up to the value passed for the `amount` param.

description: A description of the mandate or subscription that is meant to be displayed to the customer.

Constraints:

• Maximum length of 200

end_date: End date of the mandate or subscription. If not provided, the mandate will be active until canceled. If provided, end date should be after start date.

interval: Specifies payment frequency. One of `day`, `week`, `month`, `year`, or `sporadic`.

interval_count: The number of intervals between payments. For example, `interval=month` and `interval_count=3` indicates one payment every three months. Maximum of one year interval allowed (1 year, 12 months, or 52 weeks). This parameter is optional when `interval=sporadic`.

reference: Unique identifier for the mandate or subscription.

Constraints:

• Maximum length of 80

start_date: Start date of the mandate or subscription. Start date should not be lesser than yesterday.

supported_types: Specifies the type of mandates supported. Possible values are `india`.

capture_method: Controls when the funds will be captured from the customer's account.

request_extended_authorization: Request ability to capture this payment beyond the standard authorization validity window

request_incremental_authorization_support: Request ability to increment this PaymentIntent if the combination of MCC and card brand is eligible. Check incremental_authorization_supported in the Confirm response to verify support.

setup_future_usage: Indicates that you intend to make future payments with this PaymentIntent's payment method.

Providing this parameter will attach the payment method to the PaymentIntent's Customer, if present, after the PaymentIntent is confirmed and any required actions from the user are complete. If no Customer was provided, the payment method can still be attached to a Customer after the transaction completes.

When processing card payments, Stripe also uses `setup_future_usage` to dynamically optimize your payment flow and comply with regional legislation and network rules, such as SCA.

verification_method: Bank account verification method.