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: October 13, 2025
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 is 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 how you collect onboarding information. 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
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. |
| February 2026 | Review impacted accounts and test your integration updates | Stripe provides a list of your impacted connected accounts. Start testing your updated onboarding flow. |
| April 1, 2026 | New requirements apply to all new accounts | Make sure that your updated onboarding flow is ready to collect new requirements for connected accounts. Stripe will begin rolling out these requirements to new accounts that onboard on or after this date. |
| April 2026 – early July 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 and directors (for accounts deemed high risk by the Stripe risk model)
Alternative verification methods
If initial verification fails, you can try one of the following methods:
- Stripe Identity Recommended
- National ID verification
You can also still upload additional documents.
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 Public preview
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 only the following national ID numbers.
| Country | National ID type |
|---|---|
| Denmark | Central Person Register (CPR) |
| Italy | Codice Fiscale (Fiscal Code) |
| Poland | PESEL number |
| Spain | Documento Nacional de Identidad (DNI) |
| Sweden | Personnummer (Personal Identity Number) |
You can provide national ID numbers only for connected accounts in the countries affected by this update. For example, you can provide the ID number for a Spanish citizen acting as a representative for a connected account in Austria, but 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
This integration will be available in production when the updated requirements become future requirements. Use the following example to test your integration.
Implement national ID verification using the API
The following example demonstrates onboarding a new connected account with the updated requirements.
Note
The differences below only impact the v1 Accounts API, not v2.
Step 1: Create a connected account
After future requirements roll out, create connected accounts as usual. Until then, create new connected accounts in test mode to enable the new KYC behavior.
Trigger this behavior by changing two parts of your account creation call:
- Add the header
experimental_.onboarding_ preview=v1 - Submit
capabilities[card_.payments][experimental]=true
After you create the account, you see a new requirement string representative.. This indicates you can create an account representative and pass nationality.
// 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=v1" \ -d 'type'='custom' \ -d 'country'='ES' \ -d 'capabilities[card_payments][requested]'='true' \ -d 'capabilities[card_payments][experimental]'='true' \ -d 'capabilities[transfers][requested]'='true' { "id": "acct_1Nv0FGQ9RKHgCVdB", ... "requirements": { "past_due": [ ... "representative.nationality", ... ] } ... }
Step 2: Create an account representative
After you create the connected account, create an account representative.
> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB/persons \ -u sk_test_123: \ -d first_name=John \ -d last_name=Doe { "id": "person_1N9XNb2eZvKYlo2CjPX7xF6B", ... }
Step 3: Submit nationality
After you create an account representative, nationality appears in past_. Collect this field so Stripe can determine if the representative is eligible for id_ collection.
> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB -u sk_test_123: { ... "requirements": { "past_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.year", ...other person requirements... "person_1N9XNb2eZvKYlo2CjPX7xF6B.nationality" ] } ... }
After you collect nationality, if the person is in an eligible country you see past_ and alternatives. This indicates that collecting national ID is recommended but not required.
> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB/persons/person_1N9XNb2eZvKYlo2CjPX7xF6B \ -u sk_test_123: \ -d nationality=ES > curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB -u sk_test_123: { "requirements": { "past_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.year", ...other person fields... ], "alternatives": [ { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.year", ...other person fields... ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number" ] } ] } }
Step 4: Collect remaining account representative fields
Collect additional person attributes, including a national ID number, to start programmatic KYC verification.
> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB/persons/person_1N9XNb2eZvKYlo2CjPX7xF6B \ -u sk_test_123: \ -d 'id_number'='74362315-A' \ ...other person fields...
Step 5: Keyed-in fields go into pending verification
After you provide keyed-in data, fields appear in pending_ in a new way:
- Keyed-in fields go into
pending_rather thanverification verification.anddocument verification.. This indicates the keyed-in fields are being verified.additional_ document - The
id_requirement can go intonumber pending_if provided, even if it appears only inverification alternative_and never infields_ due past_ordue currently_.due
> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB/ -u sk_test_123: { "requirements": { "pending_verification": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.city", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.line1", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.postal_code", "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.day", "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.month", "person_1N9XNb2eZvKYlo2CjPX7xF6B.dob.year", "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name" ], } }
Step 6: Handle verification errors
In many cases, after fields enter pending_, the representative passes KYC and the process completes.
If verification fails, Stripe returns additional information to help you guide the next steps.
There are two important changes.
Multiple alternatives
In the requirements hash you will see multiple alternatives. Each of these represents a path forward for your users.
For example, if the name and date of birth match but the name and address don’t, your connected account has several ways to resolve the issue:
- They can check the information they’ve entered for name and address and re-enter those fields to correct any errors.
- They can check the information they entered for dob, name, address and id_number and re-key correct information.
- They can upload a document that matches their name and address
- They can complete Stripe Identity
These four paths appear as past_ fields and alternatives:
> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB -u sk_test_123: { "requirements": { // 1. They can check the information they've entered for dob, name, and address, and re-enter the correct information. "past_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.*", ], "alternatives": [ // 2. They can check the information they entered for dob, name, address and id_number and re-key correct information. { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.*", ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number" ] }, // 3. They can upload document that matches their name and address { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.*" ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.verification.additional_document" ] }, // 4. They can complete Stripe Identity { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.first_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.last_name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address.*" ], "person_1N9XNb2eZvKYlo2CjPX7xF6B.proof_of_liveness" ] }, ] } }
Errors on keyed-in fields Previously, if a verification error occurred while processing keyed-in fields, document fields went to past_ and errors appeared on them. Going forward, keyed-in fields return to past_. Fields like id_ remain in alternative_.
For example, if name, date of birth, and address are originally past_, and after submission name and date of birth match while name and address do not, then name and address return to past_ while date of birth is removed.
In this situation, errors appear on fields in past_ and alternative_.
> curl https://api.stripe.com/v1/accounts/acct_1Nv0FGQ9RKHgCVdB -u sk_test_123: { "requirements": { "past_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" ], "alternatives": [ { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number" ] }, { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.proof_of_liveness" ] }, { "original_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.name", "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" ], "alternative_fields_due": [ "person_1N9XNb2eZvKYlo2CjPX7xF6B.verification.additional_document" ] } ] "errors": [ { "code": "verification_failed_keyed_in_mismatch", "reason": "Identity information could not be verified." "requirement": "person_1N9XNb2eZvKYlo2CjPX7xF6B.name" }, { "code": "verification_failed_keyed_in_mismatch", "reason": "Identity information could not be verified." "requirement": "person_1N9XNb2eZvKYlo2CjPX7xF6B.address" }, { "code": "verification_failed_keyed_in_mismatch", "reason": "Identity information could not be verified." "requirement": "person_1N9XNb2eZvKYlo2CjPX7xF6B.id_number" } ] } }
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 board member or senior person responsible for managing a business (for example, CEO, COO, managing director).
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 | Non-profits don’t normally have UBOs |
| Government agency, government entity, individual, sole proprietor, publicly traded | N/A | Identity verification only |
Verification process
Connected accounts type in UBO or director information (name, date of birth, address). Stripe attempts to verify the person’s relationship to the legal entity using third-party sources. If automatic verification fails, the account can upload an official document or sign a digital attestation.
Digital attestation availability
Providing digital attestations isn’t available yet. Use this information to prepare for testing. We recommend that you use digital attestation when it becomes available.
If the account chooses digital attestation, use the following document templates.
Templates:
Implement digital attestation for UBO and director verification using the API
The following example shows how to perform digital attestation for UBO or director verification.
Retrieve the account to identify which attestation documents are required.
// Check for UBO attestation requirement > curl https://api.stripe.com/v1/accounts/acct_1234 \ -u sk_test_123: // Response showing UBO requirement { "id": "acct_1234", "requirements": { "past_due": ["documents.proof_of_ultimate_beneficial_ownership.files"], "errors": [] } } // Or for directors & officers requirement { "id": "acct_1234", "requirements": { "past_due": ["documents.proof_of_registration.files"], "errors": [] } }Generate a PDF using the template, and have an authorized person digitally sign it.
Upload the signed attestation document using the File API.
curl -X POST https://files.stripe.com/v1/files \ -u sk_test_123: \ -F purpose=account_requirement \ -F file=@signed_attestation.pdf // Response { "id": "file_1234567890", "object": "file", "purpose": "account_requirement" }Submit the document with the signer’s name for validation.
// For UBO attestation curl -X POST https://api.stripe.com/v1/accounts/acct_1234 \ -u sk_test_123: \ -d "documents[proof_of_ultimate_beneficial_ownership][files][]=file_1234567890" \ -d "documents[proof_of_ultimate_beneficial_ownership][signer][person]=person_xyz" // For D&O attestation curl -X POST https://api.stripe.com/v1/accounts/acct_1234 \ -u sk_test_123: \ -d "documents[proof_of_registration][files][]=file_1234567890" \ -d "documents[proof_of_registration][signer][person]=person_xyz"
Signer validation requirements
Who can sign attestations
- Account representatives
- Business owners (25%+ ownership)
- Directors and officers
- Other authorized account members
Important: The signer must be an existing person associated with the account. Only individuals with a documented relationship to the legal entity can sign attestation documents.
Error handling
Digital attestation introduces specific error scenarios you need to handle:
Invalid signator
Occurs when the signer isn’t associated with the account or lacks authority.
{ "requirements": { "past_due": ["documents.proof_of_ultimate_beneficial_ownership.files"], "errors": [{ "requirement": "documents.proof_of_ultimate_beneficial_ownership.files", "code": "invalid_signator", "reason": "Unauthorized attestation signer. The signer must have a documented relationship with the legal entity." }] } }
Stale attestation
Occurs when beneficial ownership information changes after attestation upload.
{ "requirements": { "past_due": ["documents.proof_of_ultimate_beneficial_ownership.files"], "errors": [{ "requirement": "documents.proof_of_ultimate_beneficial_ownership.files", "code": "verification_document_name_mismatch", "reason": "The attestation document is no longer valid due to changes in beneficial ownership information. Upload a new attestation reflecting the current ownership structure." }] } }
Document failed
Occurs when the uploaded document is unreadable or incorrect.
{ "requirements": { "past_due": ["documents.proof_of_registration.files"], "errors": [{ "requirement": "documents.proof_of_registration.files", "code": "verification_document_failed_other", "reason": "Your team can contact Stripe to learn more about why identity verification failed." }] } }
Implementation notes
Parameter constraints
- Provide signer parameters only when files are also submitted.
- Available for both v1 and v2 Account APIs.
API errors when submitting signer without files
{ "error": { "code": "invalid_signator", "message": "signer.person can only be provided when a file is also provided", "type": "invalid_request_error" } }
Next Steps
- Update your integration to collect signer names when using attestation documents
- Implement error handling for new attestation-specific error codes
- Train your support team on the new attestation requirements
Prefill UBO and director information Private preview
Stripe is developing an API that provides a programmatically detected set of UBOs or directors associated with the legal entity. You can present this set to connected accounts for confirmation (prefill). Prefill increases verification rates and reduces friction. If you’re interested in prefill for UBO or director verification, sign up to express your interest below.
Netherlands business registration (KvK) requirements
Starting in 2026, we’re enforcing stricter business type requirements for Netherlands (NL) accounts to ensure compliance with Dutch regulations. This specifically affects how we collect the KvK (Kamer van Koophandel), the unique 8-digit company registration number required for businesses in the Netherlands.
What’s changing
1. Individual business type is no longer supported
The individual business type is no longer supported for Netherlands accounts. This affects: Existing and new NL accounts with business_ and business_
Why this matters: In the Netherlands, every business must provide a KvK (Chamber of Commerce) number. Our “individual” business type doesn’t collect a KvK, which makes it non-compliant.
2. New error code: unsupported_ business_ type
Accounts with invalid business types see a new error in their requirements:
// Account with unsupported business type { "id": "acct_123", "business_type": "individual", "country": "NL", "requirements": { "past_due": ["business_type"], "errors": [{ "requirement": "business_type", "code": "unsupported_business_type", "reason": "Business type isn't supported in merchant country. 'individual' isn't a supported business type in country NL." }] } }
3. Collect KvK registration for unincorporated accounts
Existing and new NL accounts with the following business types and structures are required to provide KvK registration.
business_andtype: "company" business_structure: "unincorporated_ partnership" business_andtype: "non_ profit" business_structure: "unincorporated_ non_ profit"
Why this matters: unincorporated accounts are currently not required to provide a KvK number, which violates Dutch compliance requirements. All NL businesses must provide their KvK registration.
How to resolve
For existing accounts
Existing NL accounts with individual business type must update to company with sole_ structure to stay compliant when we start rolling out this new requirement:
// Update existing account curl -X POST https://api.stripe.com/v1/accounts/acct_123 \ -u sk_test_123: \ -d "business_type=company" \ -d "company[structure]=sole_proprietorship" \ -d "company[tax_id]=12345678" // KvK number // Successful response { "id": "acct_123", "business_type": "company", "company": { "structure": "sole_proprietorship", "tax_id": "12345678" }, "requirements": { "past_due": [], // business_type requirement resolved "errors": [] } }
For new account creation
Attempting to create a Netherlands account with an individual business type will return the unsupported_business_type error.
// This will fail curl -X POST https://api.stripe.com/v1/accounts \ -u sk_test_123: \ -d "country=NL" \ -d "type=custom" \ -d "business_type=individual" // Response { "id": "acct_123", "business_type": "individual", "country": "NL", "requirements": { "past_due": ["business_type"], "errors": [{ "requirement": "business_type", "code": "unsupported_business_type", "reason": "Business type isn't supported in merchant country. 'individual' isn't a supported business type in country NL." }] } // Correct approach curl -X POST https://api.stripe.com/v1/accounts \ -u sk_test_123: \ -d "country=NL" \ -d "type=custom" \ -d "business_type=company" \ -d "company[structure]=sole_proprietorship"
Supported business structures for NL
For Netherlands accounts, use these business type and structure combinations:
| Business Type | Structure | KvK Required |
|---|---|---|
company | sole_ | Yes |
company | incorporated_ | Yes |
company | unincorporated_ | Yes |
company | private_ | Yes |
company | public_ | Yes |
non_ | Various structures | Yes |
Impact on capabilities
Accounts with unsupported_ error will have their capabilities restricted until the business type is updated:
{ "capabilities": { "card_payments": "inactive", "transfers": "inactive" }, "requirements": { "disabled_reason": "requirements.past_due", "past_due": ["business_type"] } }
Accounts have not provided their KvK registration will have their card_ capability restricted until this information is provided:
{ "capabilities": { "card_payments": "inactive" }, "requirements": { "disabled_reason": "requirements.past_due", "past_due": ["company.tax_id"] } }
Migration timeline
- Now: New error code
unsupported_is activebusiness_ type - When Future requirements rollout: Existing accounts must start remediation
- September 30, 2026: All NL accounts must be compliant
Implementation Checklist
For platforms with NL connected accounts:
- Audit existing accounts
// Find affected accounts const accounts = await stripe.accounts.list({ limit: 100, // Filter for NL accounts in your system }); const affected = accounts.data.filter(a => a.country === 'NL' && a.business_type === 'individual' );
Update account creation flows
- Remove
individualoption for NL accounts - Default to
companywithsole_proprietorship - Collect KvK number (company.tax_id)
- Remove
Handle the new error code
if (account.requirements.errors.some(e => e.code === 'unsupported_business_type')) { // Prompt user to update business type // Guide them to select appropriate structure // Collect KvK number }
Communicate with affected connected accounts
- Explain why the change is needed
- Provide guidance on selecting correct business structure
- Help them locate their KvK number
Testing
Test your implementation with these scenarios:
// Test updating to valid business type const updated = await stripe.accounts.update('acct_test_123', { business_type: 'company', company: { structure: 'sole_proprietorship', tax_id: '12345678' // Test KvK } });
Additional considerations
Individual freelancers
In the Netherlands, even individual freelancers must register as a business (eenmanszaak) and obtain a KvK number. They should select company → sole_.
How to find the KvK number for connected accounts
The KvK number is on their Chamber of Commerce registration certificate (uittreksel Kamer van Koophandel).
#### Backward compatibility In older API versions, unsupported_ appears as invalid_ with a detailed_ field containing the specific error.