03.16 Back Office Merchant Onboarding Flow

Status: draft for discussion

1. Goal

This document describes how a platform user prepares a merchant for deposit processing in Back Office.

The goal is to make the setup flow understandable, repeatable, and safe.

2. Main Flow

1. Platform user creates merchant.
2. Platform user creates one or more brands under the merchant.
3. Platform user grants provider access to the merchant when the business allows it.
4. Platform user creates or confirms merchant users and roles.
5. Platform user creates payment method inside a brand.
6. Platform user configures first-level routing for the payment method.
7. Platform user creates or selects MASTER MID GROUP.
8. Platform user creates MASTER MID inside the payment method context.
9. Platform user configures processing fee on MASTER MID when needed.
10. Platform user configures second-level routing inside MASTER MID.
11. Platform user creates SUB MID GROUP.
12. Platform user connects SUB MID or SUB MID AGGREGATOR.
13. Platform user configures velocity limits and conversion fee where needed.
14. Platform user publishes routing configuration.
15. Platform or merchant user creates a test deposit through Back Office.
16. Team verifies Hosted Payment Page, routing, provider execution, callback, webhook, and timeline.
17. Merchant starts sending production traffic for the selected payment method.

3. What Must Be Easy in Back Office

Back Office should make it easy to:

• see what is missing before a merchant can go live;
• understand which brand owns each payment method;
• see whether routing has a published version;
• distinguish active configuration from draft configuration;
• see whether provider details are hidden or visible;
• open audit history for important entities;
• create a test deposit without using external tools.

4. Required Readiness Signals

Before a payment method can accept production traffic, the product should clearly show:

• merchant is active;
• brand is active;
• payment method is active;
• routing has published version;
• required MASTER MID GROUP exists;
• MASTER MID exists;
• second-level routing exists;
• at least one execution option is available;
• required secrets are configured;
• webhook URL is provided at transaction creation;
• provider-sensitive data is hidden from merchant users without access.

5. What Should Not Happen

The product should prevent:

• creating production traffic for inactive merchant, brand, or payment method;
• publishing routing with no valid target;
• exposing provider details to merchant users without provider access;
• showing saved secret values;
• allowing two users to edit the same draft at the same time;
• losing previous configuration versions.

6. MVP Success for This Flow

The flow is successful when a platform user can prepare the first merchant and payment method for production without developer assistance.