Impact Express — Multi-Carrier Courier Platform

A global courier booking system fanning out to three carrier APIs (DHL, UPS, EVRI) in parallel, with a MySQL zone pricing engine covering 100+ delivery regions and internal admin tooling for overrides and label regeneration.

Context

Impact Express lets businesses and individual shippers compare courier rates, book, pay and print a label from one interface instead of each carrier's own portal. I was the only developer on it, frontend and backend, and also handled client communication, requirements and research through the primary build. The platform is still in use, and I still own its requirements and hand maintenance work to junior developers.

Impact Express architecture: a React booking wizard calls an Express API, which fans rate requests out to DHL, UPS and an EVRI service, runs payments through Opayo with bookings in MySQL, and generates labels into object storage. — System architecture

Quotes that one carrier can't break

A quote request fans out to every eligible carrier in parallel with Promise.allSettled, so a DHL timeout never stops UPS quotes from rendering. Before any outbound call, each carrier service checks weight, dimensions, locations and package count, and carriers that can't take the shipment are left out instead of returning cryptic 4xx errors. DHL and UPS are live; the EVRI service prices from zone-based rates and waits on EVRI's new API.

Payments that survive the 3-D Secure redirect

With 3-D Secure v2, the bank's verdict arrives as a server-side callback after the browser has left the app, so the session that started the payment is gone. The booking is written as pending before the payment is sent, and the order's ID travels inside the callback URL. The callback finds the booking, verifies the result with Opayo and confirms it, or resets it on failure so nothing is left dangling. Getting this right across banks and browsers took thirteen fix commits.

Sequence diagram of the payment flow: the booking is stored as pending, then confirmed either directly on a frictionless payment or after the 3-D Secure challenge callback, which locates the booking by the order ID in its URL. — Payment flow — pending first, confirmed by whichever path completes

Labels

DHL and UPS return their own labels; for anything else the server draws a generic label with PDFKit and a Code 128 barcode. UPS returns one image per package, so multi-package shipments are merged into a single PDF, uploaded to object storage and returned as one link.

Addresses that break carrier APIs

DHL and UPS reject rate requests without a valid city, and postcode lookups don't always return one. A three-step fallback uses the entered city, then the postcode for UK-to-UK routes, then a curated country-to-city map covering more than 100 countries. It runs in both the live quote path and the admin price refresh.

What I'd change

Per-carrier timeouts, so a stalled carrier can't slow every quote; caching the UPS OAuth token instead of fetching one per call; and a nullable transaction ID with a cleanup job for bookings that never leave pending.