Deposit → decision → payout

Every deposit in.
Every payout out.
One route you can see.

Our igaming payment gateway is a commercial payment service for eligible operators: connect player payment methods, route transactions, coordinate risk signals, and reconcile every state through one operating layer.

Request gateway accessExplore the platform
DepositsPlayer-first cashier routes
PayoutsObservable withdrawal states
igaming payment gateway network connecting deposits, payouts, risk checks and reconciliation
Illustrative service architectureNo provider relationships implied
RoutingRules, recovery, visibility
01 Payment intent02 Risk decision03 Authorization04 Ledger event05 Payout state

The operating layer

Payment states your teams can act on.

A cashier is only the visible edge. The gateway keeps product, risk, finance, and support working from the same transaction story.

Accept

Localized player checkout

Present eligible methods, currencies, authentication, and return states in a focused cashier flow.

Review method strategy
Route

Rules and cascading

Use configured context to select a route, recover from eligible failures, and explain each decision.

See platform controls
Protect

Risk-aware decisions

Connect fraud, KYC, AML, authentication, velocity, and responsible-play signals without obscuring ownership.

Map control ownership
Reconcile

One payment event model

Keep deposits, refunds, reversals, withdrawals, payouts, disputes, and settlement references traceable.

Explore the event model

Two-way payment flow

Deposit speed should not create payout blind spots.

Both directions use the same account, risk, routing, and reporting context. Teams can follow a transaction from player action to final financial state.

Walk through the lifecycle

Payment choice

Local where players pay. Unified where teams operate.

Method coverage is designed market by market. No inflated count replaces the work of checking eligibility, currency, settlement, refund, and payout behavior.

Build the method mix
CardsTokenized and authenticated flows where available
Bank railsTransfers and open-banking routes by market
WalletsPlayer-recognized digital methods
Local methodsCurrency and region-specific payment choice
Payout routesApproved withdrawal destinations and states

From scope to production

A launch sequence with visible gates.

Technical integration and payment-partner approval progress together, but they are not the same milestone.

  1. Scope

    Operating model

    Entity, jurisdictions, product, player flow, methods, currencies, volumes, and payout requirements.

  2. Design

    Payment architecture

    Cashier, tokenization, routing, risk signals, webhooks, ledgers, reporting, and responsibility boundaries.

  3. Prove

    Sandbox and edge cases

    Happy paths, retries, timeouts, reversals, disputes, payout holds, duplicate events, and reconciliation.

  4. Activate

    Controlled production

    Approved routes move live with observability, operational ownership, and a rollback plan.

See integration details

Operating models

One platform, distinct payment realities.

Online casinoRepeat deposits, withdrawals, risk and retention↗ SportsbookEvent peaks, rapid authorization and payout states↗ Platform providerTenant configuration and shared payment operations↗ Game publisherDigital purchases, accounts, refunds and disputes↗

Controls and evidence

Security language without borrowed badges.

We describe the controls the service can support and the evidence that must be confirmed during onboarding. We do not claim certifications, licences, bank coverage, or compliance outcomes that have not been supplied.

Data exposure

Choose hosted, tokenized, or API-led patterns according to the selected payment route and PCI scope.

Risk context

Connect authentication, device, velocity, identity, account, and payment signals to reviewable decisions.

Responsibility map

Document which duties sit with the operator, gateway, payment partner, and specialist vendor.

Evidence trail

Preserve event history for support, disputes, reconciliation, and operational review.

Read the security and compliance model

Commercial model

No fictional “from” price.

Pricing changes with markets, methods, currencies, volumes, ticket size, settlement, payouts, risk tooling, and support. A complete proposal should separate gateway, processing, method, dispute, conversion, and optional service costs.

See pricing inputs

FAQ / 09

Questions before the first payment route.

Ask about your model
01What does an iGaming payment gateway do?

It carries payment requests between the player-facing cashier, configured payment routes, risk and authentication controls, payment partners, and operator systems. A gaming-specific service also needs to represent deposits, refunds, withdrawals, payouts, reversals, disputes, and reconciliation states without hiding them behind one generic transaction status.

02Can one integration support both deposits and payouts?

The service is designed around a bidirectional lifecycle. Deposit and payout availability still depends on the operator model, jurisdiction, payment method, acquiring or payout partner, settlement setup, and underwriting approval. Those dependencies are mapped before production activation.

03Which payment methods can be connected?

The integration model can cover eligible cards, bank-based payments, digital wallets, vouchers, and other local methods. The actual set is selected by market, player preference, currency, commercial fit, and provider approval rather than by publishing an inflated global method count.

04How does smart routing improve payment operations?

Routing evaluates configured factors such as method availability, geography, currency, risk state, cost, and provider health. Cascading can attempt an approved alternative route after a recoverable failure. Rules must remain observable so teams can explain why a transaction took a particular path.

05Does the gateway handle KYC and AML obligations?

It can connect identity, KYC, AML, sanctions, velocity, and responsible-gaming signals to payment decisions. It does not transfer the operator's legal duties to the gateway. The exact control ownership is documented for the operator, gateway, payment partner, and specialist vendors.

06Is the platform PCI DSS certified?

No certification claim is made on this site. The platform supports integration patterns that can reduce exposure to raw card data, including hosted or tokenized flows where available. Formal PCI scope and evidence must be confirmed during onboarding for the selected architecture and partners.

07How long does integration take?

There is no truthful universal timeline. The work depends on cashier scope, required methods, markets, data and authentication flows, payout logic, migration needs, testing, underwriting, and partner approvals. The integration page separates technical readiness from commercial activation so both can be tracked.

08How is pricing calculated?

Commercial terms are tailored to the operating model. Common inputs include jurisdictions, currencies, methods, projected volume and ticket size, chargeback exposure, settlement cadence, payout requirements, risk tooling, and support scope. The pricing page shows what should appear in a complete quote.

09Can an existing gateway be migrated?

Yes, migration can be planned alongside the current stack. A phased route normally inventories payment states and webhooks, recreates reporting and reconciliation, tests new provider paths, introduces controlled traffic, and keeps a rollback route until the new flow is stable.

A payment stack should be explainable before it is live.

Share your operating model, markets, methods, and payout needs. We will use them to scope eligibility and the technical route.

Request gateway access