Context
Evolvier builds and operates its own platforms alongside client work — it's why we say we build like owners, not vendors. Peyze is the largest of those builds: API-first, headless multi-vendor e-commerce infrastructure for operators selling across the GCC, UK, Europe, North America, and India. Vendors run their own catalogs, buyers check out in their own region's tax and currency context, and operators run multiple storefronts on one transaction core.
This case study covers the architecture decisions that shaped the platform — the same decisions we now apply in web application development engagements for clients with marketplace-shaped problems.
The challenge
Traditional storefront platforms couple everything: page rendering, catalog queries, and checkout share one process, one connection pool, and one deploy pipeline. When a seasonal campaign spikes traffic, the render path saturates first and checkout sessions start dropping — during exactly the hours that decide the quarter. The operator can't even react safely, because a storefront template change and the payment flow ship through the same release.
Multi-vendor, cross-border retail multiplies that baseline problem three ways:
- Vendor access risk. Dozens or hundreds of third-party sellers need real operational tooling, but a flat-permission platform turns any compromised vendor login into a platform compromise.
- Settlement complexity. Every order has to pay multiple parties correctly. The common pattern — collect into one account, reconcile in a nightly batch — drifts the moment a refund lands after payout.
- Tax at every border. GCC, UK, US, Canada, and EU buyers each need customs and regional tax computed correctly, or the operator simply doesn't sell there.
Peyze had to treat all three as architectural requirements from day one, not features patched in later.
Architecture & decisions
Decouple the storefront from the transaction core
The foundational decision: storefronts are clients of the platform, not parts of it. The transaction core — catalog, orders, payments, settlement — exposes GraphQL and REST APIs from a Node.js/TypeScript backend on PostgreSQL. Regional storefronts, built on Next.js, consume those APIs like any other client.
That separation buys two things coupled platforms can't offer. First, deploy independence: an operator can redesign, A/B test, or fully replace a regional storefront without touching payment processing. Second, independent scaling: render traffic and checkout traffic saturate different services, so a marketing-driven traffic spike queues page renders — not payments.
Make vendor isolation a security boundary, not a UI convenience
Each seller operates an independent dashboard for listings, delivery options, manifests, and performance metrics. Access is enforced with scoped, token-based authentication: a vendor session can reach that vendor's data and nothing else — no core system logs, no platform configuration, no other seller's records.
The boundary is deliberate threat modeling. Over-privileged seller accounts are a standing marketplace attack surface; on Peyze, a compromised vendor login is one vendor's contained problem. It's also what lets seller count scale without support headcount — vendors self-serve catalog and fulfillment while operators keep oversight from the platform side. The controls follow the zero-trust posture we document on our security page.
Split the payment at checkout, not in a nightly batch
Settlement is where marketplaces quietly bleed engineering time, so we moved it to the moment of payment. When a transaction clears — through Stripe, Checkout.com, or Razorpay, selected per market — merchant percentages route to sellers immediately and platform commission is isolated in the same operation. There is no reconciliation batch to drift and no payout spreadsheet to maintain; the ledger matches reality because the split is the transaction.
Card flows carry 3D Secure 2.0 and tokenization, and gateway integrations are wrapped in the same middleware discipline — request signing, rate limiting, retry logic — that defines our API integration and automation practice.
Compute cross-border tax per transaction
Peyze detects the buyer's location at checkout and computes customs, regional tax, and a compliant settlement path across the GCC, UK, US, Canada, and Europe. The calculation happens per transaction rather than at month-end, so the price a buyer confirms is the price that settles. Regional handling extends to data residency: GDPR and UAE Data Protection Law alignment are enforced through regional data isolation in the architecture, not through a policy document.
Build highlights
- One API surface, many storefronts. Catalog, pricing, and availability stay consistent across every regional front-end — web, mobile, or campaign-specific — because they all read the same platform APIs.
- Containerized, reproducible infrastructure. The platform runs in Docker on Kubernetes (EKS) in AWS, with the entire environment defined in Terraform. Environments are rebuildable and auditable — the cloud and DevOps baseline we hold for every production system.
- CI/CD with verification gates. Automated pipelines run security testing and container verification before anything reaches production, so storefront iteration speed never trades against checkout stability.
- Arabic-ready by design. Bilingual storefronts matter for GCC operators, so right-to-left and Arabic support sit in the storefront layer rather than being retrofitted.
Results
Because Peyze is our own platform, the numbers below are operational measurements, not a client's marketing claims.
—Checkout uptime through peak sale events (to be confirmed)
—Transactions auto-split at checkout (to be confirmed)
—Vendors operating in isolated dashboards (to be confirmed)
The structural results are visible in how the platform operates day to day: storefront deploys ship without touching the payment path, vendor onboarding doesn't add support load, and entering a new tax region is configuration work rather than an engineering project. The full feature set is on the Peyze product page.
Build something similar
If you're running a marketplace on a coupled storefront platform — or planning one across borders — the decisions above transfer directly: decouple the transaction core, isolate vendor access, settle at checkout, and compute tax where the buyer is. We've made these trade-offs on our own platform and can walk you through them on yours.