E-Commerce Platform App Development

Building an e-commerce platform (a system that enables other businesses to sell) is an order of magnitude more complex than building a single-brand storefront. Every feature must work for merchants with different product types, fulfilment models, tax jurisdictions, and compliance requirements, while the platform operator manages onboarding, revenue sharing, dispute resolution, and fraud at scale. Scrums.com builds dedicated engineering teams for marketplace operators, platform-as-a-service companies, and enterprises building headless commerce infrastructure for multiple brands or resellers.

Multi-Tenant Platform Architecture and Merchant Onboarding

Multi-tenancy in an e-commerce platform is not just a database question: it is an architectural decision that propagates through every layer of the system.

Row-level security (RLS) on a shared PostgreSQL schema covers most platform use cases: each merchant's data is isolated by a merchant_id column, a session variable is set to the authenticated merchant at connection time, and RLS policies enforce that all queries are automatically scoped. The CI test suite includes an RLS audit step that verifies no query can retrieve another merchant's data regardless of how the application code constructs it.

For enterprise-tier merchants with contractual data isolation requirements (common in regulated industries), a schema-per-tenant pattern provides stronger guarantees: each merchant's tables live in a separate PostgreSQL schema with no shared tables. PgBouncer pools connections across schemas so that provisioning a new merchant schema does not require a new connection pool.

Merchant onboarding automation is a first-class workflow: a Temporal-orchestrated onboarding sequence handles identity verification (KYC via a verification provider), bank account validation, contract signing (DocuSign/PandaDoc webhook), payment method setup, and catalogue import. Each step is retryable and produces an audit trail. Failed onboarding steps transition the merchant to a pending_remediation state with a support ticket created automatically; they never silently fail.

Marketplace Payments and Revenue Splitting

Marketplace payment architecture is fundamentally different from single-seller e-commerce because the platform operator collects funds and distributes them to multiple merchants, which creates money transmission obligations in most jurisdictions.

The cleanest architecture uses a payment platform with native marketplace support (Stripe Connect, Adyen Marketplaces): the buyer pays into the platform's escrow account, and a payout instruction splits the funds between the merchant (goods value minus commission) and the platform operator (commission) at capture or at configurable settlement intervals. This approach delegates money transmission licensing to the payment provider rather than the platform operator.

Commission structures are stored as configuration data: a commission_rules table with merchant_id, product_category, and rate fields, evaluated at order calculation time. A rule hierarchy (platform default, merchant override, category override) allows flexible pricing without code changes. Commission calculations are written to an immutable commission_events ledger alongside order events so that finance reconciliation is always traceable.

Refunds on a marketplace split require reversing both the merchant payout and the platform commission. The refund flow reads the original commission event, computes the reversal amounts, and issues the split reversal via the payment provider's API. Partial refunds are handled at the line-item level, with the commission reversal calculated against the refunded lines only. All refund events reference the original commission event by ID for audit traceability.

E-commerce platforms like these are built and delivered by dedicated engineering teams through our mobile app development service.

Headless Commerce APIs and Catalogue Governance

Headless commerce separates the storefront presentation layer from the commerce infrastructure, allowing the same platform to power web storefronts, mobile apps, voice interfaces, and in-store kiosks from a single API surface.

The API layer exposes a GraphQL interface for storefront queries (product browsing, search, cart operations) and a REST API for administrative operations (merchant management, order management, reporting). The GraphQL schema is designed to be additive: new fields can be added without breaking existing clients, and deprecated fields are kept alive for a migration period with a deprecation notice in the schema documentation.

Catalogue governance becomes critical at platform scale: a merchant who publishes a product with an incorrect category or a prohibited item creates moderation work and potential liability for the platform. A moderation layer intercepts new product listings and applies automated checks (prohibited keyword detection, price sanity checks, image content policy via a vision API) before publishing. Items that fail automated checks are routed to a human moderation queue. Approved items are indexed in the search layer within a configurable delay (1 to 5 minutes for standard catalogues).

The catalogue serves search through an Elasticsearch index maintained by a Kafka consumer that subscribes to product_created and product_updated events from the catalogue service. This event-driven design decouples catalogue writes from search index updates: a catalogue write returns immediately, and the search index update is eventually consistent (typically within 30 seconds). For time-sensitive operations (flash sale price changes, stock updates), a priority event channel allows near-real-time index updates without queue starvation.

Platform Fraud, Trust, and Seller Quality

Running a marketplace means managing fraud from two directions: fraudulent buyers (stolen payment methods, chargeback fraud) and fraudulent sellers (counterfeit goods, non-delivery).

Buyer fraud signals feed a scoring model that runs at checkout: order value, velocity (multiple orders in a short window from one device), delivery address mismatch, device fingerprint, and account age produce a risk score. Orders above the risk threshold are flagged for manual review or challenged with 3DS authentication. The scoring model is a rules-based engine initially (fast to deploy, interpretable) with ML gradient boosting replacing rule components as labelled fraud and legitimate data accumulates.

Seller fraud detection runs asynchronously. Signals include dispute rate above threshold, negative review velocity, tracking number patterns that do not match carrier APIs, and fulfilment SLA miss rate. A seller health score (0 to 100) is computed daily as a projection over these signals. Sellers below a threshold automatically enter a remediation review; sellers at critical risk levels have payouts held until the review completes.

Dispute resolution creates a structured evidence exchange: buyers and sellers upload evidence (screenshots, tracking information, photos) within a deadline window. The platform operator reviews the evidence and issues a decision that triggers the appropriate payment action (refund to buyer, release to seller, partial split). The decision is logged with the reviewer identity, evidence submitted, and decision rationale: required for payment provider dispute arbitration and regulatory audit.

Explore Scrums.com's dedicated teams for marketplace and e-commerce platform projects, or start a conversation today.