By Eric Kuvykin. Substantially revised October 17, 2026. The original publication date and URL are retained.
Begin with actions, not job titles
A payment portal’s “manager” role may include permissions that the business does not intend every manager to have. Build the access review around specific actions: view a transaction, issue a refund, export records, change a payout destination or add another user.
Record who needs each action and why. A support employee may need to locate a payment without permission to change bank details. Keep the requested access separate from whatever broad default role the software initially offers.
Demonstrate the approval path
Ask the provider to show how refund permissions and approval limits actually work. Test whether a user can refund only an original transaction or perform other actions as well. Confirm how the system records the person initiating an action and any approving supervisor.
If the product lacks a desired control, document the limitation and the compensating operating process for review. Do not assume a written policy prevents an action that the system still permits without visibility. Assign someone to inspect the relevant activity report.
Include provider and former-employee access
List service accounts, integrations and provider support access alongside employee accounts. Determine how access is granted, monitored and removed. A staff offboarding checklist that closes business email but leaves a payment integration active may miss an important dependency.
For a Florida merchant using temporary staff, set a review date at the end of the staffing period. Verify access removal in each actual system instead of treating a personnel spreadsheet as proof. Keep a record of the check without storing credentials in the personnel file.
Practice an unusual request
Use a tabletop example in which someone requests an urgent refund to a changed destination or asks for a payout-setting update. Staff should know how to pause, verify through a trusted route and obtain the required approval. Knowing a business name or order amount should not automatically establish authority.
The PCI Security Standards Council’s merchant resources help frame questions about people, process and technology. Work with the provider and appropriate specialists on the responsibilities and validation required for the specific environment.
Repeat the review after a software change, role change or incident. A useful permission map makes ordinary service possible while leaving important financial changes attributable and reviewable. The goal is to know who can act, who approves and how the business would discover an unexpected action.
References and related reading
Primary resource checked for this review: PCI Security Standards Council’s merchant resources. Confirm the current requirements and implementation with the responsible provider or appropriate adviser.
Continue with Payment Cybersecurity: Protect Access, Device Changes and Recovery and Chargeback Prevention Starts With the Order Record.
For state and local business resources alongside this operating checklist, use the Florida business operations guide on All State Merchants.
