Our iGaming payments layer gives operators one cashier, one ledger and one set of routing rules across cards, local bank rails, wallets and cryptocurrency. It exists because payment reach is where a casino P&L leaks quietly: a player whose deposit is declined rarely writes to support, they close the tab and try a competitor. The layer runs inside the casino software stack or as a standalone module in front of a platform you already operate, so fixing a cashier never means re-platforming the whole business.
Gambling payments behave nothing like ecommerce checkout. Merchant category codes are watched, some issuing banks decline on principle, deposit and withdrawal volumes are lopsided by design, and every movement of money carries an AML obligation attached to your licence. Treating iGaming payments as a plug-in checkout is how operators end up with a weak acceptance rate, an unexplained gap between traffic and first-time deposits, and no visibility into which provider is responsible.
How iGaming payments go live in three steps
- Map markets and methods. We start from your licensed markets, player mix and existing provider contracts, then propose a method set per country instead of one global checkout. A Brazilian lobby leads with Pix, a Canadian one with Interac, and neither should be an afterthought behind a card form.
- Connect and configure. Acquirers, PSPs and local rails are connected through a single integration. Routing rules, limits, currencies and payout thresholds are configured per market and per method, and the cashier is styled in your own design system rather than dropped in as a third-party iframe.
- Go live and tune. The cashier launches with the platform, then routing weights, retry logic and release thresholds are adjusted from live decline codes. iGaming payments are never finished at go-live, and the first month of real data is worth more than any pre-launch assumption about which provider performs best.
What the iGaming payments module covers
The module is composed of parts you can switch on independently, which matters because most operators arrive with part of their iGaming payments setup already in place: a PSP contract they are happy with, or a risk team with its own rules.
- Cashier and checkout A branded deposit and withdrawal flow, localised across 20+ languages, with saved instruments, tokenisation and per-market method ordering, so the first option a player sees is the one that market actually uses.
- Method coverage 220+ payment methods spanning cards, open banking and local bank transfer, ewallets, vouchers, prepaid and crypto, with multi-currency accounts and FX applied at the wallet level rather than per transaction.
- Payment orchestration Traffic is distributed across acquirers and providers by market, method, amount and recent approval behaviour, with automatic failover when a route degrades and cascading retries on soft declines.
- Payout automation Withdrawal requests are risk-scored, matched against the instrument used to deposit, and released automatically inside the thresholds you set, leaving manual review for the cases that genuinely need a human.
- Risk and fraud controls Velocity limits, device and behavioural signals, bonus-abuse detection and structured chargeback handling that pulls evidence from the platform instead of from a shared spreadsheet.
- Reconciliation and finance Every attempt, settlement, fee, refund and rolling reserve lands in one ledger, so month-end is a comparison against provider statements rather than a reconstruction of them.
Because the layer is API-first, it also works as casino payments software in front of a stack that is not ours, and it inherits the same wallet the game content layer uses, so balances stay consistent whether a player is depositing, playing or cashing out.
iGaming payments economics: acceptance rate, cost per transaction, NGR
An iGaming payments platform is bought on features and judged on three numbers. All three are yours to measure, and none of them require a case study to understand.
Acceptance rate is the share of deposit attempts that clear. It is the only metric here that adds revenue rather than protecting it, because a recovered deposit costs nothing extra in acquisition. Run it against your own volume: on 10,000 attempted deposits a month, one percentage point of acceptance is 100 deposits you already paid to acquire and previously lost at the last screen. Routing, retries and correct method ordering per market are the iGaming payments levers that move that number, which is why decline-code reporting sits at the front of the interface instead of three menus deep.
Cost per transaction is the blended figure across scheme fees, provider markup, FX spread, payout fees and the cost of chargebacks. A single-provider iGaming payments setup has one price. An orchestrated one lets you send traffic to the cheapest route that still clears above your acceptance threshold, and cascade to a more expensive route only when the cheap one fails. The saving compounds with volume and is invisible without a unified ledger.
Payout speed is the retention number. Withdrawal time is the most discussed iGaming payments feature in every player community, and slow manual payouts undo the retention work done by bonusing and VIP programmes. Automated release inside policy thresholds turns payouts from a queue into a background process.
Together these feed NGR from both ends. More deposits clear, each one costs less to process, and players who get paid quickly deposit again. That is the whole commercial argument for treating iGaming payments as a product decision rather than a procurement one.
Single PSP, direct integrations or payment orchestration
Most brands pass through three of these four iGaming payments models as they scale. The question is how much rebuilding each transition costs.
| Approach | Integration effort | Routing control | Adding a market | Best for |
|---|---|---|---|---|
| One PSP, one contract | Lowest | None | Wait for your provider | Early testing in a single market |
| Direct provider integrations | High, repeated per provider | Full, but hand-built | A new build each time | Groups with an in-house payments team |
| Orchestration layer | One integration | Full and rule-based | Switch on a method | Operators scaling across markets |
| Cashier bundled with the platform | Included in launch | High, configured | Handled with the market | New brands launching a whole stack |
Operators running a packaged turnkey launch get the bundled model by default and can move to full orchestration later without changing the front end. Brands built around digital currency usually start from the same cashier and add coin and stablecoin rails through crypto-first casino software, keeping fiat and crypto balances in one wallet rather than two systems that disagree at month-end.
Keeping your contracts and migrating a live cashier
Moving to a new iGaming payment platform does not mean abandoning the commercial relationships you already built. Where your acquirer supports it, existing acquirer and PSP contracts connect to the orchestration layer under your own MIDs, so the rates you negotiated stay yours and the layer decides which of them receives each transaction.
Migrating iGaming payments that are already taking live money is a staged process, not a switch. New and old flows run in parallel, traffic moves across in percentage steps while decline rates are compared side by side, and rollback stays available until the new configuration outperforms the old one. Tokenised card instruments transfer where the receiving provider supports token migration; where it does not, returning players re-enter details once and the cashier remembers them from then on. Open withdrawal requests, pending chargebacks and rolling reserves are mapped explicitly before cutover, because those are the items that cause finance disputes months later.
PCI DSS, KYC/AML and licensing obligations
Card data in iGaming payments is tokenised at the point of capture and processed inside the PCI DSS certified environments of our acquiring and processing partners, which keeps raw card numbers off your infrastructure and narrows the scope of your own compliance work. The cashier communicates over tokenised references, so a breach of your marketing stack cannot expose payment credentials.
iGaming payment risk management and AML controls run on the same event stream as the rest of the platform. Deposit and withdrawal thresholds, source-of-funds prompts, sanctions and PEP screening, and enhanced due diligence triggers are configured per jurisdiction, with rules maintained across 20+ jurisdictions and full audit logs on every decision. Responsible-gambling limits apply at the cashier as well as in the game client, so a deposit limit is enforced before money moves rather than reported after it.
Payment rules are part of your licence conditions, not a separate workstream. Which methods you may offer, how quickly you must pay out, and what you must record per transaction all change by market, and the detail per regime sits on the jurisdiction and certification hub.
How the payment layer connects
iGaming payments reduce to three moving parts. One cashier faces the player, one engine decides where each transaction goes, and one ledger records what happened. Everything else is a connector.
- Casino
- Sportsbook
- Mobile
- Telegram
- One integration point
- Games
- Cashier
- Player accounts
- CRM
- CMS
- Reporting
- Game studios
- Payment providers
- KYC
- Regulator reporting
The practical effect is that adding a provider is configuration, not a project. Operators already running one platform for casino and sportsbook get the same cashier across both products, so a player has a single balance and you get a single view of payment performance instead of two reports that never quite agree.
Payment operations, monitoring and SLAs
iGaming payments infrastructure fails in small ways long before it fails visibly. A single acquirer starts declining a card range, a local rail slows down overnight, a provider changes a limit without notice. The layer watches decline codes, approval rates and settlement latency per route and raises an alert when a pattern breaks, so a route is rebalanced before support tickets arrive.
Behind that sit 24/7 technical support, an availability target of 99.99% on our SLA, and a payments-operations option for teams that would rather not staff the function. Managed payment ops covers provider onboarding and negotiation support, decline analysis, chargeback representment and payout review, scaled up or down as volumes change. One named contact stays with your account through each new market rather than restarting the context on every ticket.
Why operators choose our iGaming payments layer
- 220+ methods and multi-currency coverage through one integration, not one contract per rail
- Rule-based smart routing with failover, cascading retries and per-market method ordering
- Payout automation with risk scoring, so fast withdrawals do not mean unchecked ones
- Your own MIDs and PSP contracts preserved, with the routing decision in your hands
- Per-jurisdiction KYC, AML and responsible-gambling rules enforced at the cashier
- One ledger for attempts, fees, settlements and chargebacks, built for month-end
For a provider without a decade of case studies behind it, the honest differentiator in iGaming payments is architecture you can inspect: where card data goes, who holds the contracts, what the routing logic does on a decline, and how the ledger closes. Those answers are on this page because they are the ones an operator asks in the second meeting.
Frequently asked questions
What are iGaming payments?
They are the deposit, withdrawal and reconciliation systems a gambling operator runs: a player-facing cashier, a routing layer across acquirers and providers, risk and AML controls, and a ledger that ties every transaction back to a player account and a licence obligation. Vendors label the same thing casino payment software, a cashier module or an orchestration layer.
How does payment orchestration differ from using one PSP?
A single PSP gives you its own routes and its own pricing. Orchestration puts a rules engine above several providers, so each transaction goes to the route most likely to clear at the lowest cost, with automatic failover when one degrades.
How many payment methods and currencies can I offer?
220+ payment methods across cards, open banking, local bank transfer, ewallets, vouchers, prepaid and crypto, with multi-currency wallets and FX handled centrally so players see prices in their own currency.
What actually moves the acceptance rate?
Five iGaming payments levers do most of the work: method ordering that matches the market, routing to acquirers with strong local approval, cascading retries on soft declines, correct data submitted with each attempt, and removing friction such as forced re-entry of saved instruments.
Can I keep my existing PSP and acquirer contracts?
Yes. Where the acquirer permits it, existing providers connect under your own MIDs and negotiated rates, and the orchestration layer decides which of them receives each transaction. You can also run our connected providers alongside yours and compare performance directly.
How quickly can the cashier be integrated?
As part of a full platform launch, iGaming payments go live with everything else in around 4 weeks. As a standalone module in front of an existing platform, timelines depend on how many providers and markets you are bringing across.
How do you reduce chargebacks and payment fraud?
Velocity and device rules at deposit, instrument matching between deposit and withdrawal, bonus-abuse detection, and a structured representment workflow with platform evidence attached. Crypto and account-to-account rails also remove card chargeback exposure entirely.
What does PCI DSS mean for my cashier?
Card data is tokenised at capture and handled inside our partners' PCI DSS certified environments, so raw card numbers never reach your servers. That narrows the scope of your own assessment considerably, though it does not remove your obligations as a merchant.
How does payout automation decide what to release?
Each request is scored against player history, KYC status, deposit instrument, bonus wagering state and AML thresholds. Requests inside your policy limits release automatically; anything outside them queues for review with the reasons attached.
Do you support crypto deposits and stablecoin payouts?
Yes, coin and stablecoin rails sit in the same cashier and the same wallet as fiat, with conversion applied on your terms and per-coin limits configurable per market.
Talk through your payment mix
Send us your target markets, current providers and approximate deposit volume. We will map the iGaming payments setup that fits, method by method and route by route, before you commit to anything.