OneWallet — Payment Manager v2

Executive Presentation

Audience: Project Manager / Leadership
Date: April 2026
Status: Phase 1 active · B7 (IPPS) in progress

---

What This Document Covers

This pack explains how the new Payment Manager (PM v2) works, why it was built this way, and how it satisfies all regulatory and compliance requirements of the Bank of Thailand (BOT).

Document	Contents
01 — System Architecture	All service layers and how they connect
02 — Payment Flows	How an instant P2P and a PromptPay withdrawal work step-by-step
03 — Compliance & Security	BOT requirements and where each is enforced
04 — Reliability & Data Integrity	Crash safety, idempotency, reconciliation
05 — Roadmap	Phase 1→2A→2B→2C delivery plan

---

The Problem We Solved

The previous system embedded payment logic inside the Dart/Serverpod monolith and delegated ledger operations to a third-party vendor (blnkfinance). This created three critical issues:

Problem	Impact
Payment bugs mixed with auth code	Hard to isolate incidents, slow fixes
blnkfinance as black-box ledger	No control over balance accuracy or auditability
Cannot scale payments independently	Auth Center restarts = payment downtime

---

What We Built

A standalone Node.js Payment Manager with TigerBeetle as the financial ledger:

Before:  Flutter → Serverpod monolith (auth + payments + blnkfinance)

After:   Flutter → nginx → Auth Center (auth only)
                         → Payment Manager (payments, TigerBeetle)

Key principles: - One entry point — POST /intents accepts all payment types from all callers - TigerBeetle is the single source of financial truth — balances come from the ledger, not from a database count - Every channel is a plug-in — adding a new PSP means adding a new channel file, not modifying core logic - Crash-safe by design — no payment can be lost even if the server dies mid-transaction