Live casino is the hardest product in an operator's catalogue to build properly and the easiest to get wrong in ways players notice inside the first thirty seconds. A slot forgives a bad network; a live table does not. The moment the video a player is watching drifts out of step with the timer they are betting against, someone works out that the two run on different clocks — and your margin starts leaking towards the people who noticed first.
This page is for operators and CTOs scoping live casino development, not for players choosing where to sit down. It covers what the engineering consists of, which decisions are cheap to reverse, where the recurring cost sits, and what regulators expect to see inside the system. For the wider mobile and web product around it, our casino app development company page covers that side of the estate.
What Live Dealer Software Actually Has to Do
From the outside a live table looks like a video stream with buttons over it. That description is wrong in a way that sinks live dealer software development projects. What you are operating is a real-time transaction system that publishes a video feed as a courtesy. Four things have to stay in agreement on every table you run: the authoritative round state, which decides what is open and what settles; the video and audio leaving the studio; the physical outcome at the table; and the player's wallet and session, moving against the same balance the rest of your site uses.
The video is the only one of those a player can see, which is exactly why it must never decide anything. Everything treated as true comes from round state and the confirmed physical outcome; the stream is presentation. Settle from the feed, close bets from the feed, or resolve disputes from the feed, and you inherit a class of bug that is close to impossible to unwind once real money has moved.
Latency Is the Product
Players judge a table on whether it feels like the same room. That perception collapses when glass-to-glass delay — the gap between something happening in front of the camera and it reaching the player's screen — grows from fractions of a second into whole seconds. The dealer's speech stops matching their hands and the table reads as a recording.
Holding delay that low rules out convenient options. Standard HTTP-based adaptive streaming buffers by design; that buffering is what makes it reliable for video-on-demand and unusable here without low-latency variants and hard tuning. Live tables generally need transport built for real-time delivery — WebRTC and its relatives — with fallbacks where a device refuses to cooperate. Price it before committing: real-time transports cost more per viewer, cache poorly, and punish a badly peered path.
Delay accumulates at capture and encoding, on the hop to the media origin, across distribution to the player's region, on a last mile you do not control, and in decode on the player's handset. Only the first three are yours to optimise, so spend there and design the rest to degrade gracefully.
Why the Server Clock Closes the Betting Window
This is the most important rule in live dealer software, and the one most often broken by teams arriving from a video background rather than a wagering one. The betting window must open and close on the server's authoritative clock. It must never respond to anything visible in the feed, and the client's countdown must render the server's remaining time rather than run alone.
The reason is arbitrage. Stream latency is not a constant — it differs per player, per network, per device. Two people betting on one round are watching it at measurably different moments, so if the window closes when the video says it closes, the player on the fastest path sees later information than the player on the slowest while both still have an open bet. On a game where the result becomes partially visible before it is final — a ball slowing on a wheel, a card lifting off the shoe — that gap is a priced edge, and organised players will find it and industrialise it.
The correct construction is simple to state and requires discipline to hold:
• The server opens the round, stamps it, and publishes a close time from its own clock
• Clients render a countdown continuously reconciled against the server, not run independently after one sync
• Every bet is accepted or rejected against the server's stamp on arrival, never against what the client believed
• The window closes before outcome information can reach any feed, with a margin covering the slowest realistic delivery path rather than the average one
• Late arrivals are rejected cleanly and told why — a player accepts a stated rejection, but a bet that vanishes without explanation opens a support ticket
The margin between window close and outcome visibility is a product decision, not only a technical one. Widen it and you protect integrity but slow the table, cutting rounds per hour; narrow it and the game quickens while you move closer to the point where the slowest player is still betting on information the fastest already has. Set it deliberately against real delivery telemetry, and revisit it in each new market.
Reading the Physical Table: Optical Capture and Dual Confirmation
A live game settles against a physical event, and something has to convert that event into a value the platform trusts enough to move money against. Two families of capture are in use, and serious tables run both: optical recognition, where cameras read card faces, wheel positions and chip placements from the table surface; and instrumented equipment — shoes that read cards as they are drawn, wheels reporting the winning pocket electronically, mats registering where chips sit.
Neither is trustworthy alone. Optical systems suffer from glare, a dealer's sleeve, a camera knocked out of alignment at shift change. Instrumented equipment fails differently: a sensor drifts, a shoe misreads a warped card, a wheel reports a pocket adjacent to the true one. Those different failure modes are what makes combining them useful.
No Round Settles on a Single Reading
The platform holds each round pending until two independent sources agree, with a supervisor's confirmation as a third channel where the licence requires one. When they agree, settlement proceeds and the player experiences it as instant. When they disagree, or either returns low confidence, the round stops rather than guesses — and what follows must sit in the published rules before launch:
• The round is flagged and held; no wallet movement occurs on a disputed outcome
• A supervisor reviews the recorded evidence against captured state; if the true outcome is established with certainty, the round settles on the confirmed value and the discrepancy is logged
• If it cannot be, stakes are returned as a void or the round is rerun, and affected players are told in-session why rather than left watching a frozen table
Void and Rerun Belong in the Design
Misreads happen. Dealers make procedural errors, cards get exposed early, a ball jumps the track. What separates a defensible product from a fragile one is that each case has a pre-agreed resolution and a system state to match. Void must be a first-class transaction type in your wallet, not a manual adjustment; rerun must be a first-class round state with an audit record linking it to the round it replaces. Bolt that on afterwards and every disputed round becomes a database intervention.
Every settled round should be reconstructable from stored records alone: identifier, timestamps, raw readings with their confidence, the confirmed outcome, the dealer and table on duty, every accepted bet with its arrival stamp, and the resulting wallet movements. Recorded video corroborates that record; it never replaces it.
Studio Operations and Table Utilisation Economics
Live tables are the only product in an online casino whose marginal cost behaves like a physical business. A slot serves its thousandth concurrent player at close to nothing. A table has a dealer standing at it whether one player is seated or four hundred, paid for the shift either way. The economics reduce to variables any operator should be able to state before commissioning a build: concurrent players per table, rounds per hour, hours of coverage your licensed markets actually play, staff cost per table-hour, and idle time.
The uncomfortable arithmetic is that utilisation, not table count, decides whether a live operation makes money — ten well-attended tables beat thirty half-empty ones. Capacity planning should follow your traffic curve, and the platform must make opening and closing a table an operational action rather than an engineering deployment.
Studio staff are users of your system, and their tooling sets how efficiently the floor runs: a dealer terminal showing round state and pending confirmations, a supervisor view across tables with alerts for held rounds, shift handover that does not interrupt an open round, and live occupancy figures.
Dealer language is a staffing question before it is a software one. Serving a market in its own language means a native-speaking dealer rostered during that market's peak hours, which multiplies coverage rather than adding to it; the platform's job is to carry language in table metadata and route players to tables they can follow.
Dedicated Branded Studio vs Shared Third-Party Tables
This decision moves the budget more than any other, and the honest answer disappoints operators who arrive wanting their own studio. At launch, and for some time after, shared third-party tables are usually right: you take tables from an established provider, integrate them, and your players sit alongside other operators' players at the same physical table. No studio lease, no dealer payroll, no equipment maintenance, no rostering. If a market underperforms you withdraw without stranded costs.
A dedicated branded studio becomes justifiable when your own concurrency keeps those tables busy across the hours you run them. Below that point you are paying a physical business's fixed costs to serve a handful of seats, and branding does not recover the difference. A common middle path is a dedicated table or two inside a provider's studio.
| Factor | Shared Third-Party Tables | Dedicated Branded Studio |
|---|---|---|
| Time to live content | Integration work only | Fit-out, staffing and certification before first round |
| Cost shape | Mostly variable, tied to activity | Largely fixed, incurred whether or not players show up |
| Brand presence | Provider's studio and identity on screen | Your identity, furniture and dealer presentation |
| Control over rules and pace | Provider's configuration | Set by you within licence conditions |
| Table availability | Shared with other operators' players | Reserved for your players |
| Exit cost if a market fails | Low — reduce or stop taking tables | High — lease, equipment and staff commitments remain |
| Best suited to | Launch and modest concurrency | Proven concurrency that fills tables across operating hours |
Whichever route you take, build the integration so the source of a table is configuration rather than an architectural assumption. Operators who hard-wire one provider's model find that moving in-house later means rebuilding the layer that should have absorbed the difference.
Live Game Types and What Each One Demands
The catalogue looks uniform from the lobby. Underneath, each family places different demands on capture, on the betting window and on the studio.
| Game Family | What Must Be Captured | Build and Operational Notes |
|---|---|---|
| Baccarat | Card values and the order they are drawn in | Fast rounds, heavy side-bet variety; unlimited seats, so utilisation scales well |
| Roulette | Winning pocket, confirmed by wheel sensor and camera | Outcome becomes visible as the ball slows, so the window must close well ahead of it |
| Blackjack | Every card dealt per seat, plus each player's decisions | Seat-limited unless run with shared-hand variants; decision timers add per-player state |
| Game shows and wheel formats | Segment landed on, plus any bonus round result | Presenter-led and production-heavy; the most demanding on set design and video quality |
| House-banked poker and card games | Community and dealt cards, plus per-player actions | Longer rounds, more per-player state; pace is dealer-driven rather than fixed |
Seat-limited games cap revenue per table in a way unlimited-seat games do not, which changes the utilisation maths considerably. And game shows are a production discipline as much as a technical one — no amount of streaming quality rescues a poorly produced format.
Same-Wallet and PAM Integration with the Rest of the Casino
Live tables must sit inside the casino, not beside it. A player who has to move funds into a separate live balance, or who sees a different figure at the table than in the lobby, is shown the seams of your integration at the moment they are most willing to bet. The account management layer stays authoritative for identity, balance, limits and history; the live layer talks to it rather than keeping its own view of the player.
• One balance across slots, tables, sportsbook and anything else you run, updated in real time in both directions
• One session and one set of player protection limits, applying at a table exactly as they do everywhere else, so a self-excluded player cannot be seated
• Bonus, wagering and loyalty logic that recognises live rounds under whatever contribution rules you publish
• A unified history detailed enough for support to answer a query without leaving the tool
Idempotency is not optional here. Live wagering runs over connections that drop: a confirmation may be lost while the bet itself was accepted, and a settlement message may be retried after the credit has landed. Every wallet operation needs a stable identifier and exactly-once semantics, and reconciliation between round record and wallet ledger should run continuously and alert on divergence.
Bandwidth, CDN Cost and Graceful Degradation
Video is a recurring cost that scales with concurrency and, unlike most of the platform, does not get cheaper per user as you grow. Every viewer consumes delivery capacity for as long as they watch, whether or not they bet, so peak concurrency rather than registered players drives that bill. The levers are bitrate ladder design, regional delivery footprint, cheap audio-only rungs for poor networks, what you do with idle viewers parked on a table, and table count itself — every open table is a live encode regardless of who is watching.
Because round state and video are separate, a player whose stream degrades has lost the pictures, not the game. A well-built product treats that as a normal condition and steps down through a ladder of experiences that all remain playable rather than failing to a blank screen.
| Condition | What the Player Sees | What the Platform Does |
|---|---|---|
| Healthy connection | Full-quality video with live audio | Highest rendition the device and network sustain |
| Bandwidth falling | Lower resolution, unchanged timing | Steps down the bitrate ladder without interrupting round state |
| Video unstable | Audio continues with a graphical table view | Drops the video rung, keeps commentary and the live state feed |
| Video lost entirely | Graphical table with countdown, bets and results | Continues the round on state data alone; betting stays open |
| State connection lost | Clear notice that the table is unreachable | Suspends new bets, protects placed bets, resumes on reconnect |
The distinction that matters is between losing the picture and losing the truth. Losing the picture should never remove a player's ability to bet, see the countdown or receive a result. Losing the state connection genuinely ends participation, so say so plainly, protect anything already staked, and design reconnection explicitly: what happens to an open bet, and what the player is told about anything that resolved while they were away.
Most of this happens on a phone, in portrait, on a mobile network, which should drive the interface rather than being retrofitted after a desktop layout is finished: bet controls that work with a thumb without covering the part of the frame that matters, and a client that survives an incoming call or a handover between Wi-Fi and cellular.
Licensing and Compliance for Live Tables
Live tables attract regulatory attention that purely digital games do not, because a physical location, real staff and real equipment are involved. Requirements vary by jurisdiction, so treat the following as the shape of the problem rather than a checklist for any one regulator.
• Where the studio physically sits often determines which authority governs the tables and which markets may be served from it
• Equipment, shuffling procedures and game rules commonly require testing by an accredited laboratory before live play
• Published rules must match system behaviour exactly, including every void and rerun case
• Logging and retention obligations apply to rounds, and sometimes to the video itself, for defined periods
• Dealer training, supervision ratios and procedural controls are frequently operating conditions rather than internal policy
• Player protection controls — limits, time-outs, self-exclusion, reality checks — must be reachable from the table view, and anti-money laundering monitoring must see live wagering alongside the rest of a player's behaviour
Involve your compliance advisers before the studio design is fixed, because retrofitting camera coverage into a finished room is expensive. And build market-specific rules as configuration rather than code branches.
Integrity monitoring needs its own attention, because live abuse patterns are not the ones your slot fraud rules were written for. Coordinated betting across accounts at one table, exploitation of a dealer's pace, systematic late-bet attempts and equipment manipulation present as patterns across rounds rather than as one suspicious transaction. Monitor against the round record — timing distributions of accepted bets, outcome distributions per table and per dealer, correlated staking — and route alerts to people who can act on the floor.
How We Scope a Live Casino Build
Live casino development starts with the commercial shape of the operation, because it determines almost every technical answer that follows.
1. Market and coverage definition — licensed markets, languages, and the traffic curve by hour, which sets table count and staffing
2. Sourcing decision — provider tables, dedicated tables inside a provider's studio, or your own room, integrated so this stays changeable
3. Round state and wagering core — authoritative clock, window rules, settlement, void and rerun states, and the audit record behind them
4. Capture and confirmation design — which sources apply per game, confidence thresholds, and behaviour when they disagree
5. Platform integration — wallet, identity, limits, bonuses and history against your account management layer, with idempotent transactions
6. Delivery architecture — transport, regional footprint, bitrate ladder, and the degradation path down to state-only play
7. Client and operations build — mobile-first table interface, reconnection behaviour, dealer terminal and supervisor console
8. Certification, launch readiness and tuning — laboratory testing where required, rules documentation, load testing at peak concurrency, then adjusting window margins and table schedules against observed utilisation
Where a live product joins an existing estate, integration work usually outweighs streaming work. For the wider picture, read the guide on how to build an online casino; the wagering estate around your tables is covered on our real money casino app development page.
Choosing a Live Casino Development Partner
A few questions separate teams with real live casino development experience from teams who have shipped video products and assume the rest follows.
• Ask how they close the betting window. If the answer involves the video feed in any way, stop there
• Ask what happens when the optical read and the sensor read disagree — you want a held round and a defined resolution path
• Ask how void and rerun are represented in the wallet. If they are manual adjustments, an audit will find them
• Ask what a player can still do when the video drops. Anything other than "keep betting" means state and presentation are entangled
• Ask how they would move you from provider tables to your own studio later, and what delivery costs look like at your expected peak concurrency by market
You can view a real-world example of how these decisions play out, or request a technical consultation to work through them against your own licences and markets.
Further Reading
1. UK Gambling Commission — licensing and remote technical standards: gamblingcommission.gov.uk
2. Malta Gaming Authority — licence types and conditions: mga.org.mt/licensing
3. Gaming Laboratories International — testing and certification: gaminglabs.com
Frequently Asked Questions
Which solution should I choose for my live casino?
Until your concurrency can keep tables busy across your operating hours, provider tables are normally sounder — costs stay variable and you can leave a market without stranded commitments. Move to dedicated tables when utilisation justifies fixed staffing.
How are live casinos different from ordinary online casinos?
An ordinary online game is resolved by a certified random number generator inside your platform. A live table is resolved by a physical event the platform must observe, confirm and settle against while streaming it to every player — which brings in capture hardware, studio operations, and a class of timing problem digital games do not have.
What games can I offer through live tables?
Baccarat and its side-bet variants, roulette, blackjack, house-banked poker and card games, and presenter-led game shows. Which ones make sense depends on your utilisation maths: unlimited-seat games carry far more players per staffed table than seat-limited blackjack.
Is integrating live tables difficult?
The streaming is rarely the hard part. Effort concentrates on making live rounds behave like everything else in your casino: one wallet, one session, one set of limits, and a history support staff can read.
Which languages do dealers speak?
That depends on sourcing and staffing rather than software. Provider tables typically offer widely spoken languages, with more available on dedicated tables you commission. Serving a market properly means a native-speaking dealer rostered during its peak hours, so coverage is a staffing cost rather than a feature toggle.
What live dealer games are supported?
Any format your provider or your own studio can run and your licence permits. Adding a family means defining its capture sources, window behaviour, rules and settlement path, so the integration layer should treat the catalogue as data.
Where to Start
The decisions that hurt later are made early: whether round state is genuinely independent of the video feed, whether void and rerun exist as real transaction types, whether your wallet integration survives a dropped connection, and whether the sourcing model can change without a rewrite. None are expensive at design stage; all are expensive once real money has been settled through the system. We can work through sourcing, delivery cost at your expected concurrency, and integration effort against your existing platform before anyone writes code — bring your licences, your markets and your traffic curve.