DEV3 Technologies home

DEV3 Stallora – Multi-Vendor Delivery Marketplace Laravel Script with Customer, Shop & Rider Flutter Apps

A self-hosted city marketplace on Laravel 12, Filament 4 and Flutter: one cart split into a package per shop, delivery zones with auto and manual dispatch, rider apps with pick-up and drop-off codes, shop wallets and payouts, and a REST API.

by DEV3 TechnologiesVerified Author(0) 0 sales 0 viewsUpdated 04 Nov 2026

Video tour. Pick a section below to browse 114 screenshots in 44 sections.

Stallora is a city delivery marketplace that you host yourself. Neighbourhood shops sell through one storefront, a customer's cart splits into one package per shop, and a rider delivers each package. DEV3 built it on Laravel 12 and Filament 4, with three Flutter apps for customers, shops and riders. The demo city, Port Avalen, is entirely fictional.

No live demo: the 114 grouped screenshots (72 web, 42 from the apps) and the video tours show the storefront, the three Filament panels and all three apps. Install it with the demo data to try every role on your own server.

Follow one order

  • Browse and cart. Search and filter across all shops, with variants, wishlist and compare. The cart splits by shop, and each package gets its own delivery fee, tax, commission and ETA.
  • Checkout. The customer drops a pin on a map; the address must fall inside a delivery zone. A tip, then card, wallet or cash on delivery.
  • The shop accepts. Each shop sees its package on an order board, picks a prep time and marks it ready. Rejecting a package refunds it automatically.
  • Dispatch. Auto dispatch offers the job to the nearest free online rider, re-offers after a timeout, and flags the job for manual dispatch after the maximum number of attempts. Admins can also assign, reassign or retry from the live dispatch map.
  • Pick-up and drop-off. The rider confirms pick-up with the shop's 4-digit code and the drop-off with the customer's 4-digit code, a photo, or both (a setting).
  • Money. On delivery the shop's earning is held for a set number of days, then released. The rider is paid from the platform's delivery wallet, and cash-on-delivery money is tracked until an admin settles it.
  • Afterwards. Verified-buyer reviews with shop replies, a 1 to 5 rider rating, returns and refunds, and chat between customer and shop.

Delivery zones and maps

  • A zone is a circle or polygon with a base fee, a fee per extra kilometre, a free-over threshold, a minimum order, rider base pay, rider pay per kilometre and a surge multiplier.
  • The maps are drawn by Stallora itself, so no map provider or key is needed. They show a stylised city, not real streets, and there is no turn-by-turn navigation.
  • Live tracking uses a simulated route that real GPS replaces when the rider app has sent a position in the last 30 seconds.

Admin console

  • A dashboard with sales, commission, orders by status and a live delivery map; the dispatch board; deliveries, riders (approve, suspend, settle COD cash) and zones.
  • Shops with a four-document KYC review, catalogue moderation, commission rules (shop, category tree, global, then the default setting), coupons, tax rates, reviews and refund requests.
  • Wallets, a double-entry ledger and payouts for shops and riders: request, approve, mark paid with a reference, or reject.
  • Reports for sales, delivery performance and top shops and riders; roles with a permission matrix (admin, manager, dispatcher); an audit log; and settings for dispatch, proof of delivery, COD limits and the storefront.

Seller centre and customer account

  • The seller centre at /vendor has a dashboard, an order board, products with variants and stock, earnings and payouts, review replies, chat, analytics, shop hours, a pick-up pin and an open toggle.
  • Shops apply at /sell and upload documents; riders apply on /ride or through the API.
  • The customer account has tracking with a live map and delivery code, returns, reviews, a wallet with top-ups, saved addresses and chat.

Three Flutter apps

  • Customer: onboarding with a 3D hero, home, search, product, shop, split cart, checkout, live tracking, orders, reviews, wallet and chat.
  • Vendor: dashboard, order board with accept, reject and ready, pick-up code, products, stock editor, earnings, payouts, reviews and chat.
  • Rider: go online, a job offer with a countdown, a map to the shop and then the customer, pick-up code, drop-off with code and photo, COD collection, earnings and payouts.
  • All three run in a built-in demo mode out of the box, have light and dark themes and Arabic right-to-left layouts, and connect to your site by turning demo mode off and setting the API base URL.

API and platform

  • A REST API under /api/v1 on Sanctum, with interactive docs at /api/docs and an OpenAPI file. Tokens are scoped per app, so a rider token cannot reach shopping or chat routes.
  • Web installer, English and Arabic (RTL), dark mode, a product site at /platform with a lazy-loaded 3D city, and money stored as integer minor units.
  • Payment drivers for Stripe, PayPal and Razorpay, with a simulated gateway as the default. Push and SMS drivers are included too.

Quality checks

  • 200 Pest tests (1428 assertions), Larastan level 6 with no errors, Pint clean, and a headless-browser smoke run over 152 pages with 5 happy paths.
  • Public JS and CSS total 38.7 KB gzipped against a 180 KB budget; the three.js scene loads lazily.
  • The packaged zip was unzipped and installed through the /install wizard with demo data, and a secret scan came back clean.
  • The three Flutter apps passed the programme's app gates, including a debug Android build.

Good to know

  • Real payment gateways were not tested live. Stripe, PayPal and Razorpay drivers are included, but they were not run against real or sandbox accounts. The simulated gateway is the default and approves any payment, so switch to a real gateway and test it in its sandbox before you take orders. Once a real gateway is set, leftover simulated payments are ignored.
  • SMS and push were not tested with live accounts. Push defaults to a simulated driver that only fills the in-app inbox; SMS defaults to the log driver. FCM, APNs and SMS credentials are accepted in settings, but nothing was sent through them.
  • The apps were not tested on physical devices. They were checked with automated tests and builds only. Before publishing you must add real push, a secure token store, real device GPS and a camera plugin for proof photos on the rider app, plus your own app ids and icons.
  • The last unit can be oversold. Stock is taken when an order is paid, not when it is placed, so two unpaid orders can both pay for the last unit. Stock then goes negative and the shop must reject one package, which refunds automatically. This comes from reading the code and has no test.
  • Payouts record what is owed. Stallora does not move money to bank accounts; you send the transfer and enter its reference.
  • Maps are stylised. No street data and no turn-by-turn navigation. Without the rider app sending positions, tracking is a simulation.
  • Cron is required. Dispatch re-offers and earnings releases run from the scheduler.
  • A clean install has no tax rates, and rider applications do not collect ID or vehicle documents; add those checks to your own process.
  • Arabic: English and Arabic ship in the box; some demo data, such as product names, stays in English.
  • Lighthouse scores were not measured.
#multi-vendor#delivery#marketplace#rider-app#flutter#dispatch#delivery-zones#vendor-payouts#cash-on-delivery#laravel#filament#php-script

How it's built

Architecture, stack, key decisions and the quality gates DEV3 Stallora passed before release.

The engineering behind Stallora: Laravel 12 and Filament 4 on a shared core, packages split per shop, zone-based delivery fees, nearest-rider dispatch with offers, code-confirmed hand-offs, a double-entry ledger with holds, and three Flutter apps that share the same API.

The problem it solves

A delivery marketplace is a marketplace plus a logistics business. One basket becomes several packages, each with its own shop, prep time, tax and delivery fee, and each needs a rider who may decline. Money moves at different moments: the customer pays once, the shop earns only when its package is delivered, the rider earns per job plus tips, and cash-on-delivery leaves the rider holding cash that belongs to the platform. A rejected package must refund only its own share. An abandoned payment must not lock stock or burn a coupon. And the same rules have to hold for the website and for three mobile apps that act on behalf of three different kinds of user.

Architecture and approach

Stallora is a Laravel 12 application with Filament 4 panels at /admin and /vendor, a Blade storefront with a customer area at /account, and a versioned REST API under /api/v1. The Flutter apps call the same API.

Packages, zones and fees

  • One package per shop. The cart groups lines by shop; each package carries its own delivery fee, tax, commission and ETA.
  • Zones as data. A zone is a circle or polygon whose settings hold the base fee, fee per kilometre, free-over threshold, minimum order, rider pay and a surge multiplier. A drop-off outside every zone cannot check out.
  • Commission resolution. The shop rule wins, then the category tree, then a global rule, then the default setting.

Dispatch and hand-off

  • Offers. Auto dispatch offers a job to the nearest free online rider inside the search radius, expires the offer after a timeout and re-offers; after the maximum attempts the job is flagged for the dispatch board.
  • Codes. Pick-up needs the shop's 4-digit code, drop-off the customer's 4-digit code, a photo, or both.
  • Tracking. A deterministic simulator builds the rider-to-shop-to-door route; real GPS replaces it when the rider app is reporting. The maps are drawn by the app itself, so no map provider is involved.

Money

  • Integer minor units on a double-entry ledger from the shared DEV3 core, with separate wallets for shops, riders (earnings and cash), customers and the platform.
  • Settle on delivery. A delivered package credits the shop net of commission and holds it for the hold period; a scheduled command releases it. Rejections and returns reverse their own share only.
  • One money gate. Checkout confirmation takes stock and coupon use, ignores simulated payments once a real gateway is configured, and refunds payments that land on a cancelled order or pay an order twice. Unpaid card orders are cancelled after 60 minutes.

Apps and access

  • Scoped tokens. Customer, vendor and rider tokens carry an app ability, never a wildcard, so a rider token cannot reach shopping or chat routes. Rate limits use named limiters.
  • Demo mode. Each Flutter app can run on an in-memory backend whose routes mirror the API, which is how the screens in the gallery were captured.
  • Performance. The live map is a canvas that only runs on screen at a capped frame rate, and three.js scenes load lazily; phones defer 3D until the first touch or scroll.

Quality gates and results

Stallora 1.0.0 passed the seven release gates of the DEV3 Laravel tooling, run against the packaged build:

  • Static analysis: Composer validation, Pint clean, Larastan level 6 with no errors, and a syntax check of 421 PHP files.
  • Tests: 200 Pest tests with 1428 assertions.
  • Front-end budget: 13.1 KB of JS and 25.6 KB of CSS gzipped on the public page (38.7 KB against a 180 KB budget), with the three.js chunk loaded lazily.
  • Seeding: the demo and empty seeders run on MySQL 8 and SQLite.
  • Browser run: 152 pages and 5 happy paths in a headless browser.
  • Installer: the zip was unzipped and installed through the web wizard, then the admin signed in.
  • Secret scan: clean.

The three Flutter apps passed the programme's app gates, including a debug Android build. Real payment gateways, SMS and push were not run against live accounts, and the apps were not tested on physical devices. One known gap is documented: two unpaid orders can both pay for the last unit of stock.

Tech stack

Area Technologies
Backend Laravel 12, Filament 4 panels, Livewire 3, Sanctum scoped tokens, Scheduler and queue, Reverb (optional)
Delivery engine Zone fee calculator, Nearest-rider dispatch, Offer expiry and re-offer, Pick-up and drop-off codes, Simulated route tracker
Money Double-entry ledger, Wallets per role, Holds and payouts, Commission resolver, Refund service
Mobile Flutter, Shared DEV3 Flutter core, Customer app, Vendor app, Rider app, Offline demo mode
Frontend Blade, Tailwind CSS, Vite, three.js (lazy), Canvas live map

Inside the build

Storefront home: Neighbourhood shops, one cart and delivery within the hour, with a 3D product orbit in the hero. Storefront home — Neighbourhood shops, one cart and delivery within the hour, with a 3D product orbit in the hero.

Categories and flash deals: Shop by aisle, with a live countdown on today’s offers. Categories and flash deals — Shop by aisle, with a live countdown on today’s offers.

Guides & articles

Practical guides and engineering write-ups for DEV3 Stallora.

Building a local delivery marketplace: what the rider side changes

Last updated
Building a local delivery marketplace: what the rider side changes: DEV3 Stallora

A shop marketplace ends when the order is paid. A delivery marketplace only starts there. The moment riders enter the picture you need delivery zones, a way to find a rider, proof that the parcel changed hands, and a plan for the cash a rider collects at the door. This guide follows one order through DEV3 Stallora, a self-hosted delivery marketplace on Laravel 12, Filament 4 and Flutter, and points out where each of those four things changes the design.

The Stallora multi-shop cart: one package per shop, each with its own delivery fee

Step 1: the cart becomes several jobs

The customer sees one basket. Behind it, each shop's lines form a package with its own delivery fee, tax, commission and ETA, and each package becomes a separate delivery. That matters because the shops prepare at different speeds and the packages may travel with different riders.

Stallora computes the fee from a delivery zone, not from a flat rate. A zone is a circle or polygon with a base fee, a fee per extra kilometre, a free-over threshold, a minimum order, rider base pay, rider pay per kilometre and a surge multiplier. At checkout the customer drops a pin on a map and the address must fall inside a zone, so you never accept an order you cannot deliver.

Checkout with a map pin, tip and card, wallet or cash on delivery

Step 2: the shop sets the clock

Each shop gets its package on an order board and chooses a prep time when it accepts. By default dispatch starts at acceptance, so the rider arrives as the shop finishes packing; a setting moves it to the moment the shop marks the order ready. If a shop rejects, only that package is refunded, including its share of delivery fee, tax and tip.

Accepting an order in the seller centre by choosing a prep time

Step 3: finding a rider

Auto dispatch offers the job to the nearest free online rider inside the search radius. The offer expires after a timeout and goes to the next rider. After the maximum number of attempts the job is flagged for a person. The dispatch board then shows every zone, shop, rider and open job on one map, and ranks riders by distance to the shop with busy and offline riders marked.

Two practical notes. The scheduler must run, because offers expire and re-offer from a scheduled command. And the maps are drawn by Stallora itself, so there is no map provider to pay for, but they show a stylised city and not real streets.

The admin live dispatch map with zones, shops, riders and open jobs

Step 4: proof that the parcel moved

Pick-up is confirmed with the shop's 4-digit code. Drop-off needs the customer's 4-digit code, a proof photo, or both, depending on a setting. The customer sees the same code while following the rider on a live map.

Order tracking with a live map, ETA and delivery code

Step 5: money, in the order it really moves

  • The shop's earning is credited when its package is delivered, then held for a configurable number of days before it can be withdrawn.
  • The rider earns a base amount plus distance pay and tips from the platform's delivery wallet. If a free delivery cannot cover a rider's pay, the shortfall is booked from commission as a visible entry.
  • For cash on delivery the rider's cash wallet goes negative by the amount collected, and an admin settles it later.
  • Payouts for shops and riders are requests that an admin approves and marks paid with a reference. Stallora records what is owed; it does not send bank transfers.

The seller earnings wallet with available balance, holds and a statement

See it in action

The video shows the flow from a two-shop cart to a delivered order and the money that follows.

Video tour of Stallora

What to check before you rely on it

  • Payments: Stripe, PayPal and Razorpay drivers are included but were not run against live or sandbox accounts. The default simulated gateway approves any payment, so change it before launch.
  • Push and SMS: drivers exist; nothing was sent through real services.
  • Apps: the customer, vendor and rider apps run in a demo mode and were tested with automated tests and builds, not on physical devices. Real push, secure token storage, device GPS and a camera plugin for proof photos still need to be added.
  • Stock: stock is taken when an order is paid, so two unpaid orders can both pay for the last unit. The shop then rejects one package and it is refunded automatically.
  • Quality checks: 200 Pest tests, Larastan level 6 with no errors, and a headless-browser run over 152 pages.

Frequently asked questions

The complete source code (version 1.0.0) as a download from your account, with the setup and usage guides shown on this page. You can modify the code to suit your product.

Buying guides: Laravel scripts with Filament panels and a web installer · Next.js or Laravel for a SaaS script?

More from this author

View all

Related in Web Scripts & Software

View all