Seller onboarding in a B2B marketplace should answer three separate questions: who is operating the account, which business they represent and what they are authorised to do. Identity verification can help with the first question. Business checks and your own approval process are needed to address the others.
That distinction matters when the marketplace handles supplier listings, purchase orders or payout details. A genuine identity does not prove that someone may change a company’s bank account. A registered business does not prove that every account using its name is an authorised representative.
This guide is commissioned content for Didit. It uses the platform as one implementation candidate and develops an editorial workflow, without claiming legal advice, a live deployment or measured fraud reduction.
Model the seller as more than a user record
An ordinary application often begins with a users table and an email address. A B2B marketplace usually needs a relationship between a person, an organisation and a role. Keep those concepts separate so one person can work for several organisations without copying their identity record into each profile.
A seller organisation may have a billing contact, catalogue editor and authorised administrator. The role that uploads product descriptions should not automatically inherit permission to alter payout instructions. Write the permissions before selecting a verification package; otherwise the vendor’s available fields can end up dictating your business model.
Use stable internal identifiers for each person and business. Store the association with the verification session rather than relying on a display name. Names can change, translations differ and several companies can have similar trading names. Your operational record should make it clear which entity was actually reviewed.
Decide where verification enters the journey
Requiring all checks at the first visit can make onboarding unnecessarily demanding. Waiting until after a seller has accepted an order can create a different problem: the marketplace has allowed activity before it knows whether the account may perform it.
A proposed sequence is to let a seller explore requirements, create an account, submit company details and then complete the checks needed for activation. Keep restricted actions unavailable until the relevant decision is complete. The sequence should follow your business and legal requirements, not a universal template.
Tell the seller what they will need before capture begins. Explain whose documents are required, whether another representative must participate and how they can continue later. A business onboarding process often involves several people, so a one-sitting mobile flow may be an unrealistic assumption.
Separate KYC, KYB and representative authority
Didit’s business-verification documentation describes business checks and related ownership information. That makes it a candidate to investigate when the seller is a legal entity. Coverage, available registry data and the configured workflow still need to be checked for the jurisdictions you serve.
The marketplace’s own policy must explain how a verified person becomes associated with that business. An invitation from an existing administrator, contractual evidence or another approved process may be required. Do not let a matching company name alone establish the relationship.
The AWS Marketplace KYC documentation illustrates how a real marketplace can distinguish business, individual and regional requirements. It is evidence about AWS’s process, not a rule that automatically applies to your marketplace. Use it to recognise the kinds of dependencies an onboarding design may need to handle.
Design a case file the operations team can use
A seller case should show what was requested, what has arrived, what remains unresolved and who owns the next action. Avoid a single red “failed” label for situations ranging from a blurry document to a discrepancy in company records.
A useful internal view separates these dimensions:
| Dimension | Example question |
|---|---|
| Person | Has the account operator completed the required identity check? |
| Business | Does the submitted entity match the business evidence? |
| Relationship | What supports this person’s authority to act? |
| Permissions | Which marketplace actions are currently enabled? |
| Review | Who must resolve the remaining discrepancy? |
These are proposed application states, not promised Didit fields. Map them to the evidence and capabilities available in your selected configuration. If a necessary piece of evidence does not exist, keep the case unresolved instead of inventing certainty through a green status icon.
Make integration events safe to repeat
The account system should tolerate repeated notifications without creating duplicate seller profiles or sending contradictory messages. Give each external session a stable association and record the decision changes relevant to your own workflow.
A browser redirect is useful for returning the person to the marketplace, but it should not be the only proof that a check completed. Reconcile the provider’s trusted result with the internal seller record. If the notification is delayed, show a truthful waiting state and a way to return later.
Plan for changes after approval. A new representative, ownership change or request to modify sensitive details may require another review. The appropriate trigger depends on your business requirements; the important design point is that an earlier verification should not become an unlimited lifetime permission.
Give reviewers a bounded task
The reviewer needs a decision question, not a folder of unexplained documents. For example: does the submitted representative evidence satisfy the marketplace’s current activation policy? Define what the reviewer can approve and when they must escalate.
Log the reason for a manual override and the policy version used. A later colleague should be able to understand the decision without reconstructing an informal conversation. If the vendor provides a review interface, check which responsibilities remain in your marketplace’s back office.
Do not expose raw identity evidence to every support agent. A support role may only need the case reference, current stage and permitted next step. More restricted roles can handle evidence when necessary. That division also makes training clearer because staff know what they can resolve themselves.
Test seller scenarios rather than isolated API calls
Construct a small acceptance set covering a sole trader, a business with several representatives, an incomplete application and a seller returning after a delay. Include a person who passes identity verification but cannot establish authority for the company.
Test changes to a company’s display name and contact details without silently changing the verified legal entity. Check that an administrator cannot grant themselves sensitive permissions simply by editing a profile field. These tests examine your application’s controls rather than asking a vendor to solve every business decision.
Measure time to activation separately from automated check duration. Waiting for another company representative may account for most of the elapsed time. That is a workflow issue that a faster document response alone cannot fix.
Handle representatives leaving the seller organisation
An onboarding design also needs an offboarding story. If a verified representative leaves the seller company, their earlier identity result should not keep their marketplace permissions alive indefinitely. The account relationship and the evidence record serve different purposes.
Define who can remove a representative, how a replacement is appointed and what happens if the only administrator is unavailable. These recovery scenarios should not rely on an unverified email asking support to transfer control. The marketplace needs an approved procedure appropriate to the sensitivity of the account.
Keep a history of the relationship changes without presenting an old role as current. A reviewer investigating a transaction may need to understand who was authorised at the time, while ordinary account screens should show the permissions that apply now. This distinction becomes especially useful when a seller has several branches or business units.
Include representative changes in acceptance testing. They often expose assumptions that a first-time registration demonstration cannot reveal, particularly where one identity is linked to multiple organisations.
Define the handover before launch
The implementation is ready when product, operations and support agree on the same states. Record the activation policy, evidence requirements, review owner, escalation path and vendor configuration. Keep commercial terms and retention choices with that record.
For related application-design decisions, consult the Nova Script Solutions blog. The aim is a seller onboarding process that your team can explain and maintain. Didit or another verification service can supply part of the evidence, while your marketplace remains responsible for deciding what that evidence permits a seller to do.