From One Way To Pay
To Three.
Replacement of a single full-payment checkout with three payment structures, including a deposit and balance model for made-to-order furniture, integrated across Adobe Commerce, the order layer and the finance system.
400
1
From 1 → 3
Payment Structures At Checkout
Client Profile
Premium Homeware & Furniture Brand.
~£30m revenue · ~2.3k orders/m.
Adobe Commerce storefront, selling to the UK and Ireland.
AOV Furniture £2,300, Accessories £150.
Made-to-order upholstery runs an eight to ten week lead time, at roughly 400 orders a month.
Every order took a single payment in full at checkout.
The Challenge
The checkout took one payment, in full, at the point of order. On a made-to-order sofa that meant handing over around £2,300 for something arriving eight to ten weeks later, with no partial commitment available and nothing left to pay on despatch.
That is a different proposition from buying anything in stock, and the checkout treated it identically. A customer willing to commit to the order but not to the full amount two months ahead of delivery had no way through, and the only lever the business held against hesitation was discount.
Why EQ50 DIGITAL
Payments sits across three functions that rarely buy together. Finance owns cost of acceptance and cash timing, ecommerce owns the checkout, and whoever holds the platform owns what can actually be built. A provider pitch answers one of the three.
The remit was to select on total cost of acceptance rather than headline rate, build the payment structures the catalogue needed, and integrate them through to go-live.
The provider brings the payment methods, the instalment product and the underwriting.
EQ50 DIGITAL supported the selection, the build and the integration.
The EQ50 DIGITAL Approach
01
Clarify the business priorities
A session with Finance and Ecommerce set the order: remove the full-payment barrier on made-to-order, widen affordability inside the furniture band, and hold blended cost of acceptance inside an agreed ceiling.
The ceiling shaped the whole design. Instalments cost materially more to accept than card, so the question was never whether to offer them but where to expose them.
Longer-term retail finance was raised and deferred. Unlike the selected instalment product, it would have introduced a materially different regulatory, customer-disclosure and operating model that the business was not ready to support.
02
Diagnose and scope
Twelve months of orders were cut by band, by product type and by lead time, so the made-to-order population was sized separately from stocked furniture and from accessories. That established which structure each population actually needed, and how much of the book each would touch.
Platform capability was assessed before anything was bought. The client’s Adobe Commerce implementation did not support the required deposit-and-balance lifecycle out of the box.
That set the line between configuration and build, and it put the integration, rather than the provider, at the centre of the work.
03
Design the solution
Three providers were scored on method coverage, instalment product terms at the basket sizes in question, integration maturity against Adobe Commerce, and three-year total cost of acceptance modelled on the actual band mix rather than a blended rate.
Deposit and balance was the harder build. Authorisation windows are far shorter than a ten week lead time, so a delayed capture was not workable. The design tokenises the payment method at order, takes a 25% deposit immediately and charges the balance at a defined trigger before despatch, with the order carrying a payment state that both the order layer and the finance system read.
The stored-payment model, customer authority and subsequent balance charge were designed with the provider as a supported card-on-file transaction, with retries and a fulfilment hold where payment failed.
Each structure was then gated on the population it serves. Deposit and balance on lead-time products, instalments on order value inside the furniture band, full payment everywhere else.
04
Deliver the change
Integration Readiness came first: what the order layer could hold as a payment state, what the storefront exposed at the point of selection, and what the finance system needed in order to recognise a part-paid order. That set the pattern, native for the checkout presentation, direct API for the payment orchestration and the balance trigger.
The deposit and balance flow with the balance charge tied to the despatch-ready event, the exposure rules for each structure, and customer comms covering the balance before it is taken. The finance design posts the deposit and balance separately against the same order, with the corresponding tax points, settlement and cancellation treatment reflected in the ledger.
Launch ran on one upholstery range first, held for a full production cycle so a real order could be watched from deposit through to balance and delivery, then opened across the made-to-order catalogue. Customer service was briefed on the exceptions the structure creates, principally a balance that fails to charge, which is a case that did not exist when payment was taken up front.
Key Decisions & Trade-Offs
Selection on total cost of acceptance, not headline rate.
A rate that looks strong on a £150 card payment is close to irrelevant on a £2,300 instalment order, so the model ran three years against the real band mix rather than an average.
The selected provider was not the cheapest on card. The accessories band pays slightly more per transaction than it would have done, to hold the economics of the band that carries the revenue.
Each structure gated on the barrier it removes.
Deposit and balance answers the wait, so it is exposed on lead-time products and not on anything in stock. Instalments answer affordability, so they are exposed on order value inside the furniture band. Neither runs across the catalogue, which keeps the higher cost of acceptance attached to the orders that justify it.
Two rules are still two rules. A large in-stock accessories basket crosses the value line and picks up a structure it was never designed for, which was accepted rather than solved.
A 25% deposit, not half.
A larger deposit protects cash and filters out the least committed orders. A smaller one removes more of the barrier. The number was set against the cancellation exposure on made-to-order production rather than against what competitors ask for.
Cash arrives later than it did, and the business now holds a customer commitment against goods not yet made, with the obligations that carries. A balance that fails to charge also creates an exception someone has to work.
The Outcomes
~400
A Month
Made-to-order orders that no longer require the full amount at checkout, taking a 25% deposit at order and the balance before despatch.
1 → 3
Payment structures at checkout: full payment, deposit and balance, and instalments inside the furniture band.
Full
Made-to-Order Range
The structure is exposed across every lead-time product rather than piloted on a subset, so no customer meets it on one sofa and not another.
Automatic
New State
The Handover
The client owns the provider relationship and its commercial terms, the deposit percentage, and the exposure rules deciding which structure appears on which product.
Handed over with it: a configuration playbook for adding methods or moving the rules without re-engagement, integration documentation covering the payment state across the order and finance systems, and the cost of acceptance model, so the mix can be retested at contract review and the case for regulated finance built when the business is ready to hold it.
