← All projectsARCHITECTURE CASE STUDY

Aquanexus

A multi-vendor marketplace running independent vendor websites from one Magento instance, with a from-scratch admin permission layer and a theme framework shared by 8 storefronts.

Business
Multi-vendor marketplace, USA
Platform
Magento Open Source, single instance
Storefronts
8 related brands via domain mapping
My focus
Admin permissions, payment flows, vendor features, theming
Magento Open SourceMulti-vendorAdmin ACLDomain mappingWebkul
storefronts on one theme framework
8
admin grids and blocks re-scoped
~40
templates in the shared theme
471
HIGHLIGHTS

Five things that set this build apart.

  • Domain-mapped vendors

    Independent vendor websites from one Magento instance.

  • AdvPermission

    A from-scratch admin ACL scoping data by website and split attribute.

  • Draft orders & QuickPay

    Admin-generated payment links with status tracking.

  • Order splitting

    One checkout divided into per-seller orders with matching shipping rates.

  • 8-store theme framework

    471 templates and 427 LESS/SCSS files in one shared base theme.

ARCHITECTURE OVERVIEW

One instance, many vendors, scoped admin.

Vendor storefronts are mapped to their own domains. In the admin, AdvPermission decides what each user can see.

StorefrontsPlatformScoped admin dataaqua_techbeyondreefroutemarinezooxaeDomain mappingMagentoOpen Source · one instanceWebkul vendor modulesOrder splittingDraft orders / QuickPayPayment remindersAdvPermissionOrdersby website & split attributeCustomersby website & split attributeProducts & CMSby website & split attributeReportsby website & split attribute8 storefronts, 1 instance471 templates · 427 style files~40 admin grids re-scoped
What makes it different

Each admin user only sees the orders, customers, products, reports and CMS for their own scope — enforced across roughly 40 rewritten admin grid collections and blocks.

WHAT THE PLATFORM DOES

What the platform does.

  • Multi-vendor

    Multiple independent vendor websites from a single Magento instance via domain mapping.

  • Admin permissions

    AdvPermission scopes orders, customers, products, reports and CMS by website/store and a custom split attribute.

  • Draft orders

    A Draft-Order/QuickPay flow letting admins generate sandbox-mode payment links with status tracking, ahead of full checkout.

  • Payment reminders

    Automated COD and bank-transfer e-mail reminders, escalating to a final notice with an attached PDF.

  • Order splitting

    One checkout divided into several orders by product attribute, with dynamic multi-shipping rate calculation.

  • Vendor features

    Customised Webkul modules for vendor registration and purchase orders; customers assigned to seller warehouses; seller mass-approve.

  • Admin & security

    Customer IP logged at registration, admin e-mails on new registrations, and customer-group visibility for CMS blocks.

  • Performance & content

    Tuned price and stock indexer batch sizes, MP4 uploads in the editor, and a Shop by Look block.

  • Theming

    A shared base theme powering 8 related storefronts.

HOW AN UNPAID ORDER IS CHASED

Reminded, then escalated.

Cash-on-delivery and bank-transfer orders are followed up automatically.

  1. STEP 1

    Order

    A customer places a COD or bank-transfer order.

  2. STEP 2

    Remind

    Automated e-mail reminders go out.

  3. STEP 3

    Escalate

    A final-notice e-mail follows, with a PDF attached.

KEY TECHNICAL CHALLENGES

Sharing one platform safely.

Many vendors, one database, one theme family.

  1. Data isolation

    Vendor sites on one instance must not see each other’s orders, customers or reports.

    Solution

    AdvPermission, a from-scratch admin ACL scoping data by website/store and a split attribute, rewriting about 40 admin grid collections and blocks.

  2. Payment before checkout

    Admins needed to take payment for orders created on a customer’s behalf.

    Solution

    A Draft-Order/QuickPay flow generating payment links with status tracking.

  3. Unpaid orders

    COD and bank-transfer orders can go unpaid.

    Solution

    A Payment Reminder module with automated reminders escalating to a final notice with a PDF.

  4. Theme scale

    Eight related storefronts needed consistent design.

    Solution

    One shared base theme — 471 templates and 427 LESS/SCSS files — powering the family.

How a vendor site is servedMany domains, one Magento instance.
VendordomainOne MagentoinstanceVendorstorefront
Payment reminder loopReminders repeat, then escalate.
UnpaidorderRemindere-mailFinal notice+ PDFrepeat reminders
How a mixed cart is splitCustomers check out once; each seller gets its own order.
MixedcartItems taggedby sellerSplit onsubmitPer-sellerorders
DESIGN DECISIONS

The options weighed, and the trade-offs accepted.

How the hardest calls were made: what else was on the table, why it lost, and what the chosen design costs.

Row-level data isolation in the admin

Magento’s ACL decides which admin screens a role can open, not which rows inside a shared grid it can see — so anyone allowed to view orders saw every business unit’s orders.

  1. Separate Magento instances per business unit — multiplies infrastructure and splits shared data
  2. Filter in the UI only — API and export paths would bypass it
  3. Filter at each grid’s data source, so every entry point is covered (chosen)
Decision

Overrode the collection classes behind each affected grid to apply website/store and split-attribute filters, tied to the admin user’s own scope.

Trade-off accepted

Couples the module to Magento’s internal collection classes, so upgrades mean re-checking each override — kept in one module so there is a single surface to test.

Splitting one checkout into several orders

A marketplace cart mixes items from several sellers, but fulfilment, invoicing and shipping rates all happen per seller.

  1. Let sellers split orders by hand afterwards — error-prone and slow
  2. Allow one seller per checkout — blocks cross-seller baskets
  3. Accept a mixed cart, tag items by seller, and split automatically on submit (chosen)
Decision

An observer tags cart items with the split attribute; on submission the order is divided into per-seller orders before the confirmation page.

Trade-off accepted

Shipping must be rated per split group, which needed a custom carrier and a plugin on shipping-information management instead of Magento’s single-shipment assumption.

TECHNOLOGIES & INTEGRATIONS

The stack behind it.

Core platform
Magento Open SourcePHPMySQLLESS / SCSS
Marketplace
Webkul (vendor registration, purchase orders, split orders)Domain mapping
Payments
QuickPayCash on deliveryBank transfer
Skills shown
Access control designMarketplace architecturePayment flowsTheme frameworks
FULL BUILD LOG

The work, piece by piece.

  1. Multiple independent vendor websites from a single Magento instance via domain mapping.

  2. AdvPermission: admin ACL scoping orders, customers, products, reports and CMS by website/store and a split attribute (~40 grid collections and blocks rewritten).

  3. Draft-Order/QuickPay flow for admin-generated payment links with status tracking.

  4. Payment Reminder module with automated COD/bank-transfer reminders escalating to a final notice with a PDF attached.

  5. Customised Webkul modules for vendor registration, purchase orders and split orders.

  6. Shared base theme for 8 storefronts: 471 templates and 427 LESS/SCSS files.

Facing a similar commerce problem?

I'm available immediately for senior Adobe Commerce roles and contract work. Tell me what you're building.

Email [email protected]LinkedInAll projects