04.03 Back Office Page Requirements

Status: draft for discussion

1. Goal

This document briefly describes what business content is needed on the main Back Office pages.

It is not a UI specification or a technical component description.

2. Transactions

The page must allow users to:

• view transactions by available merchants;
• filter transactions;
• open transaction details;
• view timeline;
• view webhook history;
• perform manual correction;
• perform webhook resend;
• export by current filters.

Default table shows the main information. User can enable additional columns themselves.

3. Merchant Details

The page must allow platform user to:

• view and edit merchant;
• edit Legal company name and Merchant name;
• manage brands;
• manage users/access;
• view provider access;
• view audit history.

Legal company name is the official legal company name.

Merchant name is the working name used in Back Office lists, filters, and operational screens.

4. Brands

The page must allow users to create and edit brands inside merchant context.

Brand is used when creating a deposit.

Payment methods are created and displayed inside brand context.

5. Payment Methods

The page shows payment methods by available brands inside available merchants.

User can create a payment method inside a brand, open details, and configure first-level routing blueprint.

6. MASTER MID

The page shows MASTER MID in the context of payment methods inside brands available to the user.

User can open MASTER MID details, configure processing fee, and configure second-level routing blueprint.

7. SUB MID

The page shows merchant-level provider configurations.

Provider details are hidden from merchant users without business access.

Secret values are not shown after saving.

8. SUB MID Aggregators

Platform page for reusable provider configurations.

Merchant users do not manage SUB MID Aggregators directly.

9. API Keys

The page allows merchant to create API key, see active key, and rotate the key with grace period.

Secret is shown only on creation.

10. Users and Roles

Pages must allow users to manage users, roles, and access on business level.

The exact access-control model is proposed by the development team.

11. Webhooks

Page or section shows webhook delivery history by transactions.

User must see delivery status, attempts, and response summary if this is available through business access.

12. Audit Logs

Audit Logs must be available on important entities.

User must see who changed what and when, without exposing secret values.