Our Virtual Terminal offers a number of benefits to your business, but what good is it if you’re not using it right? During your merchant account setup, our stellar support team does everything in its power to ensure that, when you log in for the first time, the Virtual Terminal is configured to fit your business needs. But like parents seeing their child off to college, we can only hope that our preactivation advice resonates with you and that you'll reach out to us when you’re in need.
We’ve found that many of our customers, despite having customized Virtual Terminals, share only one or two user accounts to access it. Here are four reasons why you should not share your Virtual Terminal credentials and should, instead, provide each employee with his own login:
- PCI Password Requirements - The Payment Card Industry Data Security Standard (PCI DSS) prohibits shared passwords, which is covered in detail under the eighth requirement of the PCI DSS quick guide. Why is it prohibited? According to Search Security, sharing passwords “ … jeopardizes the security of protected systems,” which could result in costly fines for your business. The PCI password requirements “appl[y] to all accounts, including point-of-sale accounts, with administrative capabilities and all accounts with access to stored cardholder data.”
Because PayJunction’s Virtual Terminal tokenizes cardholder data, your business doesn’t have access to stored cardholder data. However, the Virtual Terminal is still an account with administrative capabilities, so you’re subject to the same PCI password requirements to remain compliant.
- Accountability - Shared passwords eliminate accountability. If your employeess are sharing a login and password, then they might as well be using an old-school terminal because in either scenario no one can be held responsible in the case of a questionable refund or a transaction error. Even with the most trustworthy staff, an honest error is nearly impossible to trace with a shared user login, making it difficult to find a solution to or the reason for errors — which, gone unaddressed, could become chronic.
Our Virtual Terminal records all actions in the transaction notes. For example, if a transaction is voided or edited, the user and action are logged for reference. Without individual accounts for every user, you’re not using this feature to its fullest potential.
- Delegation and Limitation - Without individual user credentials, it’s impossible to delegate abilities and restrict access to certain staff. One user account with admin permission gives all your staff access to every function and to all data. Giving all staff members their own accounts allows you, the admin, to delegate control of certain departments or locations to the corresponding employees. This eliminates the risk of staff associating transactions with the wrong department, ultimately skewing batch and deposit reports. Limiting user access also allows you to hide certain data from your staff.
- Practicality - With any password-secured account, if you attempt entry multiple times and continuously fail, you’ll be locked out. This is a defense mechanism to ensure that hackers cannot gain access. If a user is logging into your Virtual Terminal with a shared password but fails after five attempts, every user is locked out and you’re unable to run transactions for 15 minutes until you’re allowed to try again. Similarly, if that one user changes the password to regain access, the rest of the staff have to be made aware of the change.
PayJunction’s Virtual Terminal does not limit the number of users, nor does it cost anything to add new users. Plus, it only takes an instant for a Virtual Terminal administrator to add additional users. Creating individual user accounts for every staff member from the get-go will save your business time and money in the future, and make you compliant with PCI password requirements.
Do you currently allow users to share Virtual Terminal login credentials? Will you require every user to have their own login after reading this? Tell us your thoughts below.