Cursor Rules Template: Multi-Vendor Marketplace with Seller Onboarding, Listings, Commissions, Payouts and Reviews

Overview

Cursor rules configuration for a Node.js + PostgreSQL based multi-vendor marketplace provides the guardrails Cursor AI uses to generate safe, consistent code and prompts. This Cursor Rules Template covers seller onboarding, product listings, commissions, payouts, and reviews within a production-grade stack.

Direct answer summary: This Cursor Rules Template gives you a copyable .cursorrules block and a defined project structure so you can paste it into your repository and start aligning AI-assisted development for a vendor marketplace stack.

When to Use These Cursor Rules

• When starting a new multi-vendor marketplace project with seller onboarding, catalog, and payments
• When you need enforceable guidelines for AI-assisted coding, security, and data integrity
• When you want a consistent project structure and testing workflow
• When integrating payouts (Stripe or similar) and review flows into the same stack

Copyable .cursorrules Configuration

framework: Node.js (Express or NestJS) + PostgreSQL
role: Backend Engineer
context: Build a scalable multi-vendor marketplace with seller onboarding, catalog, commissions, payouts, and reviews. Cursor AI provides instructions but must not perform unsafe actions.
style: TypeScript strict; ESLint + Prettier; conventional commits
architecture: Monorepo: apps/backend, apps/frontend, infra/db
authentication: JWT-based auth
database: PostgreSQL; explicit transactions; ACID
orm: None assumed
testing: Jest for unit tests; supertest for integration tests; CI lint/test
security: Validate and sanitize inputs; store secrets in environment; restrict DB roles; CSRF protection
payouts: Stripe integration; idempotent payout endpoints; webhook validation
vendors: Vendor onboarding flow; KYC checks
products: Catalog with categories, variants, stock; listing approval
reviews: Product and vendor reviews; moderation; anti-fraud checks
anti-patterns: Do not skip payment verification; Do not trust client-side data; Do not expose vendor financials; Do not bypass rate limits

Recommended Project Structure

.
├─ apps
│  └─ backend
│     ├─ src
│     │  ├─ modules
│     │  │  ├─ vendors
│     │  │  ├─ products
│     │  │  ├─ commissions
│     │  │  ├─ payouts
│     │  │  └─ reviews
│     │  ├─ config
│     │  └─ db
│     │     ├─ migrations
│     │     └─ seeds
│     └─ test
├─ apps
│  └─ frontend
│     └─ src
├─ infra
│  ├─ payments
│  └─ security
└─ scripts

Core Engineering Principles

• Validate all inputs server-side; never trust client data
• Use explicit SQL transactions for critical operations (onboard, listing creation, payouts)
• Design with clear boundaries between modules (vendors, products, payouts, reviews)
• Adopt strong typing and defensive programming in TypeScript/JavaScript
• Instrument observability: logs, metrics, and alerting in production
• Prefer idempotent endpoints for external integrations (payouts, refunds)

Code Construction Rules

• TypeScript with strict compiler options; no implicit any
• API endpoints follow RESTful conventions (GET/POST/PUT/DELETE) for vendors and products
• Parameterize database queries to prevent SQL injection
• Keep business logic in services; avoid controllers doing heavy processing
• Define explicit data transfer objects (DTOs) for all inputs/outputs
• Store secrets in environment variables; never commit sensitive values
• Use a minimal set of external libs; avoid framework lock-in
• Do not bypass the payout flow or financial audits; keep a clear audit trail

Security and Production Rules

• Enforce TLS for all endpoints; HSTS where possible
• Validate and sanitize all user input; apply content security policies
• Use RSA/ECDSA keys rotated regularly; manage secrets with a vault
• Stripe webhook signing verification; idempotent webhook handlers
• Vendor accounts via OAuth2 or robust KYC checks; least privilege DB roles

Testing Checklist

• Unit tests for all services with deterministic fixtures
• Integration tests for vendor onboarding, product creation, and payouts
• End-to-end tests of the purchase flow with fake payment tokens
• Linting and formatting in CI; type-check in TypeScript
• Security tests: input validation and access control checks

Common Mistakes to Avoid

• Skipping server-side validation and trusting client data
• Rushed payout integration without idempotency and webhook verification
• Overexposing vendor financial data or API keys
• Underestimating test coverage for the onboarding and payout flows

Related Cursor rules templates

Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.

• Cursor Rules Template: Local Services Marketplace (Providers, Quotes, Bookings, Payments)
• Cursor Rules Template: Rental Marketplace with Property Listings, Applications, Tenant Screening, Payments and Messaging
• Cursor Rules Template: Node Express PostgreSQL Community Platform
• Cursor Rules Template: Node.js + Sequelize Car Rental Management

FAQ

Is this Cursor Rules Template specific to Node.js + PostgreSQL?

Yes. The template targets a Node.js backend with PostgreSQL, focusing on multi-vendor marketplace features such as seller onboarding, product catalogs, commissions, payouts, and reviews. Cursor AI guidance is tuned for this stack but can be adapted to related runtimes with minimal changes.

Can I customize the seller onboarding flow?

Absolutely. The rules include an onboarding module outline with KYC checks, bank account linking, and vendor status transitions. You can adapt the flow to your jurisdiction and regulatory requirements while keeping data validation and auditing strict.

How are commissions calculated and payouts processed?

The template emphasizes a transactions-based approach with explicit commission calculations and idempotent payout endpoints. Payouts are tied to orders and vendor accounts with Stripe or similar processors, and webhooks are validated to prevent duplicates.

What security measures are required for production?

Security rules cover TLS, input validation, secrets management, minimal privileges, and signed webhooks. Payout webhooks are validated and replay-protected; vendor data access is restricted by roles and scopes.

How do I test the payout and payout-risk flows?

Use integration tests with mock payment tokens and end-to-end tests around the payout process. Verify idempotency keys, webhook handling, and error scenarios across all payout paths.