Multi-Vendor Marketplace Engineering in Banking

Summary

We build multi-vendor marketplace platforms, including those operated inside regulated banks. This kind of system lets shoppers browse products across many categories, compare offers from competing sellers and buy, while the operator handles seller onboarding, listings, payment, delivery and dispute resolution. When a bank runs one, it inherits both sides of the problem at once: consumer-grade retail experience and traffic patterns, and the controls, auditability and uptime expectations that apply to any regulated financial system.

The Challenge

Retail load lands on a bank technology estate integrated with core banking, card processing and identity systems that were never designed for e-commerce. Several sellers list the same item at different prices, stock levels and delivery promises, so a data model that merges product and offer becomes expensive to unpick later. A single basket splits into per-seller orders with independent fulfilment and refund lifecycles, which makes payment and order state machines the most failure-prone part of the system, since retries and duplicate webhooks are certainties. Platforms of this kind are usually built first as a single application and only later outgrow it, so the real question is how to decompose while it keeps serving traffic.

The Solution

Domain decomposition

• Catalogue and offer management - product definitions separated from seller-specific offers, so several sellers can list the same item with their own price, stock and delivery promise.
• Search and merchandising - faceted search with category-specific attributes, ranking and relevance tuning, which needs a dedicated search engine rather than database queries.
• Seller onboarding and back office - registration, verification, listing tools, order management and payout statements.
• Cart and order orchestration - splitting a basket into per-seller orders, each with an independent fulfilment and refund lifecycle.
• Payments and settlement - authorisation, capture on dispatch, split settlement to sellers net of commission, partial refunds and chargeback handling.
• Logistics - carrier integrations for rate quotes, label generation, tracking and returns.

Decomposing a monolith without stopping

The workable path is a strangler pattern: a routing layer in front, then one bounded context carved out at a time, moving both behaviour and data. Payments and catalogue are common first candidates because they change most often. Two rules keep the migration safe. New services own their data outright rather than reaching into the old schema, and every cross-service operation is designed for eventual consistency with idempotent handlers, retries and a reconciliation job that detects orders left inconsistent. Rolling releases per service keep the rest of the application serving traffic while a component is replaced.

Regulatory and operational constraints

Card data handling determines the compliance scope, and the usual answer is to keep the platform out of scope by tokenising through a certified processor. Seller onboarding carries KYC and anti-money-laundering obligations, plus tax identification and invoicing rules that vary by jurisdiction. Consumer protection law governs returns, refund windows and price display. Where the operator is a bank, penetration testing, change management, audit logging and segregation of duties apply as to any other regulated system.

Working inside an existing team

Where an organisation holds the domain knowledge but lacks specific competencies, typically front-end, native mobile, Golang back end and microservices architecture, our engineers embed in the existing product team. That means adopting the in-house sprint cadence, definition of done, code review standards and release process rather than importing a parallel one, and integrating directly with internal product managers and analysts. Legacy components that block progress are rewritten incrementally behind stable interfaces instead of freezing delivery.

What This Delivers

The operator gets a marketplace that can absorb new sellers and categories without unpicking its data model, and a settlement model finance can reconcile, because payout and commission logic is agreed with accounting before it is coded. Search is tuned per category rather than left as a generic keyword match, and inventory accuracy per seller is treated as a first-class problem instead of a display detail. Engineering teams release one service without coordinating a whole-platform deployment. And the platform stays defensible under bank governance, since audit logging and segregation of duties are designed in rather than retrofitted.

Technologies and Tools

• Golang services built with a toolkit such as Go-Kit and deployed as microservices on Kubernetes, alongside Java services already in the estate
• Angular and TypeScript for the web front end, with native mobile applications in Swift for iOS and Kotlin for Android
• Relational storage behind an ORM for transactional data, with a dedicated search engine and caches for sessions and pricing outside it