Skip to content
PokerEnginePro
Integrations

Plugged in to the best.
Two or more of every kind.

Identity, screening, location, payments, crypto, messaging and app-store purchases, each from established vendors — at least two of every kind. Each operator chooses its own, per market, and every logo below opens that vendor's site.

Know your player

Who they are, checked.
Before the money moves.

Identity and age, sanctions and politically exposed persons, and the pattern of the money over time — each checked by specialists, with the platform's own rules always running beside them.

01 · 4 vendors

Identity and age verification

Documents, liveness and database checks, tiered by what a player needs to do.

  • Four tiers — unverified, identity verified, enhanced due diligence and high limits — so a player is asked for only what the next step needs.
  • Age is checked against the verified date of birth, to each market's minimum age.
  • Enhanced due diligence on a politically exposed person, a partial sanctions match, a high-risk country or a money threshold.
  • Document images never pass through the platform, and no national ID number is stored.

02 · 2 vendors

Sanctions and PEP screening

Every player screened at sign-up, at verification and again when the result goes stale.

  • Screened at registration, on verification, on every monitoring update and whenever a result goes stale.
  • A suspected match blocks deposits and play until it is reviewed; clearing it needs a second approver.
  • The player is never told of a list.

03 · Built-in rules + 1 vendor

Anti-money-laundering monitoring

Transaction monitoring from a vendor, with the platform's own rules always running beside it.

  • The platform's own rules always run: each market's thresholds, cumulative deposits and withdrawals, rapid in-and-out, unusual stakes and chip dumping.
  • Alerts become cases — no action, restrict or report — and a restriction is lifted only by a second approver.
  • Report drafts in the UK NCA and Malta FIAU formats.

Where they play

Where they are.
And whether they may play.

A player's location decides their market, and their market decides the rules. Certified location where the regulator asks for it, the national self-exclusion registers wherever they exist.

04 · 4 vendors

Geolocation

Certified device location where a regulator requires it, IP location and VPN detection everywhere else.

  • Certified device location where the market requires it; IP location and VPN, proxy and Tor detection everywhere.
  • Checked on connect and on every change of IP, and again every 30 minutes in Great Britain and Malta, every 20 in the US states and Ontario.
  • A failed re-check sits the player out after the current hand. Every check is stored.

05 · 13 registers

Self-exclusion registers

A player who has excluded themselves nationally is kept out here too: the national and state registers are checked before play, beside the operator's own list.

  • Checked before a real-money session, in the markets whose rules require it.
  • US state lists arrive as file feeds and are kept only as keyed hashes, never as names.
  • A list that is missing or stale fails closed: no real money until it is current.
  • Self-exclusion on the site also goes on the operator's own list, checked beside the national ones.

Money in, money out

Payments and crypto.
Hosted, screened, closed loop.

Deposits arrive through the providers' own hosted pages and leave the way they came. Every movement is a balanced entry on the same ledger as the game's chips.

06 · 3 vendors

Payments

Cards, e-wallets, prepaid and pay-by-bank through hosted pages: card data never touches the platform.

  • Hosted pages and fields only: card data never touches the platform.
  • Withdrawals are closed loop — back to the method the money came from.
  • A pending withdrawal waits in a hold account; above €2,000, £1,750, $2,200 or C$3,000 it needs a second approver.
  • A segregated player-funds statement and settlement reconciliation.

07 · 4 vendors

Crypto

Institutional custody, crypto processing, market rates with a peg check, and on-chain screening of every deposit and withdrawal address.

  • USDT and USDC on Ethereum, USDT on Tron — in the markets that allow crypto.
  • Every confirmed deposit and every withdrawal address screened on chain; high risk holds the money.
  • The ledger stays in fiat, with the rate, its source and the time recorded for every deposit.

08 · 6 vendors

Email, SMS and push

Transactional and marketing messages with consent, suppression and per-market templates.

  • Email through Amazon SES, the default, Postmark or any SMTP server.
  • SMS through Twilio, the default, or Infobip; push through Firebase Cloud Messaging and Apple's push service.
  • Every message is sent on behalf of the operator it belongs to.

09 · 2 vendors

In-app purchases

Chip purchases in the mobile apps, checked on the server with the store itself: refunds and chargebacks take the chips back.

  • Apple's signed transactions are checked against Apple's certificate chain; Google Play purchases are validated through the Play API.
  • A purchase is credited once, and only to the account the app bound to it: a replayed receipt credits nothing.
  • Store refunds and chargebacks take the chips back through the chip store's own refund booking.
  • Chip prices are set per channel: web, App Store and Google Play.

How a vendor plugs in

Chosen per operator.
And per market.

Every outside service sits behind an interface the platform owns. Which vendor answers it is configuration, not code — set per operator, per kind of check and per market, with a default behind them.
  1. A check is needed

    Identity, location, screening or a payment, for a player of one operator.

  2. 1 · The market's choice

    A vendor chosen for the player's market — a US state, a province.

  3. 2 · The country's choice

    Otherwise, a vendor chosen for the player's country.

  4. 3 · The operator's default

    Otherwise, the operator's default for this kind of check.

  5. The vendor's adapter

    The first match wins and calls the vendor. A development fake is refused in Production.

01

Per operator, per interface, per market

Each operator chooses a vendor for each interface, and may choose another for a market or a country. The market's choice wins, then the country's, then the operator's default.

02

Fakes stay in development

Every kind of vendor has a development fake for building and testing. Production refuses a fake: an interface without a real vendor answers “not configured”, it never pretends.

03

Held to the vendor's own documentation

Every adapter is built from the vendor's published documentation and checked by contract tests against recorded examples of its documented behaviour.

04

Your accounts, your contracts

Each operator opens its own vendor accounts as merchant of record, and confirms every adapter in the vendor's sandbox before going live. The licence and the relationship stay with the operator.

05

Two people to change a vendor

Configuring or removing a vendor is a maker-checker change: one person proposes it, a second approves it, and both are in the audit log.

06Another vendor?A new vendor is an adapter against the same interface and the same contract tests — not a fork.The adapter interfaces

Your vendors, plugged in.
Your accounts, your licence.

A walkthrough of identity checks, the payment pages, the routing per market and the back office where your compliance team configures it all.