Configurable Seller Onboarding & Verification Requirements

[DenizOner]

Proposal Summary

Mercur's existing Seller Onboarding infrastructure can be extended by developers, which is very useful. However, I believe Mercur could become significantly more flexible for marketplace operators by allowing them to configure their own seller onboarding requirements without requiring custom development for every requirement.

My suggestion is not to add a dedicated "KYC module" to Mercur. KYC would be just one possible use case for a broader Configurable Seller Onboarding & Verification Requirements system.

Why is this needed?

The information and documents required from sellers can vary significantly between marketplaces.

For example, a marketplace may require:

• An identity document from individual sellers
• A company registration certificate from business sellers
• A tax identification number from sellers in specific countries
• Special permits or certificates from sellers operating in certain product categories

These requirements may depend not only on the seller type, but also on country, product category, or marketplace-specific business rules.

Instead of having a fixed onboarding structure, it would therefore be useful if marketplace administrators could define their own requirements.

Proposed structure

For example, the Admin Panel could provide a Seller Onboarding Requirements section where an administrator could create a requirement such as:

• Name: Company Registration Certificate
• Type: Document
• Required: Yes
• Applies to: Company vendors
• Country: Germany
• Verification: Admin approval

Another requirement could be:

• Name: Identity Document
• Type: Document
• Required: Yes
• Applies to: Individual vendors
• Country: All
• Verification: Admin approval

Different field types could potentially be supported, such as text, number, date, selection, or document upload.

Verification workflow

Requirements involving documents or information could also have a verification status, for example:

• Pending
• Approved
• Rejected
• Revision Required

The administrator could review submitted information or documents and, when necessary, request a new submission while providing a reason for the rejection or revision request.

The seller should then be able to see from their panel:

• Which requirements have been completed
• Which are still pending
• Which have been rejected
• Which require revision

Controlling onboarding completion

When a requirement is marked as mandatory, the marketplace could define a rule such as:

"A seller's store cannot become active until all mandatory onboarding requirements have been completed and approved."

This would allow onboarding to function not merely as an information-collection process, but as a genuine verification workflow.

This is broader than KYC

I believe this mechanism would be much more useful if it were not limited to KYC.

For example:

• An electronics seller could be required to provide a CE certificate
• A food seller could be required to provide a food business registration document
• A cosmetics seller could be required to provide relevant product safety documentation
• A branded-goods seller could be required to provide a brand authorization document
• A company operating in a particular country could be required to provide tax or company registration documents

This would allow Mercur to support different industries, countries, and business models without hard-coding specific verification requirements into the core platform.

Relation to the existing extension system

I understand that Mercur's existing extension points can already be used by developers to implement these types of requirements. In fact, I previously raised the KYC / vendor verification requirement in #1362.

In the response to that issue, it was explained that this requirement can be implemented through Mercur's existing extension points without forking the core. I agree that this is technically a valid approach.

However, that response also raises a broader question:

Should frequently needed onboarding and verification requirements always have to be implemented as custom development by the marketplace developer, or would it add value if some of these requirements could be configured directly from the Admin Panel?

My proposal is not intended to replace the existing extension system. Instead, I see this as a higher-level capability for common onboarding and verification requirements that marketplace operators could configure through the Admin Panel.

Developers could still use the existing extension mechanism for more specialized requirements, while marketplace operators would not need custom development for every standard onboarding requirement.

Conclusion

I believe adding a configurable Seller Onboarding & Verification Requirements system could significantly improve Mercur's flexibility for marketplace operators.

In particular, being able to define which information or documents are required from which sellers, under which conditions, and whether they require administrative approval, without modifying code, could make Mercur much easier to adapt to different countries, industries, and business models.

For this reason, I would suggest considering this not as a specific KYC feature, but as a general-purpose Configurable Seller Onboarding & Verification Requirements capability.

[vholik]

Thanks for the detailed write-up. We're planning to add more extension zones to onboarding, which should make this kind of setup much easier to build on top of.