Payment Infrastructure

Multi-tenant | Multi-PSP | Cascading | Adapter Pattern

Prototype

Infrastructure

Architecture Overview

FRONTEND LAYER

Checkout UI

Phase 2

Deposit | Withdrawal

Admin Panel

Phase 4

PSP Management | Routing

Status Polling

Phase 2

Webhook events -- UI

API GATEWAY

Auth & Brand

Phase 1

JWT + Brand context

Rate Limiting

Phase 2

Velocity checks

Request Router

Phase 2

Deposit | Withdrawal routes

ORCHESTRATION LAYER

Payment Orchestrator

Phase 2

Routing rules engine

Cascade Manager

Phase 2

Failover PSP1 → PSP2 → PSP3

State Machine

Phase 1

INITIATED → PROCESSING → DONE

Personalization

Phase 5

BIN + preferred method

Limits & Rules

Phase 3

Min/max, velocity, KYC gate

ADAPTER LAYER -- IPaymentProvider

Unified Interface

Phase 1

initiateDeposit | getStatus | handleWebhook

PSP #1 Adapter

Phase 1

Your current provider

PSP #2 Adapter

Phase 5

Next integration

PSP #N Adapter

Phase 5

Pluggable

EXTERNAL PSPs

PSP #1 API

Phase 1

Cards | Crypto

PSP #2 API

Phase 5

e-Wallets

PSP #N API

Phase 5

Local methods

SUPPORT SERVICES

Wallet Engine

Phase 2

Balance | ledger

KYC | AML

Phase 3

Verification gates

Bonus Engine

Phase 3

Wager | locks

Reconciliation

Phase 2

Nightly PSP sync

Key Flows & Reference

DEPOSIT FLOW

01Player → Checkout UI

02 → API Gateway (auth + brand)

03 → Orchestrator (routing rules)

04 → Cascade Manager (PSP select)

05 → Adapter Layer (normalize)

06 → PSP API (execute)

07← Webhook → State Machine

08← Balance update → Wallet

TRANSACTION STATES

INITIATED

PROCESSING

PENDING_CONFIRMATION

COMPLETED

FAILED

TIMED_OUT → reconciliation

CANCELLED

ROUTING DIMENSIONS

Brandbrand_id → PSP config

GEOcountry → methods + PSP

Currencycurrency → PSP filter

Directiondeposit vs withdrawal

PlayerBIN + last success

Cascadepriority + health score

Reference Documents

Data Model

Phase 0

DB tables: transactions, psp_configs…

State Machine

Phase 1

PassimPay statuses → UnifiedStatus

Unified Interface

Phase 1

IPaymentProvider types & API contract

Auth & Brand Spec

Phase 1

JWT validation & brand resolution

PSP #1 Adapter

Phase 1

PassimPay implementation spec

PSP #1 API

Phase 1

PassimPay service overview & onboarding

Status Polling

Phase 2

How frontend tracks transaction status

Delivery Phases

Architecture & Contracts

Documents only -- no code

Output:FigJam with diagrams + Notion with contracts. All three parties have signed off.

Adapter Layer + First PSP

Backend only -- frontend not needed yet

Output:Deposit via PSP #1 is working. Adapter tests in place.

Orchestration Layer

Backend continues, frontend starts in parallel

Output:Working end-to-end deposit flow with one PSP and basic routing.

Withdrawal + Compliance

Output:Full payment cycle: deposit → play → withdraw.

Admin Panel

Output:Operations team can manage PSPs and routing without engineer involvement.

Personalization + Second PSP

Output:Checkout conversion improves. Second PSP connected with zero interface changes.

Advanced Routing + Risk

Output:Self-optimizing routing. Full risk and analytics layer.

DEPO44 | PAYMENT MODULE v1 | PHASE 0 ARCHITECTURE