How should a payments company design merchant onboarding and KYB?

A merchant signs up on Monday, adds a bank account, and expects to be paid by Friday. On Thursday the dashboard shows “Additional information required,” and the email says “we need more information to continue.” It doesn’t say which information, from whom, or what happens next. Payouts are paused. The practice manager who filled in the form can’t supply the document compliance wants, because it belongs to an owner who is traveling. This scenario is illustrative.

KYB, know your business, is the set of checks a payments company runs on a merchant before paying it out. The form feeds a compliance record, and how the form is designed decides whether the record gets finished. This guide, published by Humbleteam, a digital product design agency, covers what KYB collects, how to stage it, how to show status, and what to ask a design agency. It is not legal advice: your compliance team and counsel decide what your company must collect.

What does KYB collect, and why?

Providers ask for the same few things: the business (legal name, address, tax ID, structure), the person completing the account, the people who own or control the business, a bank account for payouts, and a website or description of what the business sells. Stripe’s identity verification page gives the US example.

In the US, the owner questions trace to FinCEN’s Customer Due Diligence rule. It requires covered financial institutions, a group that includes banks, to identify and verify each person who owns 25% or more of a company opening an account, plus one person with significant control. That gives each company between one and five beneficial owners. The institution takes the details from the person opening the account, who may or may not be an owner. Whether the rule reaches your company directly or through a bank partner is a question for counsel. Every country has its own requirements, and FATF’s guidance falls back to the senior managing official when no owner can be identified, so a multi-country flow needs rules per country.

Keep that rule apart from the Corporate Transparency Act. Since FinCEN’s final rule took effect on August 14, 2026, US companies no longer report beneficial ownership to FinCEN, so a US merchant form should not say owners are requested “because of the Corporate Transparency Act.” Since February 2026 a bank may also skip re-verifying owners each time the same customer opens another account. Treasury’s regulatory agenda lists a FinCEN proposal to revise the bank rule for March 2027, so recheck before you build.

Hosted, embedded or API-built?

Stripe Connect offers three routes: a Stripe-hosted form, an embedded component, and onboarding you build on the API. Stripe recommends the first two because they update when compliance requirements change. With the API route you maintain the flow yourself and should review requirements at least every six months. Adyen likewise recommends its hosted onboarding over API-only.

With a hosted or embedded form you don’t draw the fields. You design what surrounds them: what happens before the merchant goes in, when they leave, and how status looks afterward. Prefill what you know, since Stripe’s form then asks the merchant to confirm it. Request only the capabilities the merchant needs, because each extra capability makes the flow verify more.

Ask for what is due now, and say what comes later

Stripe describes the choice plainly. Up-front onboarding collects everything that will eventually be due. Incremental onboarding collects only what is due now and gathers more as the account grows. Up front means one request, no payouts paused by a missed deadline, and risk showing early. Incremental means merchants start sooner. Later requirements usually arrive after a period of time or a volume of charges, and the provider sets those thresholds.

A workable rule of thumb: a marketplace of many small sellers leans incremental, and a merchant expecting a large first payout is better served up front. Either way, show the next stage early: “You can take payments now. Before payouts reach the next limit, we’ll also need your owners’ details.”

What to ask, why, and what the merchant sees if it fails

The table is a planning sheet for a US business merchant. The “when” column is a recommendation. Confirm each row against your provider’s requirement list for your countries and business types.

Each failure message names the item, says what was wrong, and offers a way out. Stripe’s verification API attaches a plain reason and a code to every failed requirement, with examples such as a website that can’t be reached and a grayscale document. Under each sensitive field, add one sentence on what it is for: “We check who owns and runs a business before we pay it out.” Add who can see the field and how long it is kept only after your privacy and compliance teams confirm the answer.

Show what works, what is blocked, and what to do

Status words differ by provider. Stripe lists requirements as currently due, past due or pending verification. Adyen gives each capability the status pending, valid, invalid or rejected. Checkout.com adds restricted. Merchants should see none of these words. They need three answers: what still works, what is blocked, and what to do by when. Four states cover the unhappy path.

• Checking. The provider is reviewing, and the merchant has nothing to do. Say so, or they will upload the same file again. Adyen says manual reviews are generally processed within 48 hours; show a timeframe only if your provider states one.
• Action needed. Name the item, the person, the reason and the deadline. Stripe typically disables payouts if the information isn’t received by the current deadline, while Adyen lets an account keep working during a verification deadline. Put the date on the screen.
• Restricted. Say which parts still work. Stripe notes an account can show Restricted while it is still taking payments and receiving payouts.
• Rejected. Adyen calls this status final, and Checkout.com says a rejected sub-entity can’t resume onboarding. Don’t show an upload button. Give a way to ask for a review, and agree with compliance what the screen may say about the reason. A list match, for example, may not be something to explain.

Our guide to payment states does the same job for transactions.

Uploads, edits and re-checks

Stripe’s upload rules are color images, 10 MB or less, JPG or PNG for identity documents, and an expiry date after the submission date. A duplicate of a failed file fails automatically, so check type and size in the browser, tell the merchant when they pick the same file again, and show the provider’s reason beside the field.

Editing a verified detail often starts a new check. Adyen runs verification again when legal entity details change, and Checkout.com says updating a verified sub-entity resets its status to pending. Warn before the save: “Changing your address starts a new check.” Adyen also sets periodic reviews with a deadline to confirm data is current: show a “confirm your details” screen with the data filled in.

When the person filling in the form is not the owner

This is the opening scenario. An owner’s birth date and ID are things a practice manager may not have, or may not want to type. Adyen’s hosted onboarding lets the user invite a decision-maker by email to submit their own details, and asks guided questions to pick the right role: beneficial owner, controlling person or signatory. If you build on the API, build the invitation yourself with a name, an email and a link to that person’s section only.

Save-and-resume needs the same care. Stripe’s hosted form has a Save for later button, and its return URL doesn’t mean onboarding is complete, so the platform checks the account’s requirements and prompts the merchant to continue. Stripe says not to email its single-use account links. Keep a “Continue onboarding” card inside the signed-in product, with a line per person: “Dana: done. Chris: invited, not started.”

An illustrative worked example

An invented payments platform for dental clinics onboards an invented clinic. The practice manager, Priya, fills in the form. Two owners, Dana and Chris, hold 60% and 40%. The platform chose incremental onboarding.

• Day 0. Priya enters the clinic, herself, the website and a bank account. The screen says: “You can take card payments now. Before your first payout we also need both owners’ details.”
• Day 1. Priya adds Dana and Chris by name and email, and each gets an invite to submit a birth date and ID.
• Day 3. Chris uploads a black-and-white photo of his license, and the check fails. The status reads: “Payouts are paused until Friday. One item is left: a color photo of Chris’s driver’s license. The last file was black and white. You can still take payments, and the money stays in your balance until payouts resume.” Two buttons follow: “Send Chris a new link” and “Upload it yourself.”

The message from the opening named nothing. This one names the item, the person, the reason and the deadline, offers two ways to fix it, and says what still works.

What to ask a design agency

Ask to see four things from a past onboarding project: a field-by-field sheet like the table above, with a reason and a timing for every field; every state, including the ones the merchant can’t fix, with the exact words; the path where the owner is not the person filling in the form; and how the flow changed when a provider changed its requirements. If you are still choosing a team, our comparison of design agencies for payments companies lists cases to inspect, including onboarding flows.

What you can produce from this

One page is enough to start: the field table for your countries and business types, with compliance’s sign-off on each reason; a stage plan for sign-up, before payouts and later thresholds; copy for the four states with a deadline in each; and the owner-invite path. Add a date to recheck the rules, because both the bank rule and your provider’s requirements keep changing.