Can multiple employees use one virtual terminal?

Multiple employees can use the same business's virtual terminal when the selected service supports separate user accounts or profiles for that workflow. The business should give each authorized employee an individual sign-in and only the permissions needed for the person's job. Exact user limits, roles, and available controls vary by provider and account configuration, so they must be confirmed before staff begin processing live payments.

A shared virtual terminal does not need to mean shared credentials. Separate accounts make it easier to remove access when responsibilities change, investigate activity, and keep administrative functions away from employees who only need to enter an authorized payment.

Use individual accounts when the service supports them

Start by checking the virtual terminal's current account-management documentation. Look for team members, users, roles, permissions, or staff access. A product may allow several people to enter payments while reserving user management, account settings, reports, refunds, or other sensitive actions for narrower roles. Do not assume that a feature shown in one provider's documentation exists in another service.

Authorize.net's current Merchant Interface documentation provides a useful example: access is assigned through user accounts and predefined roles, with different functions available to an account owner, administrator, transaction manager, analyst, or contact. This example confirms that role-based multi-user payment administration is a real design pattern; it does not establish support for every virtual terminal or imply a relationship between Payments Max and Authorize.net.

For a broader introduction to the payment channel, read what a virtual terminal is and how a virtual terminal works.

Match access to each employee's responsibilities

Payment-entry staff

Employees who take authorized phone or mail-order payments may need transaction-entry access without the ability to change account settings, manage other users, or view unrelated business information.

Supervisors

A supervisor may need to review transaction activity or handle defined exceptions. Any added permissions should reflect a documented responsibility rather than convenience.

Reporting staff

Bookkeeping or reconciliation staff may only need reporting access. If the service offers a view-only or analyst role, compare it with the exact reports that employee uses.

Account administrators

User invitations, permission changes, security settings, and other administrative functions should be limited to designated people and reviewed periodically.

The PCI Security Standards Council's small-merchant guidance recommends limiting payment-system access to business need and making user IDs unique for each person whenever possible. That supports a practical operating principle: grant the smallest useful role, test it with non-sensitive examples, and expand it only when a real job function requires more.

A practical setup sequence

List the work each person performs. Separate payment entry, transaction lookup, reporting, exception handling, user administration, and account configuration.
Confirm supported user controls. Ask the provider to document whether the account supports individual users, available roles, permission details, user limits, activity history, and multifactor authentication.
Create named accounts. Give each authorized employee a separate identity when available. Do not reuse a departed employee's account for a replacement.
Assign the narrowest workable role. Keep administrative and other high-impact functions away from routine payment-entry accounts unless the employee's duties require them.
Test before live use. Verify that each role can complete its approved tasks and cannot reach functions outside the intended workflow.
Document support and escalation. Tell staff how to report a login problem, unexpected permission, suspicious activity, or payment-entry error without exchanging credentials.

If separate users are not available, ask the provider for an approved alternative before adding employees. Do not work around a limitation by sharing a password, saving credentials in a browser used by multiple people, or sending credentials through chat or email.

Protect every employee sign-in

Require multifactor authentication wherever the service offers it, beginning with administrators and people who handle sensitive business data. CISA explains that MFA adds another verification factor and helps protect business accounts when a password is compromised. The precise MFA options depend on the service, so use the strongest supported method that the organization can operate reliably.

Keep credentials personal: employees should not share passwords, recovery codes, security keys, or one-time codes.
Use approved devices and networks: define where staff may access the virtual terminal and how shared workstations are secured between users.
End unattended sessions: use the provider's timeout controls when available and require staff to sign out before leaving a workstation.
Review account recovery: make sure recovery email addresses, phone numbers, and administrator contacts remain controlled by the business.
Remove access promptly: disable accounts when an employee leaves or no longer performs the covered work.

These controls are general operational safeguards, not a certification or a substitute for the provider's current security instructions. The business should follow the requirements that apply to its actual payment environment.

Review activity and access over time

Multi-user access needs maintenance after setup. Establish a regular review that compares the active user list with current staff responsibilities. Remove unused accounts, correct excessive permissions, confirm administrator ownership, and investigate activity the business cannot connect to an authorized employee or workflow.

When the service provides user-level activity history, retain and review it according to the business's documented record process. A unique sign-in can make activity easier to attribute, but logs should not be treated as proof that every action was authorized. Supervisors still need clear procedures for resolving exceptions and reporting suspected account compromise to the provider.

The Virtual Terminals, Invoicing & Payment Links FAQ hub connects this access question with related remote-payment workflows. Merchants that are deciding who should use the channel can also review who should use a virtual terminal.

Questions to ask a provider

Can the account create a distinct user for every employee who needs access?
Which roles can enter payments, view transaction details, access reports, or manage account settings?
Can permissions be customized, and are any important permissions bundled together?
Does the service record the user associated with each action?
Which multifactor authentication and session controls are available?
How are users disabled, and what happens to their historical activity?
Can the business test roles before granting access to a live payment workflow?

Request answers for the exact service and account configuration under consideration. Screenshots or feature names from a different product version are not enough to establish current behavior.

Map employee roles before adding users

Write down who needs to enter payments, review activity, reconcile records, handle exceptions, and administer the account. Then compare that role map with the provider's documented user controls and test each approved account before live use.

Discuss virtual terminal requirements

Share only high-level business and workflow information through a general inquiry. Do not submit cardholder data, passwords, bank credentials, complete account numbers, security codes, recovery codes, or secret API keys.

To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.