# Onboarding solutions for Custom accounts Choose the onboarding method for Custom accounts that suits your business. > #### Newer Connect integrations > > The information on this page applies only to platforms that already use legacy connected account types. For information about onboarding connected accounts, see [Choose your onboarding configuration](https://docs.stripe.com/connect/onboarding.md). Stripe offers several ways to onboard Custom connected accounts. You can choose the best onboarding method for your business. We recommend using Stripe-hosted onboarding or embedded onboarding components. Both automatically update to handle changing requirements when they apply to a connected account. With embedded components, you can [match them to your branding](https://docs.stripe.com/connect/customize-connect-embedded-components.md) and [control which policies and terms are shown](https://docs.stripe.com/connect/embedded-onboarding.md#customize-policies-shown-to-your-users). | Method | Pros | Cons | | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Stripe-hosted onboarding](https://docs.stripe.com/connect/custom/onboarding.md#stripe-hosted-onboarding) | - Lowest effort integration | - Stripe-branded with limited platform branding - Limited control over the flow logic - Connected accounts redirect to Stripe instead of completing the process without leaving your site | | [Embedded onboarding](https://docs.stripe.com/connect/custom/onboarding.md#embedded-onboarding) | - [Highly themeable](https://docs.stripe.com/connect/customize-connect-embedded-components.md) - Limited or no Stripe branding - Connected accounts remain in the flow of your site - Low effort integration | - Limited control over the flow logic | | [API-based onboarding](https://docs.stripe.com/connect/custom/onboarding.md#api-based-onboarding) | - Exercise full control over your own UI | - Expensive and time-consuming to build - Continuing high maintenance, especially to keep in compliance with changing global requirements - Can’t resolve Stripe risk reviews | ## Stripe hosted onboarding Stripe hosted onboarding allows you to redirect your user to Stripe to complete the onboarding process in a co-branded interface. Create an [Account Link](https://docs.stripe.com/api/account_links.md) and direct your user to the hosted onboarding flow. The [return_url](https://docs.stripe.com/api/account_links/create.md#create_account_link-return_url) allows Stripe to return the user to your application and allow you to progress the connected account accordingly. To integrate Stripe hosted onboarding, follow our [Stripe hosted onboarding guide](https://docs.stripe.com/connect/custom/hosted-onboarding.md). (See full diagram at https://docs.stripe.com/connect/custom/onboarding) ## Embedded onboarding Embedded onboarding is a highly themeable onboarding UI with limited Stripe branding. Connected account users interact with the embedded component without ever leaving your application. Embedded onboarding uses the [Accounts API](https://docs.stripe.com/api/accounts.md) to read the requirements and generate an onboarding form that is localized for all Stripe-supported countries and has robust data validation. In addition, embedded onboarding handles all: - Business types - Configurations of company representatives - Verification document uploading - Identify verification and statuses - International bank accounts - Error states You can integrate embedded onboarding with a few lines of code, whereas API-based onboarding requires you to construct custom logic. To integrate embedded onboarding, follow our [embedded components guide](https://docs.stripe.com/connect/get-started-connect-embedded-components.md) and integrate the [Account onboarding](https://docs.stripe.com/connect/supported-embedded-components/account-onboarding.md) embedded component. (See full diagram at https://docs.stripe.com/connect/custom/onboarding) Note: The following is a preview/demo component that behaves differently than live mode usage with real connected accounts. The actual component has more functionality than what might appear in this demo component. For example, for connected accounts without Stripe dashboard access (custom accounts), no user authentication is required in production. ## API-based onboarding API-based onboarding involves building out each aspect of your site’s onboarding user interface to call the corresponding Stripe APIs. Your integration must satisfy all of Stripe’s onboarding requirements. (See full diagram at https://docs.stripe.com/connect/custom/onboarding) ### Establish Requirements The following factors affect the [onboarding requirements](https://docs.stripe.com/connect/required-verification-information.md) for your connected accounts: - The origin country of the connected accounts - The [service agreement type](https://docs.stripe.com/connect/service-agreement-types.md) applicable to the connected accounts - The [capabilities](https://docs.stripe.com/connect/account-capabilities.md) requested for the connected accounts - The [business_type](https://docs.stripe.com/api/accounts/object.md#account_object-business_type) (for example, individual or company) and [company.structure](https://docs.stripe.com/api/accounts/object.md#account_object-company-structure) (for example, `public_corporation` or `private_partnership`) Use the [Required Verification Information](https://docs.stripe.com/connect/required-verification-information.md) tool to see how changing these factors affects the onboarding requirements for your connected accounts. ### Create forms to collect information As a best practice, organize the required parameters into logical groupings or forms in your onboarding flow. You might wish to encode a mapping between the Stripe parameters and the logical groupings. Suggested logical groupings for parameters are shown in the first column of the example requirements table. After you encode the required parameters into your application, generate UIs for the parameters corresponding to these requirements. For each parameter, design a UI form that includes: - Parameter label, localized to each supported country and language - Parameter description, localized to each supported country and language - Parameter input fields with data validation logic and document uploading where required It’s important to architect your application logic to account for the possibility of additional parameters in the future. For example, Stripe might introduce new parameters, new verifications, or new thresholds that you must incorporate into your onboarding flows over time. Changing any of the factors that determine your connected accounts requirements means you must also adjust your collection forms. [Country](https://docs.stripe.com/api/accounts/object.md#account_object-country) and [service agreement type](https://docs.stripe.com/api/accounts/object.md#account_object-tos_acceptance-service_agreement) are immutable, while [capabilities](https://docs.stripe.com/api/accounts/object.md#account_object-capabilities) and [business type](https://docs.stripe.com/api/accounts/object.md#account_object-business_type) are mutable. - To change an immutable field such as country or service agreement type, create a new connected account with the new values. Doing so produces new requirements for you to incorporate in your collection flows. - To change a mutable field such as capabilities or business type, update the connected account. Doing so produces new requirements for you to incorporate in your collection flows. ### Include Stripe Terms of Service Agreement Your connected accounts must accept Stripe terms of service before they can be activated. You can [wrap Stripe terms of service in your own terms of service](https://docs.stripe.com/connect/updating-service-agreements.md#adding-stripes-service-agreement-to-your-terms-of-service). ### Create the Connected Account Use the [Create Account](https://docs.stripe.com/api/accounts/create.md) API to create a connected account with country, service type agreement, desired capabilities, business type, and any other information matching your [requirements](https://docs.stripe.com/connect/custom/onboarding.md#establish-requirements). At a minimum, you must specify `capabilities` and `type`. If you don’t specify other parameters, they’re assigned the following default values: - The service type agreement (`tos_acceptance.service_agreement`) defaults to `full`. - The `country` defaults to the same country as your platform. The following code sample creates a Custom connected account with `card_payments` and `transfers` capabilities under a full service agreement for an individual. > This example includes only some of the fields you can set when creating an account. For a full list of the fields you can set, such as `address` and `website_url`, see the [Create Account API reference](https://docs.stripe.com/api/accounts/create.md). ```curl curl https://api.stripe.com/v1/accounts \ -u "<>:" \ -d country=US \ -d type=custom \ -d "capabilities[card_payments][requested]"=true \ -d "capabilities[transfers][requested]"=true ``` ```cli stripe accounts create \ --country=US \ --type=custom \ -d "capabilities[card_payments][requested]"=true \ -d "capabilities[transfers][requested]"=true ``` ```ruby # Set your secret key. Remember to switch to your live secret key in production. # See your keys here: https://dashboard.stripe.com/apikeys client = Stripe::StripeClient.new("<>") account = client.v1.accounts.create({ country: 'US', type: 'custom', capabilities: { card_payments: {requested: true}, transfers: {requested: true}, }, }) ``` ```python # Set your secret key. Remember to switch to your live secret key in production. # See your keys here: https://dashboard.stripe.com/apikeys client = StripeClient("<>") # For SDK versions 12.4.0 or lower, remove '.v1' from the following line. account = client.v1.accounts.create({ "country": "US", "type": "custom", "capabilities": { "card_payments": {"requested": True}, "transfers": {"requested": True}, }, }) ``` ```php // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys $stripe = new \Stripe\StripeClient('<>'); $account = $stripe->accounts->create([ 'country' => 'US', 'type' => 'custom', 'capabilities' => [ 'card_payments' => ['requested' => true], 'transfers' => ['requested' => true], ], ]); ``` ```java // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys StripeClient client = new StripeClient("<>"); AccountCreateParams params = AccountCreateParams.builder() .setCountry("US") .setType(AccountCreateParams.Type.CUSTOM) .setCapabilities( AccountCreateParams.Capabilities.builder() .setCardPayments( AccountCreateParams.Capabilities.CardPayments.builder() .setRequested(true) .build() ) .setTransfers( AccountCreateParams.Capabilities.Transfers.builder().setRequested(true).build() ) .build() ) .build(); // For SDK versions 29.4.0 or lower, remove '.v1()' from the following line. Account account = client.v1().accounts().create(params); ``` ```node // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys const stripe = require('stripe')('<>'); const account = await stripe.accounts.create({ country: 'US', type: 'custom', capabilities: { card_payments: { requested: true, }, transfers: { requested: true, }, }, }); ``` ```go // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys sc := stripe.NewClient("<>") params := &stripe.AccountCreateParams{ Country: stripe.String("US"), Type: stripe.String(stripe.AccountTypeCustom), Capabilities: &stripe.AccountCreateCapabilitiesParams{ CardPayments: &stripe.AccountCreateCapabilitiesCardPaymentsParams{ Requested: stripe.Bool(true), }, Transfers: &stripe.AccountCreateCapabilitiesTransfersParams{ Requested: stripe.Bool(true), }, }, } result, err := sc.V1Accounts.Create(context.TODO(), params) ``` ```dotnet // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys var options = new AccountCreateOptions { Country = "US", Type = "custom", Capabilities = new AccountCapabilitiesOptions { CardPayments = new AccountCapabilitiesCardPaymentsOptions { Requested = true }, Transfers = new AccountCapabilitiesTransfersOptions { Requested = true }, }, }; var client = new StripeClient("<>"); var service = client.V1.Accounts; Account account = service.Create(options); ``` ### Take your account through the onboarding flow You can enable connected accounts in either of two ways: - Incremental onboarding strategy: Collect the minimum [required information](https://docs.stripe.com/connect/custom/onboarding.md#establish-requirements) up front and the rest later - Upfront onboarding strategy: Collect all information up front The incremental onboarding strategy speeds up initial onboarding but requires additional information collection later on. The upfront onboarding strategy minimizes enablement disruption throughout the connected account’s lifecycle at the expense of a lengthier application process. You can decide which strategy better suits your use case. To implement your onboarding strategy, inspect the requirements hash of the connected account you created. The requirements hash provides a complete list of parameters you must collect to activate the connected account. - If you choose the incremental onboarding strategy, inspect the `currently_due` field in the requirements hash and build an onboarding flow that only collects for the listed parameters. - If you choose the upfront onboarding strategy, inspect the `eventually_due` field in the requirements hash and build an onboarding flow that collects for all the listed parameters. ```json { ... "requirements": { "alternatives": [], "current_deadline": null, "currently_due": [ "business_profile.product_description", "business_profile.support_phone", "business_profile.url", "external_account", "tos_acceptance.date", "tos_acceptance.ip" ], "disabled_reason": "requirements.past_due", "errors": [],"eventually_due": [ "business_profile.product_description", "business_profile.support_phone", "business_profile.url", "external_account", "tos_acceptance.date", "tos_acceptance.ip" ], "past_due": [], "pending_verification": [] }, ... } ``` ### Update the connected account Update the connected account object with new information as it progresses through your onboarding flow. Perform an [Update Account](https://docs.stripe.com/api/accounts/update.md) call, identifying the connected account by the `id` value you stored earlier. ```curl curl https://api.stripe.com/v1/accounts/{{CONNECTEDACCOUNT_ID}} \ -u "<>:" \ --data-urlencode "business_profile[url]"="https://furever.dev" \ -d "tos_acceptance[date]"=1609798905 \ -d "tos_acceptance[ip]"="8.8.8.8" ``` ```cli stripe accounts update {{CONNECTEDACCOUNT_ID}} \ -d "business_profile[url]"="https://furever.dev" \ -d "tos_acceptance[date]"=1609798905 \ -d "tos_acceptance[ip]"="8.8.8.8" ``` ```ruby # Set your secret key. Remember to switch to your live secret key in production. # See your keys here: https://dashboard.stripe.com/apikeys client = Stripe::StripeClient.new("<>") account = client.v1.accounts.update( '{{CONNECTEDACCOUNT_ID}}', { business_profile: {url: 'https://furever.dev'}, tos_acceptance: { date: 1609798905, ip: '8.8.8.8', }, }, ) ``` ```python # Set your secret key. Remember to switch to your live secret key in production. # See your keys here: https://dashboard.stripe.com/apikeys client = StripeClient("<>") # For SDK versions 12.4.0 or lower, remove '.v1' from the following line. account = client.v1.accounts.update( "{{CONNECTEDACCOUNT_ID}}", { "business_profile": {"url": "https://furever.dev"}, "tos_acceptance": {"date": 1609798905, "ip": "8.8.8.8"}, }, ) ``` ```php // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys $stripe = new \Stripe\StripeClient('<>'); $account = $stripe->accounts->update( '{{CONNECTEDACCOUNT_ID}}', [ 'business_profile' => ['url' => 'https://furever.dev'], 'tos_acceptance' => [ 'date' => 1609798905, 'ip' => '8.8.8.8', ], ] ); ``` ```java // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys StripeClient client = new StripeClient("<>"); AccountUpdateParams params = AccountUpdateParams.builder() .setBusinessProfile( AccountUpdateParams.BusinessProfile.builder().setUrl("https://furever.dev").build() ) .setTosAcceptance( AccountUpdateParams.TosAcceptance.builder() .setDate(1609798905L) .setIp("8.8.8.8") .build() ) .build(); // For SDK versions 29.4.0 or lower, remove '.v1()' from the following line. Account account = client.v1().accounts().update("{{CONNECTEDACCOUNT_ID}}", params); ``` ```node // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys const stripe = require('stripe')('<>'); const account = await stripe.accounts.update( '{{CONNECTEDACCOUNT_ID}}', { business_profile: { url: 'https://furever.dev', }, tos_acceptance: { date: 1609798905, ip: '8.8.8.8', }, } ); ``` ```go // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys sc := stripe.NewClient("<>") params := &stripe.AccountUpdateParams{ BusinessProfile: &stripe.AccountUpdateBusinessProfileParams{ URL: stripe.String("https://furever.dev"), }, TOSAcceptance: &stripe.AccountUpdateTOSAcceptanceParams{ Date: stripe.Int64(1609798905), IP: stripe.String("8.8.8.8"), }, } result, err := sc.V1Accounts.Update( context.TODO(), "{{CONNECTEDACCOUNT_ID}}", params) ``` ```dotnet // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys var options = new AccountUpdateOptions { BusinessProfile = new AccountBusinessProfileOptions { Url = "https://furever.dev" }, TosAcceptance = new AccountTosAcceptanceOptions { Date = DateTimeOffset.FromUnixTimeSeconds(1609798905).UtcDateTime, Ip = "8.8.8.8", }, }; var client = new StripeClient("<>"); var service = client.V1.Accounts; Account account = service.Update("{{CONNECTEDACCOUNT_ID}}", options); ``` Stripe validates every update to a connected account. Update the account at each step in onboarding to allow Stripe to validate information as soon as it’s added, while your users continue through the onboarding flow. After Stripe confirms acceptance of our terms of service, any changes to the connected account trigger reverification. For example, if you change the connected account’s name and ID number, Stripe reruns verifications. When updating a connected account, you must handle any [verification errors](https://docs.stripe.com/connect/custom/onboarding.md#verification-handling) or [HTTP error codes](https://docs.stripe.com/error-handling.md) returned by the Accounts API. ## Verification handling When the connected account’s data is submitted, Stripe verifies it. This process might take minutes or hours, depending on the nature of the verification. During this process, the capabilities you requested have a `status` of `pending`. ### Review status You can retrieve the status of your connected account’s capabilities by: - Inspecting the Account object’s [capabilities](https://docs.stripe.com/api/accounts/object.md#account_object-capabilities) hash for the relevant capability. - Requesting capabilities directly from the [Capabilities API](https://docs.stripe.com/api/capabilities/retrieve.md) and inspecting the status of the relevant capability. - Listening for `account.updated` [events](https://docs.stripe.com/api/events/types.md#event_types-account.updated) in your [webhook](https://docs.stripe.com/connect/webhooks.md) endpoint and inspecting the `capabilities` hash for the relevant capability. After verifications are complete, a capability becomes `active` and available to the connected account. Account verifications run continuously, and if a future verification fails, a capability can transition out of `active`. Listen for `account.updated` events to detect changes to capability states. Confirm that your Connect integration is compliant and operational by checking that the account’s `charges_enabled` and `payouts_enabled` are both true. You can use the API or listen for `account.updated` events. For details on other relevant fields, check the account’s [requirements](https://docs.stripe.com/api/accounts/object.md#account_object-requirements) hash. You can’t confirm the integration based on a single value because statuses can vary depending on the application and related policies. - [charges_enabled](https://docs.stripe.com/api/accounts/object.md#account_object-charges_enabled) confirms that your full charge path including the charge and transfer works correctly and evaluates if either `card_payments` or `transfers` capabilities are active. - [payouts_enabled](https://docs.stripe.com/api/accounts/object.md#account_object-payouts_enabled) evaluates whether your connected account can pay out to an external account. Depending on your risk policies, you can allow your connected account to start transacting without payouts enabled. You [must eventually enable payouts](https://docs.stripe.com/connect/manage-payout-schedule.md) to pay your connected accounts. You can use the following logic as a starting point for defining a summary status to display to your connected account. #### Ruby ```ruby # Set your secret key. Remember to switch to your live secret key in production. # See your keys here: https://dashboard.stripe.com/apikeys Stripe.api_key = '<>' def account_state(account) reqs = account.requirements if reqs.disabled_reason && reqs.disabled_reason.include?("rejected") "rejected" elsif account.payouts_enabled && account.charges_enabled if reqs.pending_verification "pending enablement" elsif !reqs.disabled_reason && !reqs.currently_due if !reqs.eventually_due "complete" else "enabled" end else "restricted" end elsif !account.payouts_enabled && account.charges_enabled "restricted (payouts disabled)" elsif !account.charges_enabled && account.payouts_enabled "restricted (charges disabled)" elsif reqs.past_due "restricted (past due)" elsif reqs.pending_verification "pending (disabled)" else "restricted" end end accounts = Stripe::Account.list(limit: 10) accounts.each do |account| puts "#{account.id} has state: #{account_state(account)}" end ``` #### Python ```python # Set your secret key. Remember to switch to your live secret key in production. # See your keys here: https://dashboard.stripe.com/apikeys stripe.api_key = '<>' def account_state(account): reqs = account.requirements if reqs.disabled_reason and "rejected" in reqs.disabled_reason: return "rejected" if account.payouts_enabled and account.charges_enabled: if reqs.pending_verification: return "pending enablement" if not reqs.disabled_reason and not reqs.currently_due: if not reqs.eventually_due: return "complete" else: return "enabled" else: return "restricted" if not account.payouts_enabled and account.charges_enabled: return "restricted (payouts disabled)" if not account.charges_enabled and account.payouts_enabled: return "restricted (charges disabled)" if reqs.past_due: return "restricted (past due)" if reqs.pending_verification: return "pending (disabled)" return "restricted" accounts = stripe.Account.list(limit=10) for account in accounts: print("{} has state: {}".format(account.id, account_state(account))) ``` #### Node.js ```javascript // Set your secret key. Remember to switch to your live secret key in production. // See your keys here: https://dashboard.stripe.com/apikeys const stripe = require('stripe')('<>'); const accountState = (account) => { const reqs = account.requirements; if (reqs.disabled_reason && reqs.disabled_reason.indexOf("rejected") > -1) { return "rejected"; } if (account.payouts_enabled && account.charges_enabled) { if (reqs.pending_verification) { return "pending enablement"; } if (!reqs.disabled_reason && !reqs.currently_due) { if (!reqs.eventually_due) { return "complete"; } else { return "enabled"; } } else { return "restricted"; } } if (!account.payouts_enabled && account.charges_enabled) { return "restricted (payouts disabled)"; } if (!account.charges_enabled && account.payouts_enabled) { return "restricted (charges disabled)"; } if (reqs.past_due) { return "restricted (past due)"; } if (reqs.pending_verification) { return "pending (disabled)"; } return "restricted"; }; const main = async () => { const accounts = await stripe.accounts.list({ limit: 10 }); accounts.data.forEach((account) => { console.log(`${account.id} has state: ${accountState(account)}`); }); }; main(); ``` ### Handle verification errors Handle verification failures differently depending on your onboarding flow. > You can’t use the API to respond to Stripe risk reviews. You can enable your connected accounts to respond using embedded components, Stripe-hosted onboarding, or remediation links. You can also use the Dashboard to respond to risk reviews on behalf of your connected accounts. #### API Listen to the [account.updated](https://docs.stripe.com/api/events/types.md#event_types-account.updated) event. If the account contains any `currently_due` fields when the `current_deadline` arrives, the corresponding functionality is disabled and those fields are added to `past_due`. [Create a form](https://docs.stripe.com/connect/custom/onboarding.md#create-forms-to-collect-information) with clear instructions that the account can use to correct the information. Notify the account, then [submit the corrected information](https://docs.stripe.com/connect/custom/onboarding.md#update-the-connected-account) using the Accounts API. (See full diagram at https://docs.stripe.com/connect/custom/onboarding) If you plan to create custom flows to handle all your verification errors: - Review the details regarding all possible [verification errors and how to handle them](https://docs.stripe.com/connect/handling-api-verification.md). - [Test verification states](https://docs.stripe.com/connect/testing-verification.md). #### Embedded Listen to the [account.updated](https://docs.stripe.com/api/events/types.md#event_types-account.updated) event. If the account contains any `currently_due` fields when the `current_deadline` arrives, the corresponding functionality is disabled and those fields are added to `past_due`. Let your accounts remediate their verification requirements by directing them to the [Account onboarding component](https://docs.stripe.com/connect/supported-embedded-components/account-onboarding.md). (See full diagram at https://docs.stripe.com/connect/custom/onboarding) ### Disable Stripe user authentication When using embedded onboarding, [Stripe user authentication](https://docs.stripe.com/connect/get-started-connect-embedded-components.md#user-authentication-in-connect-embedded-components) is enabled by default. You can use [`disable_stripe_user_authentication`](https://docs.stripe.com/api/account_sessions/create.md#create_account_session-components-account_onboarding-features-disable_stripe_user_authentication) to remove this behavior. We recommend implementing two-factor authentication or equivalent security measures as a [best practice](https://docs.stripe.com/connect/risk-management/best-practices.md#prevent-account-take-overs). For account configurations that support this feature, such as Custom, you assume liability for connected accounts if they can’t pay back [negative balances](https://docs.stripe.com/connect/risk-management/best-practices.md#decide-your-approach-to-negative-balance-liability). #### Hosted Listen to the [account.updated](https://docs.stripe.com/api/events/types.md#event_types-account.updated) event. If the account contains any `currently_due` fields when the `current_deadline` arrives, the corresponding functionality is disabled and those fields are added to `past_due`. Let your accounts remediate their verification requirements by directing them to the Stripe-hosted onboarding form. (See full diagram at https://docs.stripe.com/connect/custom/onboarding) ## See also Learn more about working with Custom accounts. - [Handle verification updates](https://docs.stripe.com/connect/handle-verification-updates.md) - [Updating Accounts](https://docs.stripe.com/connect/updating-service-agreements.md) - [Identity Verification](https://docs.stripe.com/connect/identity-verification.md)