Merchant Tiers and Permission Control in Payment Systems: A Bangladesh Design Guide

As a payment operation grows, merchant management becomes more than maintaining business profiles. Different merchants need different workflows, staff members require different access, and agents may need visibility across assigned businesses. Without clear boundaries, a routine support task can expose financial data or allow an unauthorized transaction change.

For businesses operating in Bangladesh, effective permission control starts with an explicit operating model: who manages each merchant, which customer-owned channels are available, who may initiate or approve financial actions, and what information each user can see. These rules should work consistently across dashboards, APIs, reports, and background processes.

This guide explains how to design those boundaries. The controls described are recommended design and evaluation criteria, not a claim that every configuration is available out of the box. Specific requirements should be confirmed during software and integration assessment.

1. Separate Merchant Tiers from Access Authority

A merchant tier and a permission role answer different questions. A tier describes how a merchant is managed commercially or operationally. A role describes what a person or software identity may do. Treating them as the same thing creates unnecessary risk.

Merchant tiers describe service and workflow needs

Useful classification dimensions include business structure, expected workflow complexity, integration requirements, and internal review status. A single-location merchant may need a simple dashboard, while a business with several branches may need consolidated reporting and branch-specific access.

A higher service tier should not automatically bypass approvals, receive access to other merchants, or gain unrestricted payout authority. Any difference in financial controls needs its own documented rationale.

Keep risk status and lifecycle status separate

A merchant can belong to one service tier while having a different risk or operational status. Maintain separate fields for classification, review status, and lifecycle state. For example, a merchant awaiting an integration review should not be confused with one that has been commercially downgraded.

This separation makes policy changes easier. Teams can restrict a particular action without rebuilding the merchant hierarchy or unintentionally changing reporting access.

2. Build a Merchant Hierarchy with Explicit Ownership

Start with a relationship map before defining permissions. A possible structure is tenant, merchant group, merchant, and branch. An agent can be associated with assigned merchants without becoming the owner of their financial records.

• Tenant: The organizational boundary within which a business operates its software environment.
• Merchant group: An optional parent used for consolidated administration or reporting.
• Merchant: The business entity to which orders, configurations, and transaction records belong.
• Branch: An operational subdivision with restricted visibility where needed.
• Agent: A relationship-based role with access limited to explicitly assigned merchants.

Not every deployment needs all five levels. Unnecessary hierarchy increases administration and makes access harder to explain. Use the simplest model that reflects actual responsibilities.

Define ownership at the record level

Orders, channel mappings, API credentials, reconciliation records, and exports should carry the identifiers needed to establish their ownership. Access decisions should use those identifiers, not rely on a merchant selection in the browser.

Document what happens when a merchant changes groups or agents. Historical visibility should follow an explicit policy rather than automatically transferring with the new relationship.

3. Combine Roles, Data Scope, and Action Conditions

Role-based access control provides a practical starting point, but a role alone is rarely enough. A sound authorization decision checks the requested action, the resource owner, the user's permitted scope, and any additional conditions.

A finance user might be allowed to export reconciliation data for assigned merchants but not change payout destinations. A support user might search orders while seeing only masked customer information.

A practical starting role model

• Platform administrator: Manages platform settings and tenant administration; financial authority should be granted separately.
• Merchant administrator: Maintains the merchant's users and permitted settings within a defined boundary.
• Operations user: Reviews orders, investigates exceptions, and performs approved operational actions.
• Finance user: Reviews reconciliation information and handles authorized financial workflows.
• Read-only reviewer: Views permitted records without changing transactions or configuration.
• Integration identity: Calls approved API endpoints for a specific merchant or service purpose.

Avoid a single permission called “manage payments.” Separate view, create, edit, approve, cancel, export, and configure actions. Likewise, permission to invite a user should not include permission to grant that user unrestricted authority.

Apply conditions to sensitive actions

Additional controls may include fresh authentication, a second approver, or a restriction based on merchant status. Require users to stay within their own delegation authority when assigning roles. For high-impact privileges, consider independent approval rather than immediate self-service assignment.

4. Design Permissions Around Payment Workflows

Permissions become easier to review when they correspond to real workflows. For each workflow, identify the initiating action, any approval step, the external interaction, and the final record.

Collection orders and automatic matching

Separate permission to create collection orders from permission to configure matching rules or resolve unmatched records. Viewing an order should not imply the ability to mark it as paid.

If manual exception handling is required, preserve the original channel evidence, record the operator's reason, and distinguish an internal correction from externally confirmed payment status. Automatic matching should follow documented rules, with uncertain cases routed for review rather than silently treated as confirmed.

Payout initiation and approval

Separate payout preparation, destination maintenance, approval, and submission to the customer's configured channel. A maker-checker model means one authorized user prepares an instruction and another independently approves it.

Define whether a material change invalidates an earlier approval. Changing the destination or amount should trigger a fresh decision under the agreed policy. An internal approval is not proof that the external payment has completed; transaction status must reflect the available channel response and subsequent verification.

Channel configuration and reconciliation

Channel routing and credential changes can affect many transactions, so they deserve stronger controls than ordinary order lookup. Restrict who can change merchant-to-channel mappings, and record configuration revisions.

For reconciliation, distinguish viewing differences, annotating exceptions, approving adjustments, and exporting results. Never solve a discrepancy by silently replacing the original transaction history.

5. Enforce Permissions Beyond the Dashboard

Hiding a button improves usability but does not enforce security. Authorization must be checked by the server whenever a user or integration requests a protected action.

Protect API and transaction boundaries

Each API identity should have a defined owner, purpose, scope, and revocation process. Avoid sharing one unrestricted credential across unrelated merchants. The server should verify that requested orders and merchants belong to the authenticated identity's permitted scope.

For transaction creation and payout submission, evaluate idempotency handling so retries do not unintentionally create duplicate instructions. Incoming status notifications also need authentication and ownership validation using the mechanisms supported by the customer's channel interface.

Apply the same rules to exports and background jobs

Reports, scheduled tasks, notifications, and downloadable files can leak data even when the dashboard is correctly restricted. Apply tenant and merchant filters consistently. For queued exports, define how permission changes affect a pending job and subsequent file access.

Mask sensitive fields where full details are unnecessary. Transaction inquiry permissions should not automatically reveal credentials, full destination details, or unrestricted bulk downloads.

6. Manage Merchant and User Lifecycles Explicitly

Merchant onboarding should establish business ownership, internal review responsibilities, user roles, and customer-provided channel configuration. Activation should follow a checklist rather than a single uncontrolled status switch.

Use clearly defined states such as draft, under review, active, restricted, and closed. For each state, specify which actions remain available. “Restricted” is too vague unless teams know whether it blocks new collections, payout submissions, configuration changes, or only selected activities.

• When users join: Assign only the access needed for their responsibilities.
• When responsibilities change: Remove obsolete permissions instead of merely adding new ones.
• When users leave: Revoke access and invalidate relevant sessions or credentials.
• When merchants close: Define how pending items, reporting access, and record retention will be handled.

Schedule access reviews at an interval appropriate to the operation, and repeat them after significant organizational changes. Review inactive users, powerful roles, agent assignments, and unused integration credentials.

7. Make Sensitive Actions Traceable

An audit record should explain who acted, under which identity and scope, what changed, when it happened, and whether an approval was involved. Capture before-and-after values for important settings without copying secrets into logs.

Prioritize role changes, merchant status changes, channel configuration, manual order intervention, payout approvals, reconciliation adjustments, and data exports. Where useful, link related events through a request or correlation identifier.

Restrict access to audit records and protect them from unauthorized modification. Agree on retention, retrieval, and review procedures. Retention periods and data-handling requirements should be verified for the customer's business model rather than assumed from a generic software template.

8. Evaluate Deployment and Bangladesh Operating Requirements

Independent deployment or multi-tenant deployment

An independent deployment may suit organizations seeking a dedicated environment and greater operational separation. It still requires internal roles, credential protection, maintenance responsibilities, and recovery planning.

A multi-tenant deployment can support several organizational boundaries in a shared application architecture. Its design must enforce isolation across database queries, caches, files, reports, background workers, and administrative tools. A tenant selector alone is not isolation.

Choose based on required control, integration complexity, operating resources, and data governance needs. Neither deployment model automatically provides regulatory compliance or eliminates security risk.

Localize operational details carefully

For Bangladesh operations, specify how BDT amounts, decimal precision, Asia/Dhaka timestamps, business-day boundaries, and reconciliation cutoffs are represented. Distinguish an internal reporting cutoff from an external provider's processing or settlement schedule.

Also confirm staff language needs and the identifiers required by each customer-provided interface. Do not assume different banks, wallets, or payment providers use interchangeable workflows.

Customers should ask qualified local legal, compliance, and payment professionals to verify obligations for their specific business model, including any relevant Bangladesh Bank requirements. Software deployment does not itself confer permission to operate a regulated payment activity.

9. Turn the Design into an Acceptance Checklist

Before implementation, create a permission matrix listing roles against actions and data scopes. Add approval requirements, lifecycle restrictions, and expected audit events. Use it as a shared specification for operations, finance, engineering, and security.

1. Map workflows: Identify owners and handoffs for collections, payouts, exceptions, and reconciliation.
2. Define boundaries: Document tenant, merchant, branch, and agent relationships.
3. Test denied actions: Attempt cross-merchant queries, unauthorized exports, and privilege escalation.
4. Test changes in access: Check revocation, reassignment, pending approvals, and queued jobs.
5. Verify evidence: Confirm sensitive actions generate useful audit records without exposing secrets.

Use test data and non-production environments for these checks. Successful normal transactions are not enough: acceptance testing must also demonstrate that forbidden actions fail safely.

How BD Payment Fits into the Design Process

BD Payment provides payment system software rental, deployment, and technical/API integration. Functional areas can include orders, merchant management, collection and payout workflows, multi-channel management, automatic order matching, financial reconciliation, risk management, agents, reports, permissions, and transaction queries.

Independent or multi-tenant deployment and standard or custom API integration can be evaluated against the customer's requirements. Detailed controls such as approval rules, field masking, audit protection, and credential scope should be confirmed during assessment rather than assumed from a general feature list.

Customers use their own payment channels. BD Payment does not provide bank accounts, electronic wallet accounts, payment channels, licenses, or regulatory authorization. Integration feasibility depends on the customer's available interfaces, access rights, documentation, and technical testing.

Conclusion

Effective merchant management separates business classification from access authority. Define ownership clearly, grant narrowly scoped permissions, protect sensitive workflows with independent checks, and enforce the same rules across dashboards and APIs. For Bangladesh businesses, pair that technical design with verified customer-owned channel access and locally informed compliance review.

Frequently Asked Questions

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

A merchant tier classifies service or operational needs. A user role defines permitted actions. Keeping them separate prevents a commercial upgrade from unintentionally granting financial authority or wider data access.

2. Can agents manage multiple merchants without seeing everything?

Yes, a scoped access model can associate agents with specific merchants and selected actions. Reporting, transaction visibility, configuration rights, and historical access should each be defined rather than inherited without restriction.

3. Is role-based access control enough for a payment system?

Usually it needs additional context. Authorization should also check tenant and merchant ownership, lifecycle status, approval requirements, and delegation boundaries. The server must enforce these checks for API requests as well as dashboard actions.

4. Does independent deployment remove the need for permissions?

No. A dedicated environment still contains users with different responsibilities. Least-privilege access, separation of duties, audit records, and credential management remain necessary even when only one organization uses the deployment.

5. Does BD Payment supply the channels used for collections and payouts?

No. Customers provide their own payment channels. BD Payment supplies software rental, deployment, and technical/API integration services; it does not supply bank or wallet accounts, channels, licenses, or regulatory authorization.