An AI marketplace is not an online shop with a chatbot added to it. It connects buyers, several sellers, products or services, payments, payouts, fulfilment and the operator. It may also include a website, mobile apps, desktop software, search, recommendations and administration. Without one shared state model, these parts quickly create duplicate orders, unclear fees and delivery states nobody can explain.
The most important architecture work happens before the interface: Who sells? Who accepts the payment? Who receives which payout? Who owns the customer relationship? Which state is authoritative when payments, the seller portal and fulfilment report different information?
Separate marketplace software from the marketplace business
TEX8 can develop and support the software. The client remains the operator of its business model and signs its own agreements with sellers, payment providers, hosting and fulfilment partners. This separation matters because technology alone cannot determine merchant-of-record, tax, KYC, consumer-right or product-liability questions.
| Layer | Typical responsibility | Technical representation |
|---|---|---|
| Marketplace operator | business model, seller agreements, commissions, support and rules | roles, settings, approvals, settlement and audit |
| Payment provider | payment processing under the provider agreement | connected accounts, payment references, webhooks and payout status |
| Seller | products, pricing, stock, service and possibly shipping | seller portal, catalogue, orders and fulfilment handoff |
| Fulfilment partner | warehouse, pick and pack, shipping and events | order contract, inventory, tracking, returns and failure queue |
| TEX8 | agreed software development and technical operations | web, apps, desktop, Rust services, integrations, tests and monitoring |
The four core objects of a multi-seller marketplace
A dependable model separates cart, buyer order, seller order and fulfilment order. One buyer order may contain line items from three sellers, producing three seller orders and perhaps several shipments. Refunds, commissions and payouts must therefore remain traceable at line-item level.
- Cart: a mutable purchase intent with current price and availability validation.
- Buyer order: one consistent record for the buyer, payment and overall state.
- Seller order: the items, fees and responsibilities relevant to one seller.
- Fulfilment order: concrete warehouse, shipping and tracking work.
This separation prevents one delayed parcel from corrupting every other item or a partial refund from cancelling the entire order.
Draw the money flow before integrating payments
Stripe Connect is designed for platforms and marketplaces and provides connected accounts, payment routing and payout models. Depending on the model, charges may belong directly to a connected account or be processed by the platform before transfers. A Revolut Merchant model can also be evaluated against the country, account, seller structure and available interfaces.
The framework cannot decide the provider model. Before integration, answer:
- Who appears to the buyer as the seller?
- Who bears payment, refund and dispute costs?
- When may a seller payout be released?
- How are marketplace commission, tax and provider fee represented?
- What happens on partial cancellation, partial delivery or a negative balance?
The operator pays provider fees, merchant costs, hosting and usage-based services through its own agreements. TEX8 does not silently absorb them.
Saved cards without a card database
Users can receive saved payment methods when supported by the provider and payment model. Sensitive card numbers must not be stored in the marketplace database. The provider stores them in its designated system; the marketplace keeps customer and payment-method references, display details and their ownership relation.
Every read and use must be bound to the current session, tenant and provider customer. Logs must not contain secret keys, full payment data or unprotected provider responses.
USDT and USDC are an additional payment rail
Stablecoins can serve particular audiences, but orders, refunds, exchange timing, networks, wallet attribution, accounting and permitted regions still require decisions. A stablecoin integration should be modelled as a separate provider flow with confirmed on-chain events, idempotency and manual review for mismatches.
Fulfilment needs confirmed events
A marketplace must not display an order as shipped merely because an API call was attempted. Only confirmed acceptance or a later fulfilment event changes operational state. Repeated webhooks and timeouts are normal, so every handler must be idempotent.
- stable internal and external order identifiers;
- inventory and reservation per seller, product and warehouse;
- handoff of only required address and line-item data;
- separate accepted, picked, shipped, delivered and returned states;
- a visible queue for failed or conflicting events;
- push and email triggered only by confirmed state changes.
Web, React Native and Electron share contracts
The website provides public discovery and access without installation. React Native offers one mobile foundation for iOS and Android with push, camera, biometric approval or deep links. Electron can provide a full desktop workflow for operators, sellers or power users. All surfaces must use the same API contracts, roles and order states.
Business logic such as prices, commissions, payout approval and permissions does not belong in three clients. It remains in Rust services behind versioned contracts, allowing surfaces to evolve without reinventing the money flow.
Where AI creates practical value
AI can improve discovery, onboarding and operations, but it should not execute unchecked financial actions. Useful first capabilities include semantic product discovery, structured seller-data intake, support using approved knowledge, translation drafts and warnings about incomplete catalogue data.
Recommendations still obey hard business constraints: availability, region, price, seller status and permissions apply before semantic ranking. An AI assistant receives only actions allowed for the user's role.
A staged launch plan
- Model: document roles, money flow, commissions and fulfilment responsibility.
- Pilot: one category, a few verified sellers and one payment model.
- Operations: close refund, support, inventory, shipping and review queues.
- Mobile and desktop: add surfaces on top of stable marketplace contracts.
- AI and scale: expand search, recommendations and automation from real requests.
Next step
Our AI marketplace development page covers web, React Native, Electron, payments, fulfilment and the operator backend. The marketplace case study shows these modules in a concrete system. For discovery and agents, review semantic search development.