Deposit payments tailored for a multi-store custom gifts business

The challenge

A Hong Kong business selling personalised 3D photo phone cases, bike cases and model gifts ran several storefronts from one multi-store installation. Because many products are made to order, the business takes a deposit at checkout and collects the balance later. It had bought our partial-payment extension from the OpenCart marketplace, but its pricing model raised questions the standard settings did not answer.

Customers regularly used coupons and bundle discounts, so the deposit had to be worked out from the discounted subtotal rather than the list price. With several stores sharing one codebase, any change also had to behave correctly on each storefront without disturbing the live sites.

What we did

• Isolated test environment. The client set up a test server in the United States that mirrored the multi-store installation. We worked there over SFTP and kept every change inside the extension's own vQmod file, leaving core files untouched and making future updates simpler.
• Deposit calculation rework. Following the client's fix-request documents, we changed the logic so the deposit is calculated from the subtotal after coupon and bundle discounts, then worked through further rounds of adjustments until all requested changes were in place.
• Multi-store debugging. We traced and resolved an error that appeared only in the multi-store setup, so the deposit option worked consistently across the storefronts.
• Second-domain licence. We issued a licence key so the extension could run on an additional storefront domain.
• Live-site follow-up. A few months later the client asked us to correct the wording of the payment notice that customers see; we updated it on the live store.

Tech stack

PHP, MySQL, OpenCart 3 (multi-store), vQmod, nginx, Linode