# Orbital for iGaming > Connect player accounts, sportsbook, casino, payments, KYC and operations using the systems you already have. Orbital handles the mappings and orchestration as providers, products and markets change. Source: https://orbitalhq.com/industries/igaming iGaming # Orbital for **iGaming** iGaming stacks grow one provider at a time — PAM, sportsbook, casino, payments, KYC, CRM and risk, each with its own APIs, events and identifiers. Orbital understands how they relate, then builds the integration each workflow needs on demand. [Get Started](/docs)[Talk to us](/contact) Use cases ## **Integrate,** simply. iGaming stacks grow one provider at a time — PAM, sportsbook, casino, payments, KYC, CRM and risk, each with its own APIs, events and identifiers. Orbital gives the concepts underneath them shared meaning, then builds the integration each workflow needs, on demand. Bring deposits, losses, session time, betting activity, limits, self-exclusion and customer interactions together as they happen. Feed that context into your existing safer-gambling rules and intervention workflows, even when the signals sit across sportsbook, casino, wallet and CRM. [Querying across systems](/docs/querying/writing-queries) **Onboard new providers in minutes** Add semantic types to a game, payment or KYC provider schema. Orbital maps those types to the player, account, amount and transaction concepts the rest of your stack already uses. Downstream systems keep the same contract, even as providers change. [Connecting data sources](/docs/describing-data-sources/open-api) Build registration, deposit and withdrawal workflows across your PAM, KYC providers, payment processors and fraud systems. Orbital works out which systems and data are needed for each request, so adding a new provider or market doesn’t mean rebuilding the workflow end to end. [Querying across systems](/docs/querying/writing-queries) Build regulatory returns from player, transaction, game and betting data across operational systems, with lineage for every value. Trace every reported value back through the calls and transformations to the source record that produced it. Changes to reporting schemas are handled against the semantic model rather than buried in another set of report-specific mappings. [Lineage and tracing](/features/observability) ## Add providers without **another integration project** Every new game, payments or KYC provider brings its own API and data model. Normally, that means another set of mappings into the systems that need its data. With Orbital, onboarding is simple: tag the new schema with the types you already use. Orbital works out how it connects to the rest of your estate. - ### Onboard new providers faster Add a game, payments or KYC provider by tagging its schema, rather than building a new set of point-to-point integrations. - ### Keep provider logic contained Provider-specific fields and formats stay at the edge. The rest of your systems keep working with the same player, account, bet and transaction data. - ### Change providers without starting again Replace a supplier, or add another one for a new market, without rebuilding the integrations that depend on it. ## Keep player data in your estate. Orbital runs inside your environment and routes data between systems without copying it into another data platform. It works with the identity and secret stores you already use. ![](/assets/plate-policy-BrOQ8GtA.webp) - ### Deploy in your cloud Run Orbital inside your own cloud or network, so player data does not have to leave your environment. - ### Keep your data at home Orbital routes data between your systems without copying it into a separate data platform or warehouse. - ### Bring your own identity Integrate with any OIDC or SAML identity provider and keep the users and groups you already manage. - ### Keep your secrets Connect Orbital to your preferred secret store, so credentials stay managed by the systems you already trust. ## Define once. **Enforce everywhere.** Define authorisation by player data type and field, then enforce it across APIs, databases, streams, back-office tools and agents. Policies can use live context from connected systems — market, brand, account status or user role — when deciding what a caller can see or change. [Explore Universal Authorisation](/features/universal-authorisation) ![A policy applied to player data, showing which fields were returned, masked or withheld for a caller.](/assets/policies-DaM1P9DW.svg) ## Keep event-driven systems **loosely coupled.** Sportsbook, casino, payments and player activity generate a constant stream of events. CRM, safer gambling, fraud, loyalty and analytics all need different parts of them. Orbital lets each consumer define the data it needs, without forcing producers to publish a schema that works for everyone. [Orbital for event based systems](/solutions/universal-mcp) - ### A schema for each consumer Send each system the fields and structure it needs, rather than making every consumer depend on the producer’s event format. - ### Enrich events as they flow Combine event data with accounts, payments or other connected systems before it reaches the consumer. - ### Change producers without breaking consumers When a provider changes its event schema, downstream systems can keep consuming the same contract. ## Frequently asked questions Got another gnarly question? We’d love to hear it. Come and chat on [Slack](https://join.slack.com/t/orbitalapi/shared_invite/zt-697laanr-DHGXXak5slqsY9DqwrkzHg). No. Orbital works across the systems you already run — PAM, sportsbook, casino, payments, KYC, CRM, databases and streams. The semantic layer describes how their data relates without moving the systems of record. Add semantic types to the provider schema so Orbital understands what each field represents. Orbital can then map that provider onto the player, account, amount, transaction and other types the rest of your estate already uses. Yes. Orbital can assemble signals such as spend, session activity, bets, deposits, limits and customer interactions across systems and supply them to your existing monitoring and intervention workflows. Your risk rules remain yours. Yes. APIs, databases and event streams can contribute to the same semantic model, so live events and request-response systems can be used in the same workflow. Orbital records where each returned value came from, including the systems called and transformations applied along the way. Individual report fields can be traced back to the source data that produced them. Yes. Orbital integrates with your identity provider and can enforce policy down to individual data types and fields. Policies can also use live data from connected systems when making an access decision. No. An LLM can translate plain-language intent into a request, but planning, authorisation and execution happen in Orbital outside the LLM. ## Start with **one integration**. Bring a provider API, safer-gambling workflow or regulatory report you already have. Add semantics to the schemas, and let Orbital build the integration. [Get Started](/docs)[Talk to us](/contact) ![](/assets/banner-cta-graph-axsXt434.webp)