How to Secure Your Payment Gateway Dashboard: 9 Essential Controls for Merchants

Your payment gateway dashboard can issue refunds, change where settlements go, create API keys and add new users. Anyone who logs in with the wrong level of access can move money or expose customer data without breaking a single technical defence. For most merchants, the bigger risk is not an outside hacker but how employee access is set up and kept up to date.

This guide covers nine controls for payment gateway dashboard security, a permission matrix for finance, support and developer teams, and an onboarding and offboarding checklist. We use Razorpay’s documented team access and two-factor authentication features as worked examples. Documentation was checked in October 2026.

Quick answer: Give every employee their own login, turn on two-factor authentication for the whole team, and assign the narrowest role that fits each job. Keep refunds, API keys, bank details and team management with a few named people, review access every six months, and remove leavers on their last working day. Add session rules and activity checks where your gateway allows them.

Why is a payment gateway dashboard a high-value target?

A gateway dashboard is where payment operations happen. Depending on the role, a user can view transactions and customer details, refund payments, accept or contest disputes, download reports, manage webhooks and API keys, and add team members. Three access problems cause most of the risk. Outside attacks such as credential stuffing and phishing are covered in our guide to account takeover attacks.

Shared passwords

When a team shares one login, nobody can tell who issued a refund or changed a setting. The password spreads to former staff and personal devices, and the shared account usually has full rights because the owner created it. If two-factor authentication is on, the OTP goes to one phone, so staff forward codes to each other and the control stops working.

Too many permissions

Owners often give everyone admin access to save time. A support agent who only needs to look up a payment then also has the power to refund it or read API keys. Every extra permission raises the cost of a mistake, an insider fraud or a stolen login.

Former employees who still have access

Dashboard accounts are easy to miss when someone leaves, because the gateway usually sits outside the company’s main email and IT systems. A former employee, freelancer or agency with a live login can still see data and, depending on the role, move money. Our article on insider threats in payment environments explains why this is hard to detect after the fact.

9 essential controls for payment gateway dashboard security

The controls below apply to any gateway. Product-specific features are covered separately in the Razorpay section that follows.

1. Give every user an individual login

Every person who uses the dashboard should have a personal account tied to their work email. Individual logins make each action traceable to one person and let you remove one user without disrupting anyone else. The PCI DSS 4.0 standard sets the same principle for systems in its scope: requirement 8.2.1 calls for a unique ID for every user, and 8.2.2 allows shared accounts only as an exception. Agencies and freelancers should get their own accounts too, never the owner’s password.

2. Turn on two-factor authentication for everyone

Two-factor authentication (2FA) stops most attacks that rely on a stolen password. Turn it on at team level so no account is left out, and never let staff share OTPs. SMS codes are better than nothing but can be intercepted, as our guide to SIM swap attacks explains, so use an authenticator app or passkeys where your gateway supports them. Decide in advance how a lost phone is handled, so resets go through the account owner. For the compliance side, see our guide to PCI DSS MFA requirements.

3. Apply least privilege

Least privilege means each user gets only the access their job needs. Start each new user on the most limited role that works, and add rights only when a task requires them. PCI DSS requirement 7.2.2 bases access on job function and the least privileges needed. In practice, most staff need to view payments, few need to refund them, and fewer still need API keys or team management.

4. Map job functions to dashboard roles

Most gateways offer fixed roles rather than fully custom permissions. Before you invite anyone, list the job functions in your business (finance, support, developers, dispute handling, auditors) and choose the closest role for each. If no role fits exactly, pick the narrower one and route occasional tasks to someone who already holds the wider role. Keep this mapping in a shared document so new managers follow it.

5. Restrict sensitive actions

Some actions can move money or open new attack paths. Keep them with two or three named people:

• Refunds, especially large or manual ones
• Viewing or regenerating API keys
• Changing settlement bank account details
• Adding, removing or changing the role of team members
• Creating or editing webhooks

Where possible, split duties so the person who requests a high-value refund is not the person who approves it. Refunds are a common route for staff fraud; our guide to refund fraud and policy abuse covers the patterns. API keys need the same care in your code, as our payment API and webhook security guide explains.

6. Review access on a schedule

Roles drift as people change jobs. Review every dashboard user at least every six months, which matches PCI DSS requirement 7.2.4 for in-scope systems, and again after any restructure or change of agency. For each account, confirm the person still works with you, still needs access and holds the right role. Remove accounts unused for 90 days, the limit requirement 8.2.6 sets for inactive accounts, and record who carried out the review and when.

7. Offboard on the last working day

Remove dashboard access on the employee’s last working day, or immediately for an unplanned exit. PCI DSS requirement 8.2.5 says access for terminated users is revoked immediately. Add the payment gateway to your HR exit checklist, since it often sits outside central IT. If the person could see API keys or webhook secrets, rotate them, and check pending invitations and agency accounts at the same time.

8. Keep sessions short and devices clean

A logged-in dashboard on an unattended laptop is an open door. Ask staff to lock their screens, log out on shared machines and avoid using the dashboard from personal or public devices. PCI DSS requirement 8.2.8 asks for re-authentication after 15 minutes of idle time on in-scope systems, and the same habit is worth applying here. A password manager keeps dashboard passwords long and unique.

9. Monitor activity and set alerts

Watch for actions that do not fit normal work: refunds outside business hours, a spike in refunds by one user, unexpected new team members, bank detail changes and API key regeneration. Use whatever audit trail, email alerts or reports your gateway offers, and compare refund reports against support tickets every month. Our guide to PCI DSS Requirement 10 logging and monitoring covers how to turn logs into regular checks.

How does Razorpay handle team access and 2FA?

Razorpay publishes enough detail to show how these controls work on a real dashboard. Based on its Manage Team documentation, API keys documentation and Business Security Checklist:

• Roles: Razorpay lists 15 predefined roles, including Owner, Admin, Manager, Operations, Finance, Finance Manager, Support, View-Only (Auditor), Dispute Manager, Fraud Analyst, Fraud Operations and R&D. Custom roles are not described in its documentation.
• One role per email: each email address can hold one role on an account.
• Team management: the Owner invites members, changes roles and removes users from Account & Settings, under Manage Team. Admins have most Owner rights but cannot manage the team.
• Team-level 2FA: the Owner can turn on 2-step verification for the whole team, confirmed with an OTP and the account password. If a user loses their phone, the Owner can invalidate their 2FA so they set it up again. Nine wrong OTP attempts lock an account, and the Owner can unlock it.
• API keys: only Owner and Admin users can see API keys. Regenerating keys needs OTP verification, the old key can be deactivated immediately or within 24 hours, and the key secret is shown only once.
• Pseudo Owner: an account can have up to two Pseudo Owners with owner-level rights, including settlement bank details. Assigning one needs extra authentication, the Owner receives an email, and Pseudo Owner actions are labelled for audit.
• Checklist: Razorpay advises granting dashboard access only to necessary users, not sharing accounts among employees, enabling 2FA across the team, never sharing OTPs, using a password manager and keeping an onboarding and offboarding checklist.

Two points need planning. Because only Owner and Admin roles can see API keys, giving a developer key access means making them an Admin, which also allows refunds. A safer pattern is for the Owner to generate keys and pass them to production through a secrets vault, while developers use the R&D role, which manages webhooks only. Razorpay’s 2FA also relies on OTPs sent to a mobile number, so protect the Owner’s number against SIM swap by adding a PIN or port lock with your mobile carrier.

Razorpay’s public documentation does not describe dashboard session timeouts or a team activity log that merchants can review, so controls 8 and 9 depend on your own practices and reports. Treat the two Pseudo Owner seats as backup access for the business owner, not everyday logins.

Permission matrix for finance, support and developer teams

Use this matrix as a starting point, then map each column to the closest role on your gateway. “Named only” means one or two named people in that team, not everyone.

For auditors or accountants, use a read-only role such as Razorpay’s View-Only (Auditor), which cannot make changes or export files. Teams that handle many chargebacks can use the Dispute Manager role, which works on disputes without refund rights.

Employee onboarding and offboarding checklist

Keep this checklist with your HR process so dashboard access starts and ends with employment.

Onboarding

• Confirm the job function and the dashboard role it maps to, approved by the account owner
• Invite the person with their work email, never a personal address
• Confirm 2FA is active on their first login
• Record the user, role, approver and date in your access register
• Brief them on OTP sharing, phishing and logging out of shared devices
• Add them to your next six-monthly access review

Offboarding

• Remove the user from the dashboard on their last working day
• Cancel any pending invitations sent to or by them
• Rotate API keys and webhook secrets if they had access to them
• Remove their phone number from any 2FA or recovery settings
• Check refunds, bank detail changes and team changes they made in the last 30 days
• Update the access register with the removal date

Where should a small merchant start?

Start with three controls this week: individual logins, team-wide 2FA and removing anyone who has left. They cost nothing and close the most common gaps. Next, move each user to the narrowest role and limit refunds, API keys, bank details and team changes to named people. Then set a six-monthly review date and a monthly refund check, so the setup stays correct as your team changes.

FAQs

1. Should every team member use 2FA on the payment dashboard?

Yes. A stolen password is the easiest way into a dashboard, and 2FA blocks most of those attempts. Turn it on at team level so no account is left out, and use an authenticator app or passkeys where available, since SMS codes can be intercepted through SIM swapping.

2. Can staff share one dashboard login?

No. A shared login hides who did what, spreads the password to people who later leave, and usually carries full rights. Razorpay’s security checklist tells merchants not to share user accounts or 2FA OTPs among employees. Give each person an individual login with the right role.

3. What dashboard role should a developer get?

The narrowest role that lets them build and test. On Razorpay, the R&D role manages webhooks without access to payments or refunds. API keys are visible only to Owner and Admin users, so have the Owner generate keys and store them in a secrets vault rather than making developers Admins.

4. How often should we review dashboard access?

At least every six months, and after any restructure or change of agency. Check that each user still works with you, still needs access and holds the right role. Remove accounts that have not been used for 90 days and record each review.

5. What should we do when an employee leaves?

Remove their dashboard account on their last working day, cancel pending invitations and remove their phone number from 2FA settings. If they could see API keys or webhook secrets, rotate them. Then check refunds, bank detail changes and team changes they made in the last 30 days.