Bildery

Payment module

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

Prototype
Infrastructure
1.

Architecture Overview

2.

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
3.

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

Outbound Webhooks
Next

Push events to operators -- retry, signing, delivery

Rate Limiting
Phase 2

Velocity checks & abuse protection

Request Router
Phase 2

Deposit & withdrawal endpoints + validation

Payment Orchestrator
Phase 2

PSP selection, routing rules, cascade logic

Cascade Manager
Phase 2

Failover logic: PSP1 → PSP2 → PSP3

Wallet Engine
Phase 2

Balance: credit, debit, hold. Built on Orleans

Reconciliation
Phase 2

Nightly PSP sync, discrepancy detection & fix

FX / Multi-currency
Phase 3

Rate lock, settlement vs display, historical rates

Limits & Rules
Phase 3

Min/max, caps, KYC gates, RG, AML -- rule engine

KYC | AML
Phase 3

Identity verification, sanctions, AML monitoring

Bonus Engine
Phase 3

Deposit match, wagering tracking, balance lock, expiry

Admin Panel
Phase 4

PSP, routing, methods, partners, compliance — control plane

Chargeback Management
Phase 4

Dispute lifecycle, evidence collection, chargeback rate control

Personalization
Phase 5

BIN lookup, preferred method, GEO context, PSP success rate

How to add a new PSP
Next

Checklist for integrating any new payment provider

4.

Delivery Phases

0
Architecture & Contracts

Documents only -- no code

Output:FigJam with diagrams + Notion with contracts. All three parties have signed off.
1
Adapter Layer + First PSP

Backend only -- frontend not needed yet

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

Backend continues, frontend starts in parallel

Output:Working end-to-end deposit flow with one PSP and basic routing.
3
Withdrawal + Compliance
Output:Full payment cycle: deposit → play → withdraw.
4
Admin Panel
Output:Operations team can manage PSPs and routing without engineer involvement.
5
Personalization

Checkout becomes data-driven; next PSP process documented

Output:Checkout surfaces the right method first. Any future PSP can be added by following the documented checklist -- zero changes to orchestration or checkout.
6
Advanced Routing + Risk

Not planned yet -- scope TBD

Output:Self-optimizing routing based on real-time success rates. Full risk scoring and analytics layer. Scope and specs to be defined.
DEPO44 | PAYMENT MODULE v1 | PHASE 0 ARCHITECTURE