06.04 MVP Acceptance Criteria

Status: draft for discussion

1. Goal

This document defines business-level acceptance criteria for the MVP.

It is not a test plan. The development and QA teams propose exact test cases and automation scope.

2. Merchant Setup

MVP can be accepted only if:

• platform user can create merchant;
• platform user can create brand under merchant;
• platform user or allowed merchant user can create payment method inside brand;
• platform user can grant provider access to merchant;
• users and roles can be managed according to business visibility rules;
• API key can be created and rotated with grace period;
• saved secrets are not visible after saving.

3. Routing Setup

MVP can be accepted only if:

• Payment Method routing can be configured;
• MASTER MID routing can be configured;
• regular rules are visually separate from fallback route;
• draft/publish flow works;
• previous versions remain visible;
• routing can be previewed or otherwise validated before publish;
• inactive or invalid configuration cannot silently accept production traffic.

4. Deposit Flow

MVP can be accepted only if:

• merchant can create deposit through integration;
• platform user can create test deposit through Back Office;
• merchant user can create test deposit through Back Office if access allows it;
• customer can open Hosted Payment Page;
• required additional fields can be collected on Hosted Payment Page;
• payment can continue through redirect or supported payment action;
• transaction receives a clear result.

5. Transaction Processing

MVP can be accepted only if:

• provider callback can update supported statuses;
• unsupported provider statuses are stored for investigation without changing transaction to unsupported status;
• duplicate callbacks do not break transaction;
• suspicious callbacks are visible to platform users;
• final status cannot be changed automatically;
• manual correction can change final status when access allows it.

6. Merchant Webhooks

MVP can be accepted only if:

• merchant receives webhook on PROCESSING and final statuses;
• failed webhook delivery is retried;
• webhook attempts are visible in transaction details;
• manual resend is possible with access;
• webhook contains business error code and description when transaction failed or was rejected;
• raw provider data is not sent.

7. Investigation

MVP can be accepted only if:

• transaction timeline explains what happened;
• routing path is visible according to access;
• provider details are hidden from merchant users without provider access;
• platform user can investigate ignored, duplicate, rejected, or suspicious callbacks;
• manual correction is visible in timeline and audit history;
• webhook history is visible.

8. Financial Context

MVP can be accepted only if:

• original amount and currency are stored;
• amount in EUR is stored;
• conversion rate and conversion time are visible where needed;
• conversion fee can be applied on SUB MID / SUB MID AGGREGATOR level;
• processing fee can be applied on MASTER MID level;
• threshold-based processing fee can be represented in Back Office.

9. Legacy Migration

MVP can be accepted only if:

• historical transactions can be migrated after old traffic is stopped for a method;
• migration target includes merchant, brand, and payment method;
• migrated transactions are read-only;
• migrated transactions are marked as legacy;
• migration result/report is available.

10. Operational Readiness

MVP can be accepted only if:

• provider names are hidden from merchant users without access;
• audit logs exist for important Back Office changes;
• success rate drop, webhook delivery issues, and suspicious callbacks can be detected or investigated;
• load test approach covers expected MVP traffic and short peaks;
• public merchant documentation covers integration, API keys, deposit creation, statuses, webhooks, errors, and sandbox flow.

11. Release Blockers

The MVP must not be released if:

• merchant cannot create a deposit;
• customer cannot complete Hosted Payment Page flow;
• routing can publish invalid configuration;
• provider names are exposed to merchant users without access;
• saved secrets can be viewed;
• webhook delivery cannot be investigated;
• transaction timeline does not explain the result;
• access rules allow users to see data outside their business context.