White Hat Gaming: one play page for 34+ live brands

White Hat Gaming runs a platform that many operator brands sit on top of. The brands look different and answer to different regulators, but underneath they run substantially the same application. A change to the shared page is thirty-four changes at once, and a defect in one is usually a defect in all of them.

The play page is where the platform meets third-party game providers, and it was still running on legacy code. Two constraints shaped the work. Compliance requirements arrive per market and are not negotiable on timing, so the new page had to be a place where features could be added and proved quickly. And nothing could stop. Brands were live throughout, which ruled out any plan whose first step was taking the old page away.

1. Decision 1

   One provider interface, two kinds of integration behind it

   Providers did not agree on how to be embedded. Some ran inside an iframe and talked over postMessage. Others shipped a JavaScript SDK that had to load in our own document and expected to be called directly. Letting that difference reach the play page would have meant a branch at every point a game is launched, resumed, or closed. Instead, the page talks to one adapter and never learns which kind of provider it has. Adding a new provider then means writing one adapter. It does not mean touching the page. The cost is a layer of indirection that hides a genuinely important distinction—so the adapter has to be honest about what it cannot promise for the SDK-based providers.

2. Decision 2

   An iframe wherever the provider allowed one

   Game providers ship code we do not control onto a page that handles real money. An iframe makes the boundary explicit: the provider gets its own document, and anything it needs from us crosses as a message we can see, log, and reject. Where a provider only offered an SDK, we did not have that luxury—their script runs in our page, their globals are our globals, and their failures look like ours. Those providers got loaded on demand, not up front. We kept them out of the main bundle and watched them more closely in production, because the containment we wanted simply was not available.

3. Decision 3

   Migrated the play page first, before anything easier

   The play page was the one the business earned money from, and the one most entangled with the legacy code. That argued for leaving it until last, and it argued just as strongly for doing it first. Doing it first meant the migration had to prove itself against the hardest case straight away. The patterns the rest of the team inherited were ones that had already survived something real. It also meant the riskiest work landed while attention and appetite for it were both still high.

4. Decision 4

   Left the legacy PHP serving through the cutover

   Thirty-four brands cannot change on the same morning. Each has its own release appetite, its own compliance position, and its own idea of a quiet week. Keeping the legacy path alive let brands move one at a time. That meant running two implementations for longer than anyone enjoyed—a known, bounded cost, set against a coordinated flip that could have gone wrong everywhere at once.