Technical reference

The engineering companion to the payments pages. Where the operator pages explain what to do, this section documents the actual endpoints, request and response shapes, and status enums behind them.

This is a reference, not the handbook

Everything here is taken from the route, controller and model files. It is aimed at engineers and integrators, not operators. If you are running a brand day to day, start with Payments overview. Endpoint paths and field names change; treat this as a map of the code as it stands, and check the source before depending on a detail.

What is covered

Page	System
End-to-end flows	Each path start to finish, with worked request/response examples. Start here.
Admin panel API	admin-backend/mono-backend — Express. Manual credit/debit, withdrawal review, manual bank, settings.
Player and provider API	player-backend management services — Fastify. Player deposits, withdrawals, wallet, provider callbacks.
Data model	Transaction schemas and the status / method enums both systems share.

Two backends

Payments spans two independent backends:

• The admin backend (mono-backend) is a single Express service. It is what the admin panel calls. Manual adjustments, withdrawal approval and configuration live here.
• The player backend is a set of Fastify microservices — player-management, wallet-management, and one service per payment provider under payment-management/. This is what the player site calls, and where provider callbacks land.

The two share the same MongoDB transaction collections (deposittransactions, withdrawaltransactions) and the same wallet balances, which is how an action in one is visible in the other.

Admin API conventions

• Base path. Routes are mounted under a prefix that is /api in local development and empty in deployed environments (const prefix = isLocal ? "/api" : ""). Paths in this reference are written from the mount point — e.g. /wallets/..., which is /api/wallets/... locally.
• adminId in the path. Almost every admin route ends in /:adminId. It identifies the administrator performing the action and is recorded on the resulting transaction (createdBy, approved.approved_by). It is a path parameter, not a body field.
• Authorization. Sensitive routes are wrapped in authorize([...permissions]). The required permission strings are listed per endpoint. Routes are also split by role (routeByRole) so affiliate users hit a different handler.
• Idempotency. Manual credit and debit accept an idempotency_key. A key already seen returns 409 with the existing transaction rather than moving money twice.

Player API conventions

• Services and prefixes. Each Fastify service registers its own route prefix — player-management under /player/..., wallet-management under /wallet/..., and each provider under its own name (/payzeasy/..., /alphapo/..., and so on). They sit behind API gateways rather than being called directly by the browser.
• Idempotency. Every deposit- and withdrawal-creation endpoint takes an idempotency_key.
• Callbacks. Providers confirm asynchronously by calling a callback endpoint. Each provider has its own, and each normalises the provider's own status vocabulary into the internal enum in Data model.

Provenance

The admin endpoints, request bodies and enums here were read directly from the route, model and controller files. The player-side endpoint list was extracted from the Fastify route registrations across the services. Where a detail was inferred rather than seen, the page says so.