05.03 Provider Visibility and Configuration

Status: draft for discussion

1. Goal

This document describes how the business expects to work with providers and provider configurations.

It is not a description of provider adapters, credential storage, or technical integration.

2. Why This Matters

Real provider names and internal provider data are sensitive business information.

If merchant sees provider names without permission, they can contact provider directly. This is a critical business risk.

3. Provider

Provider is the real payment partner through which a transaction can be executed.

Expected behavior:

• platform users can work with providers;
• merchant users do not see provider names without provider access;
• provider methods are used only where they are supported by the system;
• the list of available providers/methods is clear to users who are allowed to see it.

4. SUB MID

SUB MID is a provider configuration for a specific merchant.

Expected behavior:

• created in merchant context;
• can be created by platform user;
• in the future, can be created by merchant user if merchant has provider access;
• contains credentials and additional settings;
• secret values can be changed but cannot be viewed again after saving.

5. SUB MID AGGREGATOR

SUB MID AGGREGATOR is a reusable platform provider configuration.

Expected behavior:

• created only by platform users;
• can be used between merchants;
• merchant users do not create or connect SUB MID AGGREGATOR themselves;
• merchant users do not see internal provider details of this configuration.

6. Required Customer Attributes

Some providers require additional customer attributes.

Expected behavior:

• merchant sends basic required data when creating a deposit;
• if selected execution option requires additional data, the system collects it on Hosted Payment Page;
• customer sees clear fields;
• merchant and customer do not see field names or errors from provider integration;
• the system uses unified business names for customer attributes.

7. Provider Errors

Expected behavior:

• raw provider errors are not shown to merchant/customer;
• merchant/customer see a clear business error;
• platform users can investigate the internal error reason if their role allows it.

8. What the Development Team Decides

The development team proposes:

• technical integration approach;
• secure secrets storage model;
• provider adapter approach;
• way to hide provider names in external places;
• way to collect provider-required attributes;
• internal error handling for incident investigation.