CandyGym — Dokan Multi-Vendor Marketplace Case Study

Project Overview

CandyGym operates as a multi-vendor marketplace for fitness and performance products — injectables, tablets and capsules, fat burners, post-cycle therapy, HGH and peptides — sold under established brands such as Magnus Pharmaceuticals, Swiss Remedies and Royal Pharmaceuticals. It is not a single-brand shop. Vendors list their own catalogues, and the marketplace positions itself, plainly, as the first of its kind serving Europe.

That positioning carries an obligation. A buyer in London and a buyer in Berlin are not shopping in the same market, even though they land on the same domain. What can be sold, how it is paid for, and how it is shipped differ between the two, and a marketplace that ignores those differences either breaks the law or breaks the customer’s trust. So the site had to feel like one clean shopping experience on the surface while quietly enforcing two sets of rules underneath.

There is a second audience the platform serves just as carefully: the vendors. A marketplace only works when sellers believe the money is right. Every earning, every refund and every withdrawal has to reconcile, in the currency the vendor expects, no matter which currency the customer happened to pay in. Most of the deepest engineering on this project went into making that promise true.

Business Goals

The brief resolved into a few durable objectives, each tied to something the business could not afford to get wrong.

The marketplace had to sell into the UK and the EU as distinct markets while looking like one storefront. Customers should see only what they can legally receive, pay in the currency that suits them, and never hit a surprise at the final step. Regional separation had to be a rule the system enforced, not a note in the footer.

Vendors had to be paid correctly in a multi-currency environment. With customers checking out in either pounds or euros, the platform needed to credit each seller in the shop’s home currency, consistently, so that balances, withdrawals and refunds always told the truth. Nothing erodes a marketplace faster than sellers who suspect the numbers.

The platform needed room to grow without a rebuild. New vendors, new brands, new products and eventually new languages all had to be absorbable by the existing structure, and the running costs had to stay predictable as the catalogue and the audience expanded.

And the whole thing had to stay maintainable over years, not months — which is why we are still the team behind it.

Engineering Challenges

The hard problems on this project were not cosmetic. They came from asking one website to behave correctly across two regulated markets, two currencies and many independent sellers at the same time.

Regional stock separation. The single largest constraint was that not every product may be offered to every customer. Pharmaceutical and performance-product rules differ between the UK and the EU, and payment and fulfilment workflows differ with them. A product legal for one region may not be offered to the other. WooCommerce, out of the box, has no concept of “this product is available to this region and not that one” as a purchasing rule — its shipping zones govern rates, not eligibility. The marketplace needed eligibility enforced at the catalogue and at the checkout, not just implied.

Country-specific regulations and payment restrictions. Because the two markets are governed differently, the buying experience itself had to change depending on where the customer is shipping. That is a business-logic problem sitting on top of a commerce platform that assumes one uniform set of rules for every shopper.

Marketplace complexity. Multi-vendor operations hide a great deal of machinery behind a simple-looking storefront. Each vendor carries its own catalogue, orders, commissions, refunds and payouts. Dokan provides that foundation, but the moment a second currency enters the picture, the accounting underneath vendor earnings stops being straightforward.

Multi-currency, and the accounting it breaks. Letting customers pay in pounds or euros is easy to switch on and surprisingly hard to get right. When a customer checks out in a non-default currency, the order is recorded in that currency — and a multi-vendor plugin that reads those totals literally will credit a vendor the wrong amount. A fifty-pound earning quietly treated as fifty euros is not a rounding issue; it is a payout that is wrong by the whole exchange rate. Left unaddressed, this quietly corrupts every vendor balance on the platform.

Vendor compatibility. The marketplace layer and the currency layer were each mature, well-supported pieces of software. They simply were not built to know about each other. Reconciling them without destabilising either was one of the central engineering tasks of the project.

Multilingual, growing content. A marketplace meant to serve Europe cannot stay English-only, and its content is not fixed — vendors add products constantly. Any translation approach had to cope with a catalogue that never stops growing, at a cost the business could forecast.

Long-term maintainability. Every decision above had to be made in a way that could be supported for years by a small team, updated safely alongside WordPress, WooCommerce and Dokan releases, and handed forward without becoming a liability. That constraint shaped the engineering as much as any feature did.

Architecture

We built CandyGym on WordPress with WooCommerce as the commerce engine and Dokan providing the multi-vendor layer. That base was chosen deliberately: it is mature, widely supported, and gives the CandyGym team day-to-day control over their catalogue and vendors without a developer on standby. Just as important, it is software that will still be maintained in five years, which matters more for a platform meant to run continuously than any newer alternative would.

The visual and functional foundation is a premium pharmacy-focused theme, extended through a child theme that carries the real customisation. Keeping our work in the child theme is a maintainability decision as much as a technical one: the parent theme can receive its updates without overwriting a single line of the marketplace’s bespoke behaviour. That behaviour is considerable — the child theme handles vendor presentation, the loyalty-coin account area, direct messaging between customers and sellers, delivery-time fields shared across the vendor and admin flows, and a set of template overrides that reshape how orders and stores render.

The two problems the base stack could not solve — regional eligibility and currency-correct vendor payouts — were moved into dedicated plugins rather than buried in theme code. That separation is intentional. Business rules this important deserve their own, testable home, where they can be reasoned about, updated and, if ever needed, switched off cleanly, without touching presentation. It is the difference between a site that happens to work and one that can be maintained with confidence.

Marketplace Experience

For the customer, the marketplace is meant to feel unremarkable in the best sense. You choose where you are shipping, you see what you can buy, you pay how you like, and nothing about the two-market, multi-currency machinery underneath ever surfaces as friction.

The shopping journey opens with a choice of destination — the UK, Europe, or products available to both — and the catalogue responds to it. A shopper browses by category or by brand, sees clear regional indicators on products, and can switch between pounds and euros as they go. Direct messaging is built into product pages and vendor storefronts, so a question about a product, a brand or a delivery goes straight to the seller instead of stalling the sale. A support desk and live chat sit behind that for anything the vendor cannot resolve alone.

For vendors, the marketplace is a place to run a business, not just list products. Each seller manages their own catalogue and orders, communicates with buyers directly, and — critically — sees earnings, refunds and withdrawal balances that are correct and stable in the marketplace’s home currency, regardless of how any individual customer paid. That reliability is invisible when it works, and it is exactly the kind of thing a vendor notices instantly when it does not. Getting it right is a large part of why sellers stay.

Around the core shop sit the mechanisms that keep a marketplace growing: an affiliate and ambassador programme for advocates, a loyalty coin that rewards direct payment, a blog, and a brand-led browsing structure that lets established names carry their own reputation into the storefront.

Custom Plugin Development

Two problems on this project could not be solved by configuration, no matter how much of it we did. Each became a purpose-built plugin, engineered specifically for this marketplace and maintained as part of the platform.

WC-CBP — Country-Based Products

The requirement sounds simple until you try to build it: a customer should only ever be able to buy what is legally available in the market they are shipping to. In practice, that touches the whole journey. A product carries a regional availability — UK, EU, or both — and the storefront has to honour it consistently, from the way a product is presented to the moment an order is placed.

Existing tools stopped short of this. WooCommerce’s shipping zones decide what a delivery costs, not whether a product may be sold to someone at all, and no standard setting turns regional legality into a purchasing rule. We built WC-CBP to close that gap. It gives every product a shipping region, presents that region clearly to the shopper, and enforces eligibility where it actually counts — validating the cart against the customer’s destination and blocking an incompatible order at the server before it can be placed, not merely hiding a button on the front end. The rule is applied in one place and trusted everywhere, so the same logic governs the product page, the cart and the final checkout without contradicting itself.

The regional model reflects how the business actually ships: nothing leaves the UK-and-EU footprint, the European Union is treated as a defined set of member states, and products available to both markets become the common ground where the marketplace’s own CandyCoins loyalty currency, powered by myCred, can be spent. The point of all this is not the rule itself but its effect: customers are never offered something they cannot legally receive, orders that would fail compliance never enter the system, and the business is protected from the class of mistake that is expensive precisely because it is quiet.

Dokan-WOOCS Compatibility

This is the deepest piece of engineering on the project, and it exists to keep a single promise: that vendors are always paid the right amount.

The situation that made it necessary is easy to describe and hard to fix. Customers can pay in pounds or euros. When someone checks out in a currency other than the shop’s home currency, the order is stored in the currency they used. The multi-vendor layer then reads those stored totals to work out what each vendor has earned — and reads them literally. A fifty-pound earning gets recorded against the vendor’s balance as if it were fifty euros. Multiply that across every cross-currency order and a marketplace’s entire ledger drifts away from reality, silently, with no error to alert anyone.

It would be unfair to frame this as a flaw in either the marketplace software or the currency switcher. Both are mature, capable products. They were simply designed to solve their own problem well, and neither was built with the other in mind — every platform has boundaries where its assumptions end. The honest engineering response was not to fight either plugin or to patch their internals, but to build a compatibility layer that sits between them and reconciles the two views of money without destabilising either.

That is what this plugin does. When an order becomes eligible for vendor payout, it converts the recorded earning into the marketplace’s home currency using the exchange rate that actually applied to that order, and writes the corrected figure into the vendor’s ledger. It does the same for refunds, so a return deducts the right amount rather than a wrong-currency approximation. It adds a locked payout currency to each withdrawal method, so vendors always know exactly what they are being paid in. And it presents the vendor’s dashboard consistently in the home currency while still showing each individual order in the currency the customer used — the numbers reconcile instead of confusing.

Two design choices are worth naming, because they are what make the plugin trustworthy rather than merely clever. First, every correction is idempotent and audited: an order is converted once, stamped so it can never be double-counted, and accompanied by a full record of the original amount, the converted amount, the rate and the timestamp — so any figure can be traced and defended later. Second, the conversion is guaranteed rather than hoped for. Real marketplaces are messy — orders get edited, saved, refunded and occasionally processed out of the expected order — so the plugin verifies and heals the ledger on those events and sweeps periodically for anything missed, instead of assuming the happy path always holds. The result is a vendor balance that stays correct through the ordinary chaos of a live store. For a marketplace, that reliability is not a feature; it is the foundation the vendors’ trust rests on.

Breview Pro — Verified Reviews

Reviews are decision-making infrastructure in a trust-sensitive category, and they are only worth anything if buyers believe they are real. CandyGym uses Breview Pro, our own commercial reviews plugin for WooCommerce, to tie reviews to genuine orders and give customers a straightforward way to leave feedback directly from their purchase history rather than through an anonymous form.

Because it is our product, the review workflow on CandyGym is not a bolted-on dependency the client has to hope stays supported — it is maintained by the same team that maintains the marketplace, updated in step with WooCommerce, and shaped to fit the store rather than the other way round. Verified reviews raise the credibility of every product they attach to, and in a market where buyers are cautious by default, that credibility does measurable work.

Technical Consulting

The most valuable decision on a project is often the one that stops a future problem from ever forming. On CandyGym, that decision was about translation.

The original plan was to make the site multilingual with WPML, a capable and popular choice. We recommended against it here, and steered the project to GTranslate instead — not because one plugin is broadly better than the other, but because of how this particular marketplace grows. CandyGym’s content is not a fixed set of pages an editor translates once. It is a catalogue that expands every time a vendor adds a product, in a business that intends to keep adding vendors. A translation approach that meters effort or cost against volume of content works against a marketplace whose whole growth model is more content.

GTranslate fit that reality better on the terms the business actually cares about. Its pricing is predictable and subscription-based, with no per-word or credit accounting to manage as the catalogue swells. New vendor products are picked up and translated automatically as they appear, rather than requiring a manual pass each time. And the operational overhead of keeping the site multilingual stays flat as the store scales, instead of climbing with it. Framed as a business decision rather than a plugin swap, it lowers the running cost of being multilingual and removes a recurring chore from the team — which is exactly the kind of quiet advantage a technical partner is supposed to provide.

Performance

Speed is a commercial property here, not a technical vanity. Shoppers in this category compare, hesitate and abandon quickly, and a marketplace that feels slow reads as less trustworthy regardless of what is on the page. We treated performance as something to protect as the catalogue grows, not a number to hit once at launch.

The site runs on an Apache, PHP and MySQL stack, with the front end optimised so that a marketplace carrying many vendors and products still loads quickly and stays responsive on ordinary connections and mobile devices. The measured results reflect that discipline: 90+ on Google PageSpeed Insights, 85%+ on GTmetrix, and 95%+ on Pingdom. Those figures matter less as scores than as the everyday experience behind them — pages that open fast for a customer deciding between sellers, where a few seconds of delay is often the difference between a sale and a bounce.

Security

A marketplace that handles customer accounts, payments and a network of vendors in a scrutinised category cannot treat security as an afterthought, so the protection is layered rather than bolted on at the end.

Cloudflare sits in front of the site, filtering hostile traffic and absorbing the automated attacks any commerce domain attracts. An SSL certificate encrypts everything that passes between a visitor and the server, from a login to a payment. Wordfence guards the WordPress layer against intrusion and known exploits, a server-level firewall hardens the infrastructure beneath it, and WP Hardened closes the common configuration gaps attackers probe first. hCaptcha keeps bots and spam off registration and forms without pushing friction onto genuine customers and vendors. Together these form a defence-in-depth posture: if one layer is bypassed, others still stand — the right approach for a platform that holds other people’s money and trust.

Technology Stack

The stack was chosen to match the business and to stay supportable for years, not to chase novelty. WordPress, WooCommerce and Dokan provide a marketplace foundation the CandyGym team can operate themselves, with the multi-vendor machinery already mature and maintained by large communities. A premium pharmacy theme, extended through a child theme, carries the bespoke marketplace behaviour while leaving the parent free to update safely. ACF Pro structures product and vendor data consistently. AffiliateWP runs the affiliate and ambassador programme, Better Messages powers customer-to-vendor chat and the support desk, myCred drives the CandyCoins loyalty currency, and WOOCS handles multi-currency pricing. GTranslate keeps the marketplace multilingual as it grows. Our own two plugins — WC-CBP for regional eligibility and the Dokan-WOOCS compatibility layer for currency-correct payouts — supply the logic the platform could not get anywhere else.

Underneath, Google Analytics informs decisions, and hCaptcha, Cloudflare, SSL, Wordfence, WP Hardened and a server firewall protect the platform. Payment is accepted by card, bank transfer, cash on delivery and the CandyCoins loyalty currency. The build rests on PHP, HTML5, CSS3, JavaScript and jQuery — well-understood, well-supported technologies, chosen because this platform needs to run dependably for years rather than impress for a quarter.

Outcome

CandyGym Fitness runs today as what it set out to be: a single marketplace that serves two regulated markets, prices in two currencies, rewards direct payment with its own loyalty coin, and pays a roster of vendors accurately every time. The regional rules are enforced by the system rather than trusted to chance. The vendor ledger stays correct through cross-currency orders, refunds and edits. The multilingual layer expands with the catalogue at a cost the business can predict. And all of it sits on a fast, secured, maintainable foundation the CandyGym team can operate day to day.

The clearest measure of the work, though, is that it did not end at launch. We have handled CandyGym’s support and maintenance continuously since the platform went live — updating it safely alongside every WordPress, WooCommerce and Dokan release, extending it as the business has grown, and standing behind the custom engineering as the platform it belongs to. The client’s five-star rating reflects a partnership, not a handoff. This was built to last, and the fact that we are still the team behind it is the proof.