Mixbox

Mixbox coordinates customers, stores, couriers, delivery managers, and administrators into a single product. The customer uses a Flutter app available on mobile and web for location, discovering stores and products, favorites, cart, checkout, payments, order tracking, history, reviews, and support. The store gets its own Flutter app for orders, statuses, catalog, stock, coupons, schedule, invoices, receipts, and POS operations, and the courier has a separate app for availability, delivery requests, acceptance, navigation, location, payment proofs, cash collection, wallet, and history. The Laravel backend serves all of these experiences and includes the shared API, the admin panel, and the interface dedicated to the delivery manager.

The product starts from the SixAMart commercial base, but the Mixbox code adds and extends flows that substantially change the standard behavior. Checkout allows products from multiple stores in the same cart: the backend groups line items by store, validates each store separately, and creates distinct orders, with distance and delivery fee calculated per store, coupons distributed proportionally, and split tips controlled across deliveries. For multi-store digital payment, an OrderGroup is created that allows consolidated payment of the resulting orders, without each store seeing or operating on the others' products.

A major component is managing catalogs sourced from suppliers. Mixbox accepts JSON, CSV, XLS, and XLSX feeds, manual or scheduled import, preview, column normalization, batch processing, resuming from the last processed index, import logs, and updating existing products by SKU. The CategoryResolverService centralizes the same rule for both preview and import: explicit SKU mapping takes priority, followed by source-taxonomy mapping, direct matching, and, in the absence of a valid resolution, sending the product to the Uncategorized area for review. The Feed Category Manager allows simple or compound mappings, creating categories, moving existing products, ignoring sources, and synchronizing images. The implemented SKU mapping is a feed-specific or general classification rule; it is not presented in the portfolio as an automatic cross-supplier stock consolidation system, since the current code does not demonstrate that mechanism.

Orders go through operational states common to the apps: pending, confirmed, accepted, processing, handover, picked_up, and delivered, with branches for cancellation, failure, and refund. The backend checks the geospatial zone, the store's schedule and availability, quantity limits, variations, stock, coupons, fees, delivery costs, vehicle, and payment-method restrictions before saving. Stock is updated in the same transaction as the order details for an individual order, and cancellation restores the quantities. Couriers can be assigned or can accept requests, transmit their location, update statuses, confirm payment, and can upload proofs; the customer and the store receive updates via Firebase and persistent notifications.

Payments confirmed in the code include cash on delivery, digital payment, wallet, offline payment, bank transfer, and partial payment from the wallet. The deferred digital-payment flow allows creating the order as unpaid, showing it to the store immediately, and sending the payment request to the customer when the store moves the order into processing. After payment, the operational status is preserved and the store is notified. For digital orders spanning multiple stores, OrderGroup centralizes the amount and payment status.

On web, the Flutter app dynamically sets title, description, canonical URL, and Open Graph/Twitter metadata for products, stores, categories, and brands. The backend fills in the limitations of a client-rendered app with pre-rendered pages for crawlers, robots.txt, and a cached dynamic sitemap for public slugs. Technical delivery is split across four GitHub Actions workflows: SSH deploy of the backend on push to main, build and deploy for customer web plus APK, and APK build/distribution for the store and courier apps. The current workflows automate the build and distribution to the server, but are not presented as automatic App Store or Google Play publishing, and they do not include a test suite or automatic rollback.