Payment Reconciliation for Multi‑Brand Casino Operations and Multiple PSPs · Monarchs

Introduction

Accurate payment reconciliation is the backbone of any iGaming operation that runs several casino brands under a single umbrella. When each brand uses a different payment service provider (PSP), the complexity of matching deposits, withdrawals, chargebacks, and fees multiplies. A failure in this process leads to incorrect gross gaming revenue (GGR) calculations, compliance gaps, and frustrated players. This article outlines an engineering‑led approach to building a scalable reconciliation layer that works across multi‑brand casino platforms and heterogeneous PSP integrations.

Core Challenges in Multi‑Brand Reconciliation

1. Heterogeneous Transaction Formats

Different PSPs expose APIs that return transaction data in varied structures – CSV, JSON, XML, or proprietary binary blobs. Field names, timestamp formats, currency codes, and status enumerations rarely align.

2. Brand‑Specific Business Rules

Each casino brand may apply unique fee schedules, bonus‑abuse detection thresholds, and withdrawal limits. Reconciliation must respect these rules while still providing a unified view for the back‑office.

3. Currency and Exchange‑Rate Management

Multi‑brand operators often serve players in multiple jurisdictions. Deposits may arrive in USD, EUR, or crypto (USDT/BTC). Converting these amounts to the reporting currency without losing precision is critical for GGR/NGR calculations.

4. Real‑Time vs. Batch Processing

Some PSPs push real‑time webhooks, while others require nightly batch pulls. The reconciliation engine must harmonise both streams without creating duplicate records.

5. Regulatory and Audit Requirements

Licenses from MGA, UKGC, or Curacao demand a complete audit trail of every financial movement. The system must retain immutable logs, support geo‑blocking checks, and be able to produce regulator‑ready reports on demand.

Architectural Blueprint

Below is a reference architecture that satisfies the above challenges while remaining extensible for future PSP additions.

+-------------------+      +-------------------+      +-------------------+
|  Brand A Casino   |      |  Brand B Casino   | ... |  Brand N Casino   |
+-------------------+      +-------------------+      +-------------------+
          |                         |                         |
          |   Unified Player Wallet (microservice)            |
          +-------------------+-------------------+----------+
                              |   Transaction Hub (Kafka)   |
                              +-------------------+----------+
                                            |
               +----------------------------+----------------------------+
               |                                                         |
    +----------+-----------+                                 +----------+-----------+
    |  PSP Adapter Layer   |                                 |  Reconciliation Core |
    +----------+-----------+                                 +----------+-----------+
               |                                                         |
   +-----------+-----------+                                 +-----------+-----------+
   |   Normalisation Service   |                               |   Settlement Engine   |
   +-----------+-----------+                               +-----------+-----------+
               |                                                         |
          +----+----+                                            +-----+-----+
          |   DB   |                                            |   DB   |
          +--------+                                            +----------+

Key Components

Unified Player Wallet – A single source of truth for player balances across all brands. All deposit/withdrawal events funnel through this service.
Transaction Hub (Kafka) – Guarantees ordered, durable event streaming. Each PSP adapter publishes raw transaction events to dedicated topics.
PSP Adapter Layer – A set of micro‑services, one per PSP, responsible for pulling data (REST, SFTP, SOAP) and emitting a normalized event schema.
Normalisation Service – Transforms heterogeneous payloads into a canonical PaymentEvent object: {pspId, brandId, playerId, amount, currency, type, status, timestamp, externalTxId}.
Reconciliation Core – Matches inbound PaymentEvents against internal wallet movements. Utilises deterministic matching keys (playerId+brandId+externalTxId) and a configurable tolerance window.
Settlement Engine – Applies brand‑specific fee rules, updates GGR/NGR, and triggers downstream accounting exports.
Databases – Two separate stores: an immutable ledger (append‑only, e.g., PostgreSQL with pg_partman or Apache Iceberg) for audit, and a relational reporting DB for BI dashboards.

Data Flow Walkthrough

Ingestion – PSP A pushes a webhook for a €100 deposit. PSP B’s nightly batch file contains a USD withdrawal of $150. Both adapters emit raw events.
Normalization – The Normalisation Service maps fields to the canonical schema, converts timestamps to UTC, and records the original payload for audit.
Enrichment – The service adds brand metadata (fee percentages, bonus eligibility) and resolves the player’s internal UUID from the external ID supplied by the PSP.
Matching – The Reconciliation Core checks if a corresponding wallet credit/debit already exists. If a match is found, the status is set to settled; otherwise, the event is staged for manual review.
Settlement – Upon successful match, the Settlement Engine applies brand‑specific logic:
- Deduct 2.5% processing fee for Brand A.
- Flag deposits below €10 for potential bonus abuse.
- Convert USD to EUR using the daily FX rate stored in a secure key‑value store.
Reporting – Updated GGR/NGR figures are written to the reporting DB. Real‑time dashboards consume these tables via a BI tool (e.g., Tableau, Power BI).
Audit Trail – Every step writes an immutable log entry to the ledger DB, including the raw PSP payload, transformation metadata, and final settlement outcome.

Handling Edge Cases

Duplicate Transactions

PSPs may resend webhooks after a timeout. The matching algorithm must be idempotent: use a composite key of pspId+externalTxId+brandId. If a duplicate arrives, compare the amount and status; if identical, discard silently.

Partial Refunds and Chargebacks

Chargebacks arrive as separate events with a distinct type. The engine treats them as negative transactions, reverses the original GGR impact, and flags the player for potential fraud scoring.

Currency Rounding

When converting crypto (e.g., USDT) to fiat, retain at least eight decimal places during internal calculations. Round only at the point of reporting to avoid cumulative errors.

Regulatory Locks

If a jurisdiction imposes a geo‑block on a specific PSP, the adapter should automatically disable ingestion for that region and raise an alert. The ledger must still retain any pre‑block transactions for audit.

Monitoring and Alerting

Lag Monitoring – Track the time between PSP event receipt and settlement. Alert if latency exceeds the SLA (e.g., 5 minutes for real‑time webhooks).
Reconciliation Gap – Daily report of unmatched events. Critical if the gap > 0.5 % of total transaction volume.
Fee Drift – Compare calculated fees against PSP‑provided fee reports. Trigger alerts on variance > 2 %.
Security – Enforce mTLS between adapters and the Transaction Hub. Rotate certificates quarterly and log all handshake failures.

Scaling Considerations

Partitioning – Kafka topics should be partitioned by brandId to ensure that high‑traffic brands do not starve smaller ones.
Horizontal Scaling – Deploy adapters and the Normalisation Service as stateless containers behind an orchestrator (K8s). Autoscale based on inbound event rate.
Database Sharding – For the immutable ledger, consider time‑based sharding (monthly partitions) to keep query performance high.
Cache Layer – Use a distributed cache (Redis) for frequently accessed FX rates and brand fee tables to reduce DB load.

Compliance Checklist

Requirement	Implementation
Immutable audit log	Append‑only ledger with cryptographic hash chaining
Data retention (5 years)	Automated partition expiry policy
GDPR / data subject access	Separate personal data store with encryption keys per brand
AML/KYC linkage	Reconciliation events include `playerKycStatus` flag; unsettled high‑value transactions trigger AML review
regulator‑ready export	CSV/JSON export templates per jurisdiction, generated on demand

Conclusion

Designing a payment reconciliation engine for a multi‑brand casino operator is not a generic fintech problem; it demands deep integration with gambling‑specific concepts such as GGR calculation, bonus‑abuse rules, and jurisdictional compliance. By normalising PSP data, leveraging a deterministic matching engine, and enforcing immutable audit trails, operators can achieve real‑time accuracy, reduce manual review overhead, and satisfy regulator expectations. The modular architecture described here scales horizontally, accommodates new PSPs with minimal code changes, and keeps the engineering team focused on delivering player‑centric value rather than firefighting financial mismatches.

For a detailed technical review or a custom implementation roadmap, contact our architecture team at /contact/.