Londinium Checkout,
an ecosystem in motion.

Londinium sells hand-built espresso machines that ship internationally in multiple crates, on multiple carriers, sometimes to regions the company can't actually serve — and they sell to both retail customers and trade buyers who expect to be invoiced rather than charged at checkout. The native checkout that came with the commerce platform could not model any of that honestly.

Splitting an order across parcels meant manual intervention. Blocked destinations weren't surfaced until after payment. Trade customers were routed through the consumer flow and reconciled by hand in a spreadsheet. Coupons, gift cards, and account credit all lived in different places. On top of that, the checkout needed to run in four currencies, verify phone numbers before releasing a shipment, and talk to the company's own billing and CRM backend.

Now every Londinium order — consumer paying by card or trade buyer settling an invoice — flows through one checkout with a consistent look, URL structure, and set of rules. The checkout is reached by a signed cart ID, so marketing can send a link to a specific cart or invoice and the recipient lands exactly where they need to be.

Multi-parcel shipping reflects the real shipment. Large machines often ship in several crates on different carriers; each parcel is priced and named separately, and the customer picks a service per parcel. Rates come back from Swell's live rating engine and are saved against the cart through a server-side endpoint that validates the combination before it commits.

When the rating engine can't return a live quote for a destination, the checkout doesn't turn the customer away. Their details and cart are captured, the order is held as a draft, and the team follows up to quote shipping and send an invoice — which lands back in the same checkout where the customer pays. One flow covers both the automated path and the manual-quote path without the customer ever leaving it.

A standard-shipping option lets the team confirm the customer and the shipment before collecting money. The order is created as a draft, the customer is invoiced afterwards, and the same invoice page is where they pay. PayPal is dropped from this path automatically because it doesn't fit the deferred-payment model.

When sales issues an invoice from the back office, the checkout recognises the record, routes the buyer to an invoice page, and reconciles any drift between cart and order shipping details. Balances, payments, and refunds are shown explicitly, and the customer moves to the confirmation view as soon as the invoice is paid.

Six ways to pay sit under one roof — credit card, PayPal, bank transfer via Wise, manual bank transfer, gift card, and account credit. Each is a first-class option with its own validation, handlers, and rules about when it can appear. The admin decides which are active.

Phone verification through Twilio sits in front of shipment confirmation, with verified numbers stored so repeat buyers don't re-verify. The checkout runs in USD, AUD, CAD, and CZK with taxes recomputed per currency. Every server-side failure reports to the observability provider with full cart and checkout context attached.