Field	Notes · validation · defaults · edge cases
{row.name} {row.desc && {row.desc}}	{row.notes}

Field

Notes · validation · defaults · edge cases

{row.name} {row.desc && {row.desc}}

{row.notes}

{T("page.devCto","Development · CTO briefing")} The complete map of PayBO for the engineering lead. Every shipped feature is written up as a task with a plain-English title, the business reason, the key terms, testable acceptance criteria, every input field (type + validation + required), and a numbered logic flow. Two foundational panels at the top explain Routing & Cascading and Providers in operational detail.

5 phases · {PHASE_1_TASKS.length + PHASE_2_TASKS.length + PHASE_3_TASKS.length + PHASE_4_TASKS.length + PHASE_5_TASKS.length} tasks · every one in Title · Why · Key terms · Acceptance · Inputs · How it works shape

Internal · CTO & engineering

Informational preview page. This page is not part of the operator's daily workflow — it is a CTO / engineering reference. It opens in a separate browser tab so it does not interfere with the main back office. Live data is read-only.

{/* ============================================================ How to read this doc ============================================================ */}

How to read this doc

Every task in every phase follows the same six-part shape your team agreed on:

Task Title — plain English, action-first.
Why This Matters — 1–2 sentence business reason.
Key Terms Used — short glossary of the gambling / PSP terms in the task.
Acceptance Criteria — 3–6 testable bullets defining "done".
Inputs — every field / parameter with type, validation, required / optional, defaults and edge cases.
How It Works (Step by Step) — numbered logic flow in plain English.

The two foundation panels below (Routing & Cascading · Provider registry) belong to every task — they explain the core engine logic the rest of the platform plugs into.

{/* ============================================================ FOUNDATION 1 · Routing & Cascading — operational summary ============================================================ */}

1 · Objective

Maximise deposit conversion rate.
Optimise costs and liquidity.
Ensure operational continuity.
Provide operator control over PSP allocation.

2 · Routing

Flow.

Receive request (deposit / withdrawal).
Identify: payment method · country (GEO) · amount.
Filter compatible PSPs.
Apply constraints (limits, licenses, availability).
Apply ranking / scoring.
Select PSP.
Send transaction.

Provider Ranking (key feature). Ability to assign a ranking to providers supporting the same payment method.

Objective — give direct control to the operator; influence routing decisions beyond automated logic.
Ranking types — manual (fixed priority, e.g. PSP A > PSP B > PSP C); hybrid (manual + score); context-based (by GEO, by payment method, by transaction amount).

Provider Configuration (key point). To support ranking and advanced routing, each PSP must have a complete configuration profile.

Costs — deposit fee (percentage / flat); withdrawal fee; settlement / transfer costs.
Limits — min/max deposit, min/max withdrawal, daily / monthly limits.
Liquidity — minimum transferable amount from PSP wallet to operator wallet (critical); payout capacity.
Supported GEOs — enabled countries.
Licenses — supported license types (MGA, Curaçao, Anjouan, …).
Supported payment methods — explicit method list.
Technical configuration — endpoints, timeout settings, fallback priority.

Main triggers (routing).

Performance — decreasing success rate; increasing timeout rate.
Costs — lower fees should increase priority.
Liquidity (key) — PSP wallet balance, transfer capacity, minimum thresholds.
Limits — automatic validation of min / max constraints.
GEO and License (key) — PSP must be compatible with user GEO and operator license.
Technical status — PSP downtime or instability leads to exclusion.

Actions (routing).

Select optimal PSP.
Apply operator-defined ranking.
Balance traffic across providers.
Allocate funds across PSPs (key requirement).

Key points routing. Decision happens before transaction execution. Manual ranking is a strategic control lever. Requires complete PSP configuration. Must include liquidity, cost, GEO, and license considerations.

3 · Cascading

Flow.

Send transaction to PSP (from routing).
Receive response.
Success → stop.
Failure → analyse error.
Classify error.
Decide retry (yes / no).
If yes → select next PSP.
Stop after max retries.

Main triggers (cascading) — Error type matrix (key point).

Error type	Action
Timeout / Network	Retry
PSP down	Retry
PSP limit reached	Retry with another PSP
Insufficient funds	Stop
Fraud decline	Depends

Retry policy.

Maximum 2–3 retries.
Always use different PSPs.
Avoid loops.

Actions (cascading).

Automatic retry.
Switch PSP (respecting ranking and constraints).
Controlled stop.

Key points cascading. Triggered after failure. Directly improves conversion rate. Must be selective (not all failures should be retried). Must respect ranking and PSP constraints.

4 · Routing + Cascading (integrated view)

Combined flow.

Routing selects PSP (based on ranking and scoring).
Transaction attempt.
On failure → cascading logic.
Select next valid PSP (based on ranking and rules).
Repeat until success or stop.

Key points global. Routing = proactive optimisation. Cascading = failure recovery. Ranking = operator control. Provider configuration = system foundation.

5 · Best practices

Enable operator-configurable ranking.
Maintain complete and up-to-date PSP configuration.
Use hybrid logic (manual + automated).
Implement real-time monitoring.
Integrate liquidity management (critical).
Enforce GEO and license constraints.

{/* ============================================================ FOUNDATION 2 · Provider registry + liquidity management ============================================================ */}

1 · Provider registry — information the operator needs

The provider registry supports the methods. Certain information must be visible to the operator when defining the portfolio of providers to be used for the same method:

Processing times and minimum withdrawable amount per provider — e.g. T+0, $5,000.
Operations supported under each license — Anjouan, Curaçao, MGA, etc. (deposit, withdrawal, refund).

2 · Live liquidity management

For the different providers, it is important to have real-time visibility of the available balance on each provider wallet, in order to allow timely intervention and active liquidity management.

Objective. Avoid keeping an excessive amount of funds locked within provider wallets, also considering the concrete risk that some providers may become unavailable or blocked.

Mechanism.

Define, for each provider and payment method, a maximum balance threshold for the wallet.
The system supports configurable notifications via Slack or other channels — e.g. when 80% of the configured threshold is reached, allowing the operator to promptly plan withdrawal and fund rebalancing activities.
This works in the opposite direction too: when withdrawal volumes exceed the average and some provider wallets are close to depletion, the operator is notified in advance and enabled to transfer funds to the provider wallets — preventing withdrawal requests from being rejected due to lack of liquidity.

Implementation today. Both directions are wired through the Provider Liquidity Alarms (Phase 1 · Task 4). Operator sets the Floor, Ceiling and Min withdrawable (currency-neutral integers — whatever the PSP's wallet currency is), then adds one or more rules from the 26 available metrics (Wallet near ceiling at 80%, Wallet below floor, Liquidity dropped by, Payout capacity below, Settlement delay, etc.) with their own Slack / email / Telegram destinations.

{/* ============================================================ FOUNDATION 3 · Transaction lifecycle (To-Confirm / Approve / Partial Approve / Reject) ============================================================ */}

1 · Two distinct steps

Every transaction goes through two steps and they must not be confused:

Operator decision — auto-approval engine or human operator decides whether the transaction can be passed to the PSP. Outcomes: Approved, Partial-approved, or Rejected. Approval rate measures this step.
PSP outcome — only runs for transactions the operator approved. The PSP confirms (Balanced) or refuses / errors (Failed). Balanced measures this step.

So a transaction can be Approved by the operator and still end up Failed if the PSP later rejects it. The two rates (Approval rate and Balanced rate) are not the same metric.

2 · To Confirm

Meaning. The transaction is paused in the manual-review queue waiting for an operator to take a decision (Approve, Partial Approve, or Reject). The PSP has not seen the transaction yet.

When a transaction lands in To Confirm.

Withdrawal amount > the method's auto-approve threshold.
Deposit / withdrawal flagged by a fraud rule (high-risk player, suspicious geo, velocity).
Route's execution mode is MANUAL — the operator must approve every step of the cascade.
Player is on a watchlist or operator-suspended list.

Queue sort. Spec-mandated: amount DESC, then created_at ASC — biggest payouts surface first, ties broken by oldest age.

SLA. Critical-severity alarm fires when the oldest To-Confirm transaction crosses 30 minutes (configurable in Settings → Alarms → To-Confirm queue age).

3 · Approve (full)

What it does. Operator releases the transaction from the To-Confirm queue at its full amount. It is then sent to the PSP through the route's chain.

Flow.

Operator clicks Approve on the transaction row → modal opens.
Operator writes a free-text note (min 10 chars) explaining the decision.
On Confirm, the engine writes an immutable Activity-log entry: operator ID + timestamp + before-state (to_confirm) + after-state (approved) + full note text.
Transaction status flips to approved and the routing engine sends it to the first PSP in the chain.
PSP outcome — if the PSP confirms, status becomes Balanced; if the PSP refuses / errors, status becomes Failed (cascade may retry the next PSP first, depending on the route's triggers).

Counts toward. Approval rate (numerator). Balanced rate counts it only if the PSP confirms in step 5.

4 · Partial Approve

What it does. Operator releases the transaction for a smaller amount than the player requested. The remainder is recorded as a partial reject.

When to use it. Common on withdrawals: a player asks to cash out 10,000 but their available-to-withdraw balance after wagering requirements is only 7,500 — operator partial-approves 7,500 and the system logs the 2,500 remainder as Partial reject.

Flow.

Operator clicks Partial Approve on the To-Confirm row → modal opens.
Operator enters the Approved amount (must be > 0 and < the original amount).
Operator writes the note (min 10 chars).
On Confirm, two Activity-log entries are written:
- OPERATOR action OPERATOR_PARTIAL_APPROVED with the approved amount.
- SYSTEM action PARTIAL_REJECT with the remainder, so the rejected portion is auditable.
The approved-amount slice is sent to the PSP exactly like a full approval; PSP outcome decides Balanced vs Failed.

Counts toward. Approval rate (numerator) for the approved portion. The remainder counts toward the Reject side of the operator-decision step.

5 · Reject

What it does. Operator refuses the transaction. It is not sent to the PSP. Terminal state.

When to use it. Failed KYC, hard fraud signal, exceeded operator-side limits the engine should have caught, manually-blocked method, requested-by-player cancellation, or any case where the transaction should not reach any PSP.

Flow.

Operator clicks Reject on the row → modal opens.
Operator writes the note (min 10 chars) — this is the rationale that the player support team will reference if the player calls in.
On Confirm, the Activity log captures operator ID + timestamp + before-state (to_confirm) + after-state (rejected) + full note text.
Transaction status flips to rejected. The player's balance / wager / KYC record is unchanged. No PSP is involved.

Counts toward. The denominator of Approval rate (lowers the rate). Never counts toward Balanced.

6 · Status summary — at-a-glance

Status	Who sets it	Next state	Counts toward
Created	Engine	→ Auto-approved · To-Confirm · Declined (limits)	—
To-Confirm	Engine (when amount or risk flags)	→ Approved · Partial-approved · Rejected	Queue depth
Approved	Auto-approval engine or operator	→ Sent to PSP → Balanced · Failed	Approval rate (numerator)
Partial-approved	Operator	Same as Approved for the approved slice; remainder logged as Partial reject	Approval rate (numerator, partial)
Rejected	Operator	Terminal	Approval rate (denominator only)
Pending	Engine (after Sent to PSP)	→ Balanced · Failed	—
Balanced	PSP webhook	Terminal — success	Balanced rate
Failed	PSP webhook (or cascade timeout)	Terminal — failure (cascade may have retried first)	—

{/* ============================================================ PHASE 1 · SETTINGS ============================================================ */} {PHASE_1_TASKS.map((t, i) => )} {/* ============================================================ PHASE 2 · PAYMENT METHODS ============================================================ */} {PHASE_2_TASKS.map((t, i) => )} {/* ============================================================ PHASE 3 · PLAYERS ============================================================ */} {PHASE_3_TASKS.map((t, i) => )} {/* ============================================================ PHASE 4 · REPORTS & ANALYTICS ============================================================ */} {PHASE_4_TASKS.map((t, i) => )} {/* ============================================================ PHASE 5 · FULL PROJECT COMPLETE ============================================================ */} {PHASE_5_TASKS.map((t, i) => )} {/* ============================================================ Closing note ============================================================ */}

Open decisions still on the table

Stack — runtime, DB, queue, real-time channel. Intentionally not prescribed here.
KYC vendor — Player 360 → KYC ships as placeholder; pick a vendor (Sumsub / Onfido / Veriff) for v2.
Anomaly engine — Overview tab consumes a mock ANOMALIES stream; v1 needs the real detector.
Restore-to-version on routes — Route history is captured today; one-click restore is scoped for v2.
Bonus / FX cost in Profit — Profit excludes them today; CFO call on whether to add them in v2.