00. Context

Status: draft for discussion

1. Why a New Version Is Needed

The current system has grown around providers for a long time. Because of this, the product became hard to configure, support, and explain.

The main problem: merchants should work with clear payment methods, not provider names.

Today this creates several issues:

• Back Office is hard to use without knowing the internal system logic;
• some settings are unnecessary or incomplete;
• routing is hard to verify and explain;
• errors are hard to investigate;
• it is not always clear at which step a transaction failed;
• the team spends time supporting functionality that the business does not need.

2. Product Context

We are building a white-label payment orchestrator for the casino, online business, or payment processors market.

The product must help operators and white-label operators accept deposits through clear payment methods, route traffic through the best available execution path, hide sensitive provider information, and investigate every transaction quickly.

For this market, the product must be especially strong in:

• deposit conversion;
• payment method availability by brand and country;
• fast and safe routing changes;
• fallback when an execution option is unavailable;
• clear transaction investigation for support teams;
• safe provider visibility;
• reliable merchant webhooks;
• operational control without requiring developer knowledge.

The end user of the payment platform is a natural person.

The merchant is the business client that accepts payments through the platform.

Brand represents the brand/URL under the merchant. Payment methods are configured inside the brand.

3. Product Promise

The new version should become the operational control center for deposits.

It should allow the platform team and merchant team to understand:

• which payment methods are available;
• how traffic is routed;
• why a transaction succeeded, failed, was rejected, or is still processing;
• whether the merchant was notified;
• which configuration version was active;
• which data is safe to show and which data must stay hidden.

The product should feel clear, fast, and safe for daily use.

Users should not need to understand internal architecture to operate deposits.

4. How the Business Sees the New System

The new version should become a clear payment orchestration product.

Business expectations:

• merchants work with clear payment methods;
• providers are selected inside routing;
• Back Office separates platform and merchant experiences;
• every transaction has a clear history;
• hidden provider details are not exposed without separate access;
• configuration changes can be managed safely through a clear lifecycle;
• support can quickly understand why a transaction succeeded or failed.

5. Design-First Approach

Before development starts, the team must align on:

• which scenarios are included in the MVP;
• who participates in each scenario;
• which actions are available to users;
• what the user sees;
• which data is hidden;
• which business rules apply;
• which edge cases matter for launch.

After that, the development team proposes the technical solution.

6. What Is Not Fixed Here

This package does not fix:

• internal data storage structure;
• exact technical integration contracts;
• internal processing model;
• technical access names;
• asynchronous processing details;
• exact monitoring implementation.

These decisions should be proposed by the development team based on the business requirements.