01. MVP Scope

Status: draft for discussion

1. MVP Goal

The MVP must prove that the new deposit model works end-to-end.

A successful MVP means that:

• a platform user can create a merchant;
• a platform user or merchant user can configure a brand and a payment method inside that brand;
• routing can be configured through a clear blueprint;
• a merchant can create a deposit;
• a customer can complete the Hosted Payment Page flow;
• a transaction goes through routing and receives a clear result;
• a merchant receives a webhook;
• a transaction can be investigated in Back Office;
• real provider names are not exposed to merchant users without separate access.

The MVP must be strong enough to migrate the first merchant with several brands, several payment methods, and several providers behind routing.

2. What Is Included in the MVP

The MVP includes:

• deposits;
• merchant and brand management;
• payment methods inside a brand;
• routing on Payment Method and MASTER MID levels;
• MASTER MID GROUP / MASTER MID;
• SUB MID GROUP / SUB MID / SUB MID AGGREGATOR;
• Hosted Payment Page;
• provider callback handling;
• merchant webhooks;
• transaction timeline;
• velocity limits;
• FX, conversion fee, and processing fee;
• users, roles, and access;
• API keys;
• audit logs;
• manual transaction correction;
• legacy transaction migration;
• test provider / sandbox flow;
• basic merchant documentation;
• transaction export.

3. What Is Not Included in the MVP

The MVP does not include:

• withdrawals;
• approve/cancel withdrawals;
• refunds;
• anti-fraud/manual review;
• dashboards;
• advanced reports;
• provider polling;
• full Hosted Payment Page customization;
• full self-service setup of provider capabilities by merchants.

These items can be planned later, but they must not block the first deposit-focused release.

4. Payment Methods

The system must work with specific business payment methods, not with providers as payment methods.

Initial methods:

• Cards;
• Apple Pay;
• Google Pay;
• Open Banking;
• BLIK.

APM is not used as a generic method. If Skrill, Quick Checkout, or another method is needed, it must be described as a separate payment method.

Future method catalog should be able to support market-relevant methods such as Skrill, Neteller, Paysafecard, crypto, open banking, bank transfer, instant banking, and local methods by country.

These future methods are not automatically included in the MVP unless selected for the first merchant.

5. Merchant Transition

The first merchant moves to the new system gradually: one payment method inside a brand at a time.

Business expectations:

• the old system continues working while the merchant uses the old flow;
• the merchant moves to the new flow within agreed timelines;
• after old traffic stops for a specific method, historical transactions can be migrated;
• migrated transactions are read-only and visually marked as legacy.

6. Business Load Expectation

The system should be designed with the target of supporting 5 million transactions per month.

This equals roughly 114 transactions per minute on average, but traffic will not be linear.

The business expects the system to handle short peaks around 10 transactions per second for several minutes without breaking merchant deposit creation.

Exact technical scaling, performance testing, and architecture decisions are proposed by the development team.

7. What the Development Team Decides

The development team proposes architecture, integration contracts, data storage model, event model, monitoring, and the technical access model.