05.02 Access and Roles

Status: draft for discussion

1. Goal

This document describes business expectations for roles, access, and data visibility.

It is not a technical authorization model or permission matrix.

2. Main Principle

Back Office is one product, but users see different data and actions.

This depends on:

• user type;
• role;
• available merchants;
• available merchant groups;
• provider access;
• visibility rules.

3. Platform Users

Platform user acts on behalf of our platform.

They can:

• work with Platform section;
• work in Merchant section;
• create and manage merchants;
• grant provider access;
• manage roles;
• see more internal data if their role allows it.

4. Merchant Users

Merchant user works only in the context available to them.

They can:

• work with merchants or merchant groups they have access to;
• invite other users if their role allows it;
• manage available entities;
• see provider details only if provider access has been granted.

5. Roles

Roles are needed to manage sets of actions.

Expected behavior:

• roles are created and configured by platform user;
• roles can be for platform users or merchant users;
• platform user can assign merchant admin role;
• merchant admin can grant other users only allowed merchant roles;
• merchant admin does not change the permission set inside a role.

6. Merchant Access

Merchant access defines which merchant data a user can see.

Expected behavior:

• user can have access to one or several merchants;
• user can have a different role in each merchant context;
• if user has no access to merchant, they do not see its data.

7. Merchant Group Access

Merchant group access is needed to give access to several merchants at once.

Expected behavior:

• platform user can give user access to merchant group;
• role in merchant group context defines what user can do;
• group access does not expose internal provider data without separate provider access.

8. Provider Access

Provider access is business permission for a merchant to work with a specific provider.

Expected behavior:

• platform user grants provider access on merchant level;
• access is granted to a specific provider, not to all providers at once;
• after provider access is granted, merchant users with the required role can see more information and create their own provider configurations;
• without provider access, provider remains a blackbox.

9. Visibility Rules

Expected behavior:

• platform users can see real provider names if their role allows it;
• merchant users do not see real provider names without provider access;
• provider configurations created by the platform hide internal data from merchant users;
• provider configurations created by merchant user can be visible in that merchant context;
• secret values are not shown after saving.

10. What the Development Team Decides

The development team proposes:

• technical roles and permissions model;
• permission naming;
• authorization checks;
• audit behavior;
• UX constraints for unavailable actions.