A bespoke order system of record for a loan-financed commerce launch

Introduction

Some problems don’t have a product. A leading financial-services company was opening a new consumer-finance commerce channel — orders paid up front by a loan, then fulfilled through a merchant-of-record and a third-party logistics partner. They needed an order system of record to own everything from the moment of payment onward. No off-the-shelf OMS fits a loan-financed order wired into a consumer-finance core, so we built one.

The challenge

This isn’t a standard retail checkout. An order reaches the system already paid — financed in full — and from that point a single platform has to confirm it, orchestrate fulfilment across a merchant-of-record and a 3PL, keep the finance core in step (activating the loan on delivery, reversing it on cancellation), and give operators and merchants the tooling to run it at volume. Bolting platforms together with point integrations would have been brittle exactly where it mattered most: the hand-off of a paid order, where a dropped confirmation means a customer charged for something that never ships.

What we built

A bespoke OMS as the order system of record and back-office. It exposes a single signed, idempotent order-push endpoint: when an order completes upstream, the payment flow hands it over, and the OMS commits the order and its event in one transaction before it acknowledges. A success response is a hard receipt — nothing is half-committed, every response is typed rather than inferred from an empty body, and retries are safe by key, so a confirmation is never silently lost.

Underneath, a guarded state machine runs each order through roughly fifteen states from confirmed through fulfilment to returns. Every order line carries its own lifecycle and the order state is a rollup of its lines, so split shipments and per-line returns are native, not bolted on. Fulfilment is forwarded to the merchant-of-record and the 3PL through a swappable adapter pattern — the core never imports a partner’s SDK, so a vendor can change without re-architecting the system. Every meaningful transition publishes through a transactional outbox onto a CloudEvents backbone, so the whole flow is observable and automatable.

We built it experience-first: the entire system on local fixtures that mirror the real contracts, then a swap to live providers, then hardening for volume. Because the fixtures matched the real data shapes, going live was a provider swap and an optimisation pass — not a second architecture.

One platform, one login

Operators and merchants work in surfaces of the same application behind a single authenticated session. Permissions are enforced at the API and gate the UI, and tenant scoping is applied server-side on every query — so the platform is multi-tenant from day one and a merchant only ever sees its own brand. The operator’s landing page is a fulfilment list built for thousands of orders: attention tiles with live counts, an urgency-first default sort, and a three-tone status taxonomy so exceptions never read like healthy, in-flight orders.

Engineered for reliability

This is the record of truth for money-movement-adjacent orders, so it’s built to that bar: defined recovery objectives, a threat model at design time, security scanning on every change, two-reviewer governance on the state machine and payment paths, and a multi-stage pipeline to cloud with infrastructure-as-code and drift detection. Sensitive data is masked in exports by default, and the payment-card boundary is drawn so cardholder data never transits the OMS.

The result

The Connectivity Model made physical: a bespoke orchestration core that no vendor ships, engineered to be the dependable system of record for a loan-financed commerce launch. When no platform fits, you build — and built to this standard, that isn’t a compromise. It’s the point.