Every country has its own requirements that accounts must meet to be able to pay out funds to individuals and companies. These are typically known as “Know Your Customer” (KYC) regulations. Regardless of the country, the broad requirements are:
- Collecting information about the individual or company receiving funds
- Verifying the information is accurate
Connect platforms collect the required information from users and provide it to Stripe. This may include personal information and a scan of a government-issued ID. We’ll then attempt verification, asking for more information when needed.
This page explains the verification flow options, but the easiest way to manage verification is to integrate Connect Onboarding, which lets Stripe take care of the verification complexity. Handling the details of verification yourself is not only complex initially, but requires ongoing maintenance because of changing regulations around the world.
If you choose to handle the details yourself, read on to learn more about the verification flow options, how our API fields translate to both companies and individuals, and how to localize information requests. You should also read our Handling Identity Verification with the API guide to learn how to programmatically provide information and handle requests.
Verification requirements vary depending on:
- The country the connected account is in.
- The capabilities the account has.
- Whether the business entity is a company or an individual.
Typically, there are two sets of information that needs to be collected and verified. The first set enables charges and the second set enables payouts. For example, to enable charges for a company in the U.S., you might need to collect:
- Information about the business (e.g., name, address).
- Information about the person opening the Stripe account (e.g., name, date of birth).
- Beneficial owner information (e.g., name, personal address).
The second set of information (typically required for connected accounts in the U.S.) enables payouts and needs to be collected after certain thresholds are reached. These thresholds vary, but they often have a processing element and a time element. For example, after 30 days from the first charge or after $1,500 (USD) in charges are created (whichever comes first), Stripe requests this second set of information. Using the previous example, this additional information might include:
- The last four digits of an owner’s social security number
- A scan of an ID document
If a connected account does not satisfy the initial requirements to enable payouts, Stripe temporarily pauses charge creation until this information is provided. After 21 calendar days from the first charge, if this information still isn’t provided, charges on the account are automatically refunded. Charges are refunded incrementally, not in a lump sum. For example, if the first charge is made on May 1st, and the last charge is made on May 6th, the first charge is refunded on May 22nd, and the last charge is refunded on May 27th.
As the platform, you need to decide if you want to collect the required information from your connected accounts upfront or incrementally (incremental onboarding). Some pros and cons for each method are listed below.
|Upfront onboarding||incremental onboarding|
To help you determine which flow to build, review the required information for the countries your connected accounts will be in. Requirements vary depending on the country, so one flow might fit your business better depending on the location of your connected accounts.
Individual vs. company information
The specific KYC information required depends upon the type of entity involved. For individuals, it’s straightforward: collect and provide information about that person.
For companies, collect information about the company. Depending on the countries your connected accounts are in, you might also have to collect information about beneficial owners. The required verification information page lists information required for individuals and companies by country. You can read more about handling identity verification with the API when you know what information needs to be collected.
Internationalization and localization
If you support users in multiple countries, you’ll need to consider internationalization and localization when asking for information. Creating an interface that uses not only the user’s preferred language but also the proper localized terminology results in a smoother onboarding experience.
For example, instead of requesting a business tax ID from your users, regardless of country, you should request:
- EIN, U.S.
- Business Number, Canada
- Company Number, UK
You can find recommended country-specific labels along with the other required verification information.
Now that you've learned the basics of identity verification, you may want to read:
Was this page helpful?