Vendor management & payments system for Hind social
How we designed the KYC and payout foundation that unlocks paid events, store, and services on a multi-entity social platform.
ROLE
Product designer & manager ( Founding )
SCOPE
Vendor onboarding, business details, Hind platform team ops, monetization gates, Payments for consumers
TEAM
Hind Social - Development , Business & marketing team
Hind Social is a multi-layered community platform (Philosophy → Community → Organization). Communities already run events, content, and engagement — but selling and accepting payments requires a regulated identity: business details, bank/UPI, and a signed vendor agreement.
Without that identity, paid ticketing, future store listings, and services would risk fraud, failed payouts, and compliance issues in India.
Product north star (epic vision): Verified vendors can list products, offer services, run paid events, and receive weekly payouts through Hind’s payment stack.
What we designed first (foundation): Vendor as a monetization identity — not a public shopfront. Verify once → unlock commerce surfaces across the platform.
Some parts of the project remain confidential and cannot be shared due to privacy and security protocols
Motion GIF made on Figma motion
The problem?
Hind Social was evolving from a community platform into a platform where communities could also offer paid experiences and services.
Until this point, the platform had no paid features or vendor infrastructure. Community and organisation admins could build their presence and engage their members, but there was no system that allowed them to become sellers, collect payments, manage transactions, or offer paid events, products, and services.
This meant we had to design the entire foundation of the vendor ecosystem — from understanding what it means to become a vendor, to KYC, payment setup, verification, approval, and ongoing vendor management.
How?
How might we build a simple and trustworthy vendor onboarding system from scratch, enabling communities and organisations to become payment-ready and eventually sell events, products, and services on Hind Social?
We had to build the vendor ecosystem from scratch while working within Cashfree’s KYC and payment requirements. The experience needed to make a largely third-party-driven verification process feel clear and guided for communities.
Define the vendor model: What does becoming a vendor actually mean within Hind Social?
Create a guided onboarding journey: Turn complex KYC and payment requirements into understandable steps.
Build trust around sensitive information: Explain why information is required and how it will be used.
Handle payment setup: Support bank/UPI details and make gateway errors understandable.
Create verification states: Clearly communicate what is submitted, verified, pending, rejected, or requires action.
Build the admin control layer: Give Hind Social admins tools to review, approve, hold, and manage vendors and configure platform fees.
Design for future monetisation: Create infrastructure that could eventually support paid events → services → products → causes/donations.
The design
I designed the end-to-end vendor ecosystem for Hind Social, covering the complete journey from verification to becoming payment-ready.
The solution included three interconnected layers:
Community & Organisation Experience — vendor registration, KYC, bank/payment setup, verification status, and the steps required to become eligible to sell.
Hind Social Admin Experience — a vendor management system for reviewing applications, managing verification, approving or holding vendors, and configuring platform-level controls.
Communication System — transactional emails and notifications triggered throughout the journey, keeping vendors informed about submissions, verification progress, approvals, rejections, and required actions.
Constraints that shaped the UX
You can call Hind Social like a marketplace for other communities to monetise. We took reference from products like Shopify, Whop , Mighty networks,etc
Regulatory Compliance (India KYC): Required dynamic data validation tailored to entity types (Proprietorship, Private Limited, NGO), capturing mandatory Phone, Email, Business Category, GSTIN, and PAN parameters.
Payment Gateway API Contracts (Cashfree): Demanded real-time UI state synchronization to mirror gateway sub-merchant statuses (Pending, Active, Bank Verified, Rejected) without confusing technical jargon.
Strict Entity Hierarchy: Monetization capabilities are restricted strictly to Communities & Organizations, while Hind Social platform act purely as regulatory approval body.
Asynchronous Legal Agreement Workflow: Legal compliance required signed physical/digital agreements, but requiring instant file uploads on form submission caused severe funnel drop-off.
Downstream Feature Dependencies: Event publishing engines and custom layout tools directly query the platform state (
isActiveVendor), necessitating graceful feature-gating states.
This is visualised using ChatGPT
Design principles we used
''''''''''''''''''''''''''''''''
Progressive Disclosure Over Cognitive Overload: Divided exhaustive compliance forms into three digestible steps—Personal & Business Info → Financial Payouts → Agreement Contracts—reducing drop-off and form fatigue.
Status as a Product Surface: Replaced dead-end submission confirmation screens with an active Business Details Dashboard featuring live section badges and actionable alert banners.
Value-Oriented Microcopy: Replaced intimidating corporate language (“KYC Portal”, “Compliance Registration”) with empowering value proposition messaging (“Monetization & Payments”, “Verify to Start Selling”).
Local Failures, Isolated Recovery: Designed section-level verification states. Editing payout details re-evaluates bank information without invalidating previously verified business credentials.
Educational Feature Gating: When blocking unverified creators from creating paid events, clearly explain the precise verification steps required alongside an immediate action trigger.
Discovery & Intent Activation
Community admins encounter an empty-state illustration inside Monetisation & Payments highlighting unlocked outcomes: paid ticketing, digital store creation, and automated weekly payouts.
The existing communities also get notified via email, SMS, Whatsapp & in-app notifications.
In existing flow of event creation, the creators see the paid events notification
Feaure is live email to community owners and admin team
Vendor Setup — Community / Organisation Owners
Admins complete the vendor setup by providing their business identity, payment details, and required verification documents. This includes business information, GST/PAN where applicable, bank account or UPI details, and the Hind Social vendor agreement. The flow validates payment details through Cashfree where applicable and clearly surfaces any errors or missing information before submission.
Legal Agreement Review
Presents the vendor terms. Document upload can be deferred on initial submission to eliminate drop-off while waiting for legal document signing.
Become a vendor flow for communities
After Submission
Admins land on Business Details, which becomes the central source of truth for their vendor account.
It shows:
Overall verification status
Business / personal information
Payment details
Documents & agreement
Sections requiring action
Each section can be edited and re-submitted for re-verification where required.
After the vendor request is done , Hind Social team send them the custom vendor tri-party agreement
Hind social admin team review
On the platform side, Philosophy admins review the submitted vendor information and agreement.
Once everything is approved, they Activate the Vendor.
Activation unlocks the ability for the community or organisation to create paid offerings and accept payments.
Hind Social team viewing vendor details when the communities apply
Hind Social admins could configure custom platform fees and settlement rules for each vendor, giving the platform granular control over its monetisation model.
Hind Social admins could configure settlement rules independently for each monetisation module. This allowed different business models to have different payout timelines.
For each module , Events, Services, or Causes - the platform could define:
Post-transaction: Settle after
Xdays from the transaction.Post-completion: Settle
Xdays after the event, service, or campaign is completed.Immediate: Settle the vendor instantly at the time of the transaction.
This gave Hind Social granular control over vendor payouts while allowing each module to follow a settlement model suited to its own lifecycle.
Hind Social team editing convenience fees, platform fees , settlement period for the events module for a community
Hold & Rejection States
On Hold
New orders and bookings are stopped
Existing paid offerings can be hidden where required
Vendor remains accessible for review and reactivation
Rejected
Admin sees the reason for rejection
Only the relevant information needs to be corrected
Admin can resubmit the affected section rather than restarting the entire process
Design decisions
Decoupling Merchant Identity from Store Creation
Rather than bundling store setup with KYC, we decoupled the architecture so that store, ticketing, and services consume a shared platform flag (isActiveVendor).
Impact: Avoided building premature marketplace UI before established payment trust rails were validated.
Deferred Legal Document Uploads
We permitted initial KYC submission without immediate legal agreement uploads, while maintaining strict activation blocks until platform admin review.
Impact: Prevented drop-off from creators who didn't have signed PDFs readily available during initial setup.
Make Cashfree the Verification Source of Truth
Since KYC and payment verification depended heavily on Cashfree, we designed the experience around a third-party verification state rather than pretending verification happened entirely within Hind Social. Vendor status could be fetched and reflected back into the Business Details experience.
Impact: Gave admins visibility into an otherwise opaque external process while keeping Hind Social's vendor status aligned with the payment gateway.
Configure Commercial Rules per Module
Events, Services, and Causes don't necessarily have the same transaction lifecycle. We therefore designed the admin system to configure fees and settlement rules independently for each module—including platform/convenience fees and settlement after transaction, after completion, or immediately.
Impact: Gave Hind Social the flexibility to evolve its monetisation model without redesigning the vendor system every time a new module or business rule was introduced.