Merchant Tiering and Access Control Design for Payment Systems in Bangladesh

A payment system becomes harder to manage as more merchants, branches, agents, and staff members join it. The challenge is not simply creating accounts. It is deciding which business each account belongs to, which transactions it can see, and which actions it can perform without exposing another merchant’s data or weakening financial controls.

For businesses operating in Bangladesh, effective merchant management should connect organizational structure, transaction workflows, and access control. A merchant administrator may need to manage staff but should not automatically gain authority to change payment configurations. A finance user may need reconciliation reports without permission to initiate payouts.

This guide explains how to design merchant tiers and permissions as a practical software framework. BD Payment provides payment system software rental, deployment, and technical/API integration services. Customers use their own payment channels. The design patterns below are implementation recommendations; specific controls should be confirmed during requirements assessment.

1. Separate Merchant Hierarchy, Service Tiers, and Risk Status

A common design mistake is using one merchant level to represent everything: organizational position, commercial package, transaction access, and risk. These concepts should remain separate so that changing one does not silently change the others.

Merchant hierarchy: who belongs to whom?

The hierarchy defines ownership and reporting relationships. Depending on the business model, it might include a platform operator, an agent organization, a merchant business, and merchant branches. Not every deployment needs every layer.

A parent-child relationship should not automatically grant unrestricted transaction access. An agent responsible for merchant onboarding, for example, may need application status and assigned merchant records without seeing sensitive transaction details.

Service tier: which software features are available?

A service tier can determine access to reporting, API functionality, branch administration, or particular workflows. It is a feature entitlement, not a security role.

Even when a merchant’s package includes payout workflows, individual users should receive payout permissions only when their responsibilities require them. Feature availability and user authorization must both be satisfied.

Risk status: which restrictions currently apply?

Risk status should independently influence actions such as transaction submission or configuration changes. An account under review might retain access to historical records while new payout requests are paused.

Document the actions affected by each status. Avoid ambiguous labels such as “restricted” unless staff can see exactly what the restriction means and who may change it.

2. Build a Permission Model Around Roles, Scope, and Context

Role-based access control is a useful starting point, but a role name alone is insufficient. “Finance manager” does not explain whether someone can access one branch, an entire merchant business, or multiple tenant organizations.

A practical authorization decision should evaluate:

• Identity: Which human user or API client is making the request?
• Role: Which actions have been assigned to that identity?
• Scope: Which tenant, merchant, branch, or assigned records are accessible?
• Context: Does the merchant status or approval state permit the action?

Enforce these checks on the server for every relevant request. Hiding a dashboard button is not access control: a user might still call the underlying endpoint or attempt to open another merchant’s transaction directly.

Recommended role patterns

• Platform administrator: Manages platform configuration and authorized tenant administration, with sensitive production access tightly controlled.
• Merchant administrator: Manages users within the merchant’s permitted scope but cannot grant permissions beyond an approved ceiling.
• Operations user: Monitors orders, investigates exceptions, and performs specifically authorized workflow actions.
• Finance preparer: Reviews reconciliation information and prepares permitted financial requests.
• Finance approver: Reviews requests independently and approves only within assigned authority.
• Read-only reviewer: Views defined records and reports without modification rights.
• API client: Performs narrowly defined machine-to-machine actions for a specific merchant and purpose.

These are templates, not mandatory job titles. Smaller teams may combine routine responsibilities, but sensitive actions should preserve independent review wherever feasible.

3. Define Permissions by Action, Not Just by Module

A permission called “order access” is too broad. It may unintentionally combine viewing, exporting, changing transaction associations, and retrying requests. Break each module into meaningful actions.

Orders and transaction queries

Separate permission to search transactions from permission to view sensitive fields, export results, request a retry, or modify an internal association. A support user may need order status and references without access to full customer or beneficiary details.

Apply the same scope restrictions to search results, downloadable reports, and individual record pages. Otherwise, a carefully restricted dashboard can still leak information through exports.

Collection and payout workflows

For collection workflows, distinguish order creation, status review, exception handling, and authorized corrections. For payouts, separate request creation, approval, submission to a customer-configured channel, and status investigation.

Permission to approve a payout should not also allow someone to rewrite its beneficiary details. Material changes after approval should invalidate that approval and require review again.

Channel configuration

Multi-channel management concerns the customer’s own payment channels. Configuration access should be separate from transaction operations because credential, routing, or callback changes can affect many orders at once.

Users who can monitor channel health do not necessarily need access to credentials. Store secrets securely, mask them in interfaces, and define a controlled process for replacement or rotation.

4. Use Approval Workflows for High-Impact Changes

Not every action needs a second approver. Requiring approval for ordinary searches would slow operations without improving security. Reserve stronger controls for actions with significant financial, security, or data-exposure consequences.

Candidate actions include:

• Granting an administrator or payout-approval role.
• Changing a payout destination or sensitive merchant configuration.
• Updating production channel credentials or routing rules.
• Overriding an automatic order match.
• Exporting sensitive data beyond routine reporting needs.
• Changing transaction restrictions or releasing a held workflow.

Use a maker-checker pattern: one authorized person proposes the change, and another reviews it. Approval should bind to the exact request version rather than a changeable record.

For example, a finance preparer creates a payout request. An approver reviews the destination, amount, and supporting reference. If the preparer changes the destination afterward, the earlier approval no longer applies. Before submission, the system checks the approved version and the merchant’s current permissions again.

Requests also need clear pending, approved, rejected, expired, and cancelled states. Emergency access should be time-limited, justified, logged, and reviewed rather than implemented as an untracked administrator bypass.

5. Protect Tenant Boundaries in Every Data Path

Independent deployment and multi-tenant deployment have different operational trade-offs. Neither removes the need for careful authorization. An independent deployment can still contain multiple merchants, while a multi-tenant environment needs dependable isolation between tenant organizations.

In a multi-tenant design, tenant scope should come from trusted authentication and server-side authorization context. Do not trust a merchant or tenant identifier supplied in a request as proof of access.

Test more than the transaction screen

Isolation must extend to background jobs, report generation, caches, file downloads, webhook routing, and transaction searches. A report may be generated correctly but become exposed if its download link lacks access checks.

Parent-level reporting also requires an explicit rule. Specify which child merchants are included, whether transaction-level details are visible, and how access changes when a merchant is reassigned to another agent.

BD Payment supports assessment of independent or multi-tenant deployment. Selection should consider isolation requirements, operating responsibilities, maintenance capacity, and customization needs rather than treating either model as universally superior.

6. Treat API Clients as Restricted Operational Identities

API integration should follow the same permission principles as dashboard access. A merchant’s order-creation application should not inherit the authority of its human administrator.

For standard or customized API integration, define:

• The merchant and environment associated with each credential.
• The endpoints and actions the client may use.
• The records it may query and fields it may receive.
• How credentials are issued, rotated, and revoked.
• How requests, responses, and callbacks are authenticated.
• How duplicate requests and uncertain responses are handled.

Use idempotent request handling for supported transaction operations so that a retry does not create an unintended duplicate. Scope idempotency records to the correct merchant and operation. A unique request key is not a substitute for authorization.

Confirm callback verification and status-mapping requirements against the customer’s channel documentation. An API timeout should not automatically be treated as a failed payment or trigger an uncontrolled resubmission.

7. Connect Automatic Matching, Reconciliation, and Audit Trails

Automatic order matching can reduce manual work, but exceptions need controlled handling. Matching logic should use reliable references and defined criteria. Ambiguous records should enter an exception queue rather than being treated as confirmed matches without sufficient evidence.

A user authorized to investigate a mismatch should not automatically be allowed to rewrite its financial outcome. Manual reassignment should preserve the original association, the new association, the reason, and the reviewer where approval is required.

Keep reconciliation separate from money movement

Reconciliation compares records and highlights differences; it does not itself prove that funds have settled. Reports should distinguish internal order status, the status reported by a customer’s channel, and any separately verified settlement information.

A reconciliation analyst may need broad read access while remaining unable to initiate payouts. Likewise, a payout operator should not be able to erase reconciliation exceptions.

Make sensitive actions traceable

Audit records should capture the actor, tenant and merchant scope, action, timestamp, affected record, previous and new values where appropriate, and approval reference. Protect logs from alteration by the users whose actions they record.

Avoid logging credentials or unnecessary personal information. Define retention, access, and deletion rules with the customer’s operational and applicable compliance requirements in mind.

8. Plan for Bangladesh Operations Without Assuming Regulatory Coverage

Localization should support actual operating practices. Where relevant, define BDT amount formatting, Asia/Dhaka display times, report cut-off conventions, and searchable customer-channel references. Store timestamps consistently so that dashboard reports and API records can be compared reliably.

Business and finance teams should agree on what a daily report includes. A transaction created before a reporting cut-off but confirmed afterward may otherwise appear inconsistent across teams.

Software permissions do not establish legal authority to conduct payment activities. Customers should ask qualified local legal, compliance, and financial professionals to verify requirements for their specific business model in Bangladesh.

BD Payment does not provide bank accounts, electronic wallet accounts, payment channels, licences, or regulatory authorization. Its role is payment system software rental, deployment, and technical/API integration. Channel availability, permitted usage, and external processing arrangements must be verified by the customer with the relevant providers.

9. Roll Out Access Control With a Testable Checklist

Start with the most sensitive workflows rather than a long list of role names. Document who owns each action, what data it touches, and what could go wrong if permission is excessive.

1. Map the organization: Identify tenants, merchants, branches, agents, and reporting relationships.
2. List actions: Separate viewing, exporting, creating, approving, configuring, and submitting.
3. Assign scope: Define record ownership and permitted cross-merchant visibility.
4. Set approval rules: Identify changes requiring independent review.
5. Test denied access: Attempt cross-merchant queries, unauthorized exports, self-approval, and direct endpoint access.
6. Test access removal: Confirm that disabled users, revoked API credentials, and stale sessions cannot continue operating.
7. Review periodically: Remove unused roles, expired temporary access, and permissions left behind after staff changes.

Before deployment, confirm which controls are standard configuration, which require customization, and which depend on the customer’s channel interfaces. Include acceptance tests and operating ownership in the implementation scope.

Conclusion

Reliable merchant management separates organizational hierarchy, feature entitlements, risk restrictions, and user permissions. Access control then connects each action to the correct identity, merchant scope, and workflow state.

For a Bangladesh-focused payment system, the goal is controlled operations across orders, customer-owned channels, reconciliation, reporting, and APIs. A useful next step is to prepare a merchant hierarchy, permission matrix, and channel integration requirements for assessment with BD Payment.

Frequently Asked Questions

1. What is the difference between a merchant tier and a user role?

A merchant tier defines software entitlements or operational classification. A user role defines what a particular person may do. Access should require both an available feature and an authorized user action within the correct merchant scope.

2. Should agents see every transaction from their assigned merchants?

Not automatically. Agent visibility should reflect a documented business need. Some agents may need only onboarding status or aggregate reports; transaction-level access should be explicitly granted, scoped, and reviewed.

3. Is independent deployment more secure than multi-tenant deployment?

There is no universal answer. Independent deployment can offer greater environmental separation, while multi-tenant deployment requires robust tenant isolation. Security in either model depends on implementation, configuration, maintenance, and operational access controls.

4. Can dashboard permissions also protect API operations?

The same authorization principles should apply, but API clients need their own credentials and explicit permissions. Do not assume that hiding a dashboard action prevents API access. Both interfaces require server-side enforcement.

5. What does BD Payment provide for this type of project?

BD Payment provides payment system software rental, deployment, and technical/API integration. Relevant functional areas include orders, merchants, collection and payout workflows, multi-channel management, automatic order matching, reconciliation, risk management, agents, reports, permissions, and transaction queries. Independent or multi-tenant deployment and standard or customized API integration can be assessed. Customers supply their own payment channels and must verify their own account, provider, and regulatory arrangements.