Upcoming requirements updates
Learn about the changes to required verification information and how this impacts your integration with Stripe.
Payments regulations help prevent crimes such as money laundering, fraud, and tax evasion. Financial regulators around the world enforce Know Your Customer (KYC) requirements to make sure that Stripe collects, verifies, and maintains identity information from certain types of businesses and from individuals who ultimately own, control, or direct them. These requirements are frequently updated by financial service regulators, card networks, and other financial institutions.
This guide provides an overview of the upcoming changes, and highlights the most significant changes. For the exhaustive list of requirements, refer to Required verification information.
If you use an API-based flow to onboard your connected accounts, you must update your integration to handle all requirement changes. Learn more about Connect onboarding options and migrating your API-based onboarding and remediation flows to Stripe-hosted or embedded flows.
Last updated: February 23, 2026
Understand the changes to verification requirements
To align with regulations from the UK Financial Conduct Authority (FCA) and the Central Bank of Ireland (CBI), Stripe is updating our verification requirements for Know Your Customer (KYC) and ultimate beneficial owners (UBO) and directors.
If your connected accounts operate in any of the listed countries, you might need to update your onboarding flow. Failure to make required updates will disrupt your connected accounts’ access to payments and financial services.
To learn more about what’s changing and why, see the new compliance requirements support article.
The upcoming changes affect connected accounts in the following countries:
Ongoing updates
Stripe will continue updating the API to support collecting these requirements through April 1, 2026.
Choose an integration approach
Stripe recommends using Stripe-hosted or Embedded onboarding to collect business and identity verification requirements. These options require fewer resources to implement and maintain than using API onboarding. The following table describes the major differences:
- Stripe-hosted onboarding: Recommended Send accounts to a Stripe-hosted flow to submit required information.
- Embedded onboarding: Recommended Embed Stripe-provided onboarding components that let accounts submit information directly to Stripe from within your app.
- API onboarding: Build and manage a custom onboarding flow using Stripe APIs.
| Stripe-hosted onboarding | Embedded onboarding | API onboarding | |
|---|---|---|---|
| Best for | Platforms that want Stripe to handle onboarding | Platforms that want a branded, in-app onboarding flow | Platforms that need full control and can build and maintain it |
| Initial implementation effort | 3–4 engineering weeks | 3–4 engineering weeks | 30–40 engineering weeks |
| Ongoing effort to address requirement updates | Handled automatically by Stripe | Handled automatically by Stripe | Requires proactive monitoring for upcoming changes, plus engineering resources to update the onboarding flow for each change |
| Customization | Stripe-hosted interface with platform branding | Highly themeable component that accounts access through the platform app | Platform designs, builds, and maintains the interface |
| Effort to support additional countries | Handled automatically by Stripe | Handled automatically by Stripe | Requires engineering resources to update the onboarding flow for each additional country |
Learn more about Connect onboarding options and migrating your API-based onboarding and remediation flows to Stripe-hosted or embedded flows.
The changes you make to your onboarding flow depend on your onboarding configuration. In addition to updating your onboarding flow, update your internal and external documentation as needed, and prepare your support teams to answer questions about the updates.
If you use Stripe-hosted or Embedded onboarding, then you don’t need to update your integration to prepare for these requirement updates. However, you can communicate to your connected accounts that Stripe might request new or updated identity information when requirements change.
API integration overview
If you choose not to migrate to Stripe-hosted or Embedded onboarding, then you need to address the following updates:
- Know Your Customer (KYC) verification
- Ultimate beneficial owner (UBO) and director relationship verification
- Netherlands business registration (KvK) requirements
- New error codes
Update timeline
The following timeline explains the key milestones for these changes. Make sure to update and test your integration early to avoid any issues when the new requirements take effect.
| Date | Milestone | Description |
|---|---|---|
| October 2025 | Start integration planning | Initial API updates are available. Review this guide and the changes to start planning your integration updates. |
| March 2026 | Review impacted accounts and test your integration updates | Stripe provides an estimated count of your impacted connected accounts. Start testing your updated onboarding flow. |
| March – April 2026 | future_ rollout begins (API onboarding) | For platforms using API onboarding, Stripe starts adding the new requirements to future_ for both new and existing accounts. |
| April 1, 2026 | New requirements start for platforms that only have connected accounts with business type individual | Make sure that your updated onboarding flow is ready to collect the new requirements. You need to have your updated flow working by April 1, when Stripe begins rolling out the new requirements. All of the new requirements will become active by the end of April. |
| May 1, 2026 | New requirements start for platforms that have connected accounts with business type company, including platforms that also have individual connected accounts | Make sure that your updated onboarding flow is ready to collect the new requirements. You need to have your updated flow working for all connected accounts by May 1, when Stripe begins rolling out the new requirements. All of the new requirements will become active by the end of May. |
| June 2026 – August 2026 | New requirements become currently due for existing accounts | The new requirements roll out to existing connected accounts during this period. Use your updated onboarding flow to collect them as needed. |
| July – October 2026 | Due dates for new requirements | To avoid restrictions, the updated requirements for each account must be verified by that account’s due date. |
Know your customer (KYC) verification
Stripe is strengthening our identity verification process, which might require some of your connected accounts to provide additional information. We’re also adding more options to the API for verifying information.
The following entities must provide verifiable KYC information:
- Legal entity (for individuals and sole proprietor entities);
- Account representative
- UBOs (for accounts deemed high risk by the Stripe risk model)
Additional verification methods
Use the following optional methods in addition to standard keyed-in information to maximize verification success rates:
- Stripe Identity: Recommended Use selfie and document capture for accounts that fail automatic verification.
- National ID verification: Collect a national ID number up front to increase first-pass verification rates.
- Upload additional documents: Submit supporting identity or address documents for manual review.
Stripe Identity Recommended
You can attempt to verify connected accounts that fail their automatic verification by using Stripe Identity. Identity works by capturing a selfie and an ID document. Most European countries support Stripe Identity, and success rates vary by country.
Create an Identity verification session and use the related_person parameter to submit document and proof_ requirements for the person. You can check the results using the API or the Dashboard.
National ID verification
In the countries affected by this update, you can improve verification of a connected account representative by providing their national ID number in addition to their name, birthdate, address, and nationality.
Verification currently supports the following national ID numbers.
| Country | National ID type |
|---|---|
| Denmark | Central Person Register (CPR) |
| Finland | Henkilötunnus (Personal Identity Code) |
| Greece | Arithmós Forologikoú Mitróou (AFM / Tax ID) or Prosopikós Arithmós (Personal Number) |
| Ireland | Personal Public Service (PPS) number |
| Italy | Codice Fiscale (Fiscal Code) |
| Latvia | Personas kods (Personal Code) |
| Poland | PESEL number |
| Romania | Cod Numeric Personal (CNP) |
| Spain | Documento Nacional de Identidad (DNI) |
| Sweden | Personnummer (Personal Identity Number) |
Countries not affected by this update, such as the US, don’t support National ID number verification. For example, you can provide the ID number for a Spanish citizen acting as a representative for a connected account in Austria, which is in the EU. However, you can’t provide the ID number for a Spanish citizen acting as a representative for a connected account in the US.
National ID availability
You can start collecting national ID numbers for your connected accounts when the updated requirements become future requirements. In the meantime, the integration is available for your sandbox accounts as a preview feature.
Implement national ID verification using the API
High risk accounts
Stripe’s risk model requires KYC verification for UBOs only for accounts classified as high risk. For testing, append _ to the business name to force a high-risk rating. This lets you test the full KYC verification flow for owners, including the requirements and errors your integration needs to handle.
This example shows how to create a high-risk test account and add owners:
// Creating a connected account in Spain curl https://api.stripe.com/v1/accounts \ -u sk_test_123: \ -H "Stripe-Version: 2025-08-27.basil;experimental_onboarding_preview=v2" \ -d 'type'='custom' \ -d 'country'='ES' \ -d 'capabilities[card_payments][requested]'='true' \ -d 'capabilities[card_payments][preview]'='true' \ -d 'capabilities[transfers][requested]'='true' { "id": "acct_123", ... "requirements": {...} ... } // Set the business name to enforce the account to be high risk curl https://api.stripe.com/v1/accounts/acct_123 \ -u sk_test_123: \ -d "business_profile[name]"="example_high_risk"
curl https://api.stripe.com/v1/accounts/acct_123/persons \ -u sk_test_123: \ -d first_name=Marie \ -d last_name=Dupont \ -d "dob[day]"=1 \ -d "dob[month]"=1 \ -d "dob[year]"=1901 \ -d "relationship[owner]=true" \ -d "address[line1]"="address_no_match" \ -d "address[city]"="Madrid" \ -d "address[postal_code]"="28001" { "id": "person_123", ... }
curl https://api.stripe.com/v1/accounts/acct_123 \ -u sk_test_123: \ -d "company[owners_provided]"="true"
After Stripe runs KYC verification on the owner, the account requirements reflect the result. When the owner’s name matches but their address doesn’t (triggered by using the address_ test address), the requirements include verification_ errors on the owner’s fields:
{ "requirements": { "past_due": [ "people.person_123.address.city", "people.person_123.address.line1", "people.person_123.address.postal_code", "people.person_123.first_name", "people.person_123.last_name" ], "errors": [ { "code": "verification_failed_keyed_identity", "requirement": "people.person_123.address.city" }, { "code": "verification_failed_keyed_identity", "requirement": "people.person_123.address.line1" }, { "code": "verification_failed_keyed_identity", "requirement": "people.person_123.address.postal_code" }, { "code": "verification_failed_keyed_identity", "requirement": "people.person_123.first_name" }, { "code": "verification_failed_keyed_identity", "requirement": "people.person_123.last_name" } ], "alternatives": [ { "original_fields_due": [ "people.person_123.address.city", "people.person_123.address.line1", "people.person_123.address.postal_code", "people.person_123.first_name", "people.person_123.last_name" ], "alternative_fields_due": [ "people.person_123.verification.additional_document" ] }, { "original_fields_due": [ "people.person_123.address.city", "people.person_123.address.line1", "people.person_123.address.postal_code", "people.person_123.first_name", "people.person_123.last_name" ], "alternative_fields_due": [ "people.person_123.verification.proof_of_liveness" ] } ] } }
To resolve these requirements, either resubmit the owner’s identity information or fulfill one of the alternative requirements (upload an additional_ or complete proof_).
Relationship verification for UBOs and directors
Stripe is enhancing our verification process for ultimate beneficial owners (UBOs) and directors. European regulations require verification of the relationship of UBOs and directors to the legal entity:
- UBO: An individual who owns or controls (directly or indirectly) more than 25% of a legal entity (for example, companies, corporations, LLCs, and partnerships).
- Director: A member of the board of directors of the business, or any other senior person responsible for managing the business. (Examples include CEO, COO, President, Managing Director, Executive Director, and so on.)
The following table shows the relationships that must be verified for each legal entity type:
| Legal entity type | Relationships to verify | Note |
|---|---|---|
| Company, corporation, LLC, partnership | UBOs if they exist; otherwise directors | UK only: both UBOs and directors |
| Non-profit | Directors | Most non-profits don’t have UBOs |
| Individual or sole proprietor | N/A | N/A |
| Government entity or agency | N/A | To be exempt from providing UBO information, government entities must follow the process described in this Support article. |
| Publicly traded company | N/A | To be exempt from providing UBO information, publicly traded companies must follow the process described in this Support article. |
Verify UBO and director information
UBOs and directors must provide the following information:
- Full name
- Date of birth
- Address
- Title (directors only)
Stripe attempts to verify the person’s relationship by matching the following key properties of the person and the legal entity:
| Entity | Key properties |
|---|---|
| Person |
|
| Legal entity |
|
A successful verification might require only a subset of the properties to match.
Stripe attempts to verify relationships in the following ways:
| Method | Description | Sample requirements |
|---|---|---|
| Third-party provider | If a third-party provider is available, Stripe automatically attempts to verify all relationships on the account. |
|
| Official document | You can provide a “Proof of UBO” document for owners and a “Proof of Registration” document for directors. Acceptable documents vary by country. |
|
| Digital attestation | You can use the following PDF templates to provide digital attestations for your relationships: |
|
Identify relationship verification requirements using the API
Implement digital attestation for UBO and director verification using the API
Prefill UBO and director information Private preview
Optionally, you can also integrate with an API that programmatically detects and prefills UBOs or directors associated with a legal entity. The connected account can verify the relationship by confirming the detected information instead of through document upload or digital attestation.
This path can increase verification rates and reduce friction, but it doesn’t work for all accounts. You still need to handle document uploads or digital attestations for accounts where Stripe can’t prefill their relationships.
If you’re interested in prefill for UBO or director verification, sign up to express your interest below.
Interested in getting early access to the Stripe UBO/director prefill?
Enter your email to request access.
Netherlands business registration (KvK) requirements
Effective May 14, 2026
Earlier in 2026, platforms were required to collect a KvK (Kamer van Koophandel) number, a unique 8-digit business registration number, from connected accounts in the Netherlands (NL). As part of this change, the individual business type was restricted with an unsupported_ error, and unincorporated entities were required to provide a KvK number via company..
Starting May 14, 2026, connected accounts representing individuals or unincorporated entities that don’t have access to a Stripe-hosted Dashboard are no longer required to provide a KvK number.
Connected accounts representing individuals or unincorporated entities that have access to the full Stripe Dashboard or the Express Dashboard must still provide a KvK number.
What’s changing
business_is now supported for connected accounts in the Netherlands that don’t have access to a Stripe-hosted Dashboard. Thetype: "individual" unsupported_error no longer appears for these accounts.business_ type unincorporated_andpartnership unincorporated_business types no longer requirenon_ profit company.to hold the KvK number for connected accounts that don’t have access to a Stripe-hosted Dashboard.tax_ id
What you need to do
No action is required. You don’t need to make any changes to your integration.
For existing connected accounts affected by this change:
- Stripe automatically clears the
unsupported_error frombusiness_ type requirements.for individual accounts.errors - Any capability restrictions (such as
card_orpayments transfers) tied to this error are automatically lifted. - Accounts representing individuals or unincorporated entities that were restricted for a missing KvK number are also automatically unrestricted.
New error codes
Verification error codes Public preview
The new error code verification_ can appear in the requirements. array on the Account object. This error signals that Stripe was unable to retrieve information (such as UBO or Director/Officer data) from third-party verification providers using the connected account’s known legal entity details. That can happen for a number of reasons, but it’s often because the account entered their information incorrectly.
This “data not found” error is distinct from existing verification error codes:
verification_: Indicates that known owners are missing from the account.missing_ owners verification_: Indicates a mismatch between submitted information and verification sources.failed_ keyed_ match
// Example: verification_data_not_found error { "requirements": { "errors": [{ "requirement": "owners", "code": "verification_data_not_found", "reason": "Stripe was unable to retrieve ownership or director information from third-party providers based on the current legal entity details. Verify that the business information on the account is correct." }] } }
To handle this error, prompt the connected account to review and correct their legal entity information (company name, registration number, address). If they update their information, Stripe automatically attempts to verify it again.
If the account information is correct, or if Stripe still can’t verify updated information, use a manual verification method such as document upload or digital attestation.
Testing
You can create test accounts to use when developing and testing your integration. Test accounts can simulate different verification outcomes, allowing you to see how the API returns requirements and errors for each case.
The following examples help you prepare for the upcoming EU requirements changes. For more information about Connect testing in general, see Testing Stripe Connect.
Create a test account
Create a test Account by sending a POST request to the Accounts API using your sandbox secret key.
To access the new requirements before they’re released to non-test mode accounts, set a header enabling a preview version of the API, enable the experimental onboarding preview feature, and enable the preview version when requesting a capability. For example:
curl https://api.stripe.com/v1/accounts \ -u sk_test_123: \ -H "Stripe-Version: 2026-01-28.preview;experimental_onboarding_preview=v2" \ -d 'type'='custom' \ -d 'country'='ES' \ -d 'capabilities[card_payments][requested]'='true' \ -d 'capabilities[card_payments][preview]'='true' \ -d 'capabilities[transfers][requested]'='true' \ -d 'capabilities[transfers][preview]'='true'
The examples below demonstrate how to simulate different situations by using values that trigger specific responses for test accounts.
Test an Account belonging to an individual
This example creates an account that doesn’t require relationship verification because the business entity type is individual.
Create a test account following the earlier instructions, then set the basic business details:
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d business_type=individual \ -d "business_profile[mcc]"=5995 \ -d "business_profile[url]"="https://accessible.stripe.com"
The response includes the basic requirements for an individual. You can meet these requirements by creating a representative:
curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Marie" \ -d "last_name=Dupont" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=test@example.com" \ -d "phone=%2B35366666666" \ -d "nationality=ES" \ -d "relationship[representative]=true"
Specifying the DOB 1901-01-01 triggers successful identity verification in a sandbox. For other result triggers, see Test dates of birth. Similarly, setting the first line of the address to the string address_ triggers successful verification of the address. For other result triggers, see Test business addresses.
The response shows that the individual’s requirements have become pending. If you wait a few moments and retrieve the Account, you can see that those requirements have been cleared:
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123
The only remaining requirements are for the bank account (external_) and terms of service (TOS). To clear the terms of service requirements, set the Account’s tos_ hash:
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "tos_acceptance[date]=1540248693" \ -d "tos_acceptance[ip]=10.0.0.1"
To clear the bank account requirements, create a test bank account for the Account. Specify a test bank account number according to its country:
curl https://api.stripe.com/v1/accounts/acct_test_123/external_accounts \ -u sk_test_123: \ -d "external_account[object]=bank_account" \ -d "external_account[account_number]=ES0700120345030000067890" \ -d "external_account[country]=ES" \ -d "external_account[currency]=EUR"
Test an Account belonging to a company
This example creates an account that is subject to relationship verification requirements because the business entity type is company.
Regional considerationsUnited Kingdom
The UK requires verification of both the ultimate beneficial owners (UBOs) and the directors. If you’ll have connected accounts in the UK, make sure to test with accounts that have the country set to GB.
Create a test account following the earlier instructions, then set the basic business details:
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d business_type=company \ -d "business_profile[mcc]"=5995 \ -d "business_profile[url]"="https://accessible.stripe.com" \ -d "company[name]=Test company" \ -d "company[phone]=628123456787" \ -d "company[address][line1]=address_full_match" \ -d "company[address][city]=Madrid" \ -d "company[address][postal_code]=28009" \ -d "company[address][country]=ES" \ -d "company[tax_id]=000000000"
Specifying the tax ID number 000000000 triggers successful verification of the company. For other result triggers, see Test business tax IDs.
Next, provide a representative.
curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Adam" \ -d "last_name=" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=test@example.com" \ -d "phone=%2B35366666666" \ -d "nationality=ES" \ -d "relationship[representative]=true" \ -d "relationship[title]=CEO"
After the verification process for the representative completes, you can see the remaining requirements with a GET request:
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123:
The requirements in the requirements. array list the details we need about the owners on the Account. The requirements. array can include optional information that you can provide to fulfill certain requirements. For example:
{ "alternative_fields_due": [ "company.owners_provided", "documents.proof_of_ultimate_beneficial_ownership.files", "owners.first_name", "owners.last_name" ], "original_fields_due": [ "company.owners_provided", "owners.first_name", "owners.last_name" ] }
You can provide the fields listed in alternative_ as another way to fulfill the requirements in the corresponding original_ list. In this example, alternative_ includes the properties in original_, plus documents.. That means the original information is required, but you have the option to also provide a document proving ultimate beneficial ownership to help the verification process.
To meet the owner requirements, create two persons and mark them as owners. The names in this example are hard-coded values for test accounts that use the tax ID number 000000000.
curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Marie" \ -d "last_name=Dupont" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=owner@example.com" \ -d "relationship[owner]=true" curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Louis" \ -d "last_name=Martin" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=owner@example.com" \ -d "relationship[owner]=true"
Indicate that you’ve created all of the Account’s owners by setting company. to true:
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[owners_provided]=true"
Completing this request removes all the owner requirements from the Account.
Test fallback to document verification
An Account’s owner requirements remain in currently_ (or in pending_, if verification is in progress) until verification is successful.
When verification fails, one of your options is to upload a document. This example shows how to do so using the API.
Create a test account following the earlier instructions, then set the basic business details. Set the tax ID number to 222221001, which triggers owner verification failure. For other result triggers, see Test business tax IDs.
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d business_type=company \ -d "business_profile[mcc]"=5995 \ -d "business_profile[url]"="https://accessible.stripe.com" \ -d "company[name]=Test company" \ -d "company[phone]=628123456787" \ -d "company[address][line1]=address_full_match" \ -d "company[address][city]=Madrid" \ -d "company[address][postal_code]=28009" \ -d "company[address][country]=ES" \ -d "company[tax_id]=222221001"
Next, provide a representative:
curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Marie" \ -d "last_name=Dupont" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=test@example.com" \ -d "phone=%2B35366666666" \ -d "nationality=ES" \ -d "relationship[representative]=true" \ -d "relationship[title]=CEO"
Then, create an owner:
curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Adam" \ -d "last_name=Smith" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=owner@example.com" \ -d "relationship[owner]=true"
Indicate that you’re done creating owners by setting company. to true:
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[owners_provided]=true"
If you examine the Account, you can see that the owner requirements remain and the requirements. array contains an entry with a requirement of owners and a code of verification_. That means Stripe wasn’t able to verify the owners using the provided company information.
Public preview
If you’re using the public preview version of the API, the error code is verification_data_not_found instead of verification_.
If you receive this error for a real Account, check that you entered the details for the correct legal entity. This example assumes that the details are correct, and that you need to provide a document to verify them.
For a real Account, use the Files API to upload a document, then update the Account using the token returned in the response. For this example, use the test token file_. For other result triggers, see Test relationship document tokens.
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "documents[proof_of_ultimate_beneficial_ownership][files][]"=file_relationship_document_success
A few moments after updating the Account, you can get the current requirements and see that the owner requirements have been cleared.
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123:
Test a company with no applicable owners
If a company has no owners with more than 25% ownership, Stripe requires the director information instead. This example demonstrates how to provide director information.
Create a test account following the earlier instructions, then set the basic business details. Set the tax ID number to 000000000, which triggers company verification success.
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d business_type=company \ -d "business_profile[mcc]"=5995 \ -d "business_profile[url]"="https://accessible.stripe.com" \ -d "company[name]=Test company" \ -d "company[phone]=628123456787" \ -d "company[address][line1]=address_full_match" \ -d "company[address][city]=Madrid" \ -d "company[address][postal_code]=28009" \ -d "company[address][country]=ES" \ -d "company[tax_id]=000000000"
Next, provide a representative:
curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Marie" \ -d "last_name=Dupont" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=test@example.com" \ -d "phone=%2B35366666666" \ -d "nationality=ES" \ -d "relationship[representative]=true" \ -d "relationship[title]=CEO"
To indicate that the business has no relevant owners, set company. to true without creating any owners. To reuse an existing test Account that has owners, you can remove all the existing owners.
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[owners_provided]=true"
The requirements. array contains a set of director properties as an alternative to the owner properties. The process for creating a director is very similar to the process for creating an owner:
curl https://api.stripe.com/v1/accounts/acct_test_123/persons \ -u sk_test_123: \ -d "first_name=Adam" \ -d "last_name=Smith" \ -d "dob[year]=1901" \ -d "dob[month]=1" \ -d "dob[day]=1" \ -d "address[line1]=address_full_match" \ -d "address[city]=Madrid" \ -d "address[postal_code]=28009" \ -d "address[country]=ES" \ -d "email=owner@example.com" \ -d "relationship[director]=true" \ -d "relationship[title]=President"
Indicate that you’re done creating directors by setting company. to true:
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[directors_provided]=true"
To simulate a successful relationship verification, set company. to the string match_:
curl https://api.stripe.com/v1/accounts/acct_test_123 \ -u sk_test_123: \ -d "company[name]=match_name_relationships"
Other test cases
The following tests are also valuable:
- A
non_type entity, which requires director verification (UBO verification isn’t an option).profit - Meeting director verification requirements using a document.
- Companies in the UK that require both UBO verification and director verification.