[{"data":1,"prerenderedAt":61},["ShallowReactive",2],{"watch-pos-permissions-refunds-without-shared-manager-pin":3},{"id":4,"title":5,"author":6,"blogbody":7,"body":8,"category":15,"ctaLabel":16,"ctaUrl":17,"date":18,"description":19,"extension":20,"featured":21,"image":22,"lastReviewed":18,"meta":23,"navigation":24,"outboundlinks":25,"path":26,"reviewStatus":27,"seo":28,"seoTitle":29,"sources":30,"stem":46,"tags":47,"videos":52,"youtubelinks":25,"__hash__":60},"blog\u002Fblog\u002Fpos-permissions-refunds-without-shared-manager-pin.md","Set POS Permissions Without Making Everyone a Manager","Nick DiVito","## Executive summary\n\nThe line is growing. An employee needs to correct a transaction. The register asks for a manager code, and the manager is somewhere else.\n\nSomebody shares the code. The immediate problem disappears. So does part of the answer to a later question: who approved that refund?\n\nThe solution is not to make every small decision wait for the owner. Give employees the permissions their actual jobs require under their own identities, reserve meaningful exceptions for the right approver, and check what the register records. Then retire the shared shortcut.\n\nA point-of-sale system, or POS, combines access to money, customer information, reports, and business settings. Treating its permissions as a one-time setup detail leaves real authority scattered around the shop. This article uses Square and Toast examples, but the operating questions apply to other systems too. Exact features depend on your product, plan, device, and configuration.\n\n## The borrowed code solves the wrong problem\n\nAn employee borrows a manager's personal identification number, or PIN, because the system blocks something they need to do. Sometimes the employee has too little access. Sometimes the business has no available approver. Sometimes the restriction is correct and the workflow around it is broken.\n\nThose are three different problems. Handing over a broad code treats all three as permission to act as the manager.\n\nAsk the team which task triggers the borrowing most often. Do not start with a lecture about password sharing. Start with the transaction that repeatedly stops work.\n\nWatch the normal sequence: the customer request, employee action, prompt, approval, and final record. You may discover that the employee needs one routine permission rather than an owner's full access. Or that the closing shift has no authorized person available for an ordinary exception.\n\nWrite down that specific gap. \"Employees need manager access\" is too broad. \"The closing supervisor needs to approve this defined correction without calling the owner\" gives you a configuration and staffing question you can solve.\n\n## Separate identity, authority, and the open session\n\nThree settings need to agree:\n\n- **Identity:** whose account or code does the system recognize?\n- **Authority:** what may that identity do?\n- **Session:** whose authority remains active on the device right now?\n\nDifferent codes do not solve excessive access if every employee still has the same broad manager role. Restricted roles do not preserve attribution if people enter one shared code. Both can fail when an authorized manager leaves an elevated session open for the next person.\n\n[Square's passcode documentation](https:\u002F\u002Fsquareup.com\u002Fhelp\u002Fus\u002Fen\u002Farticle\u002F8357-require-passcodes-at-point-of-sale) distinguishes shared team codes from personal codes and explains the individual activity-tracking limitation of the shared option. It also documents passcode timeout settings. Inspect both the assigned identity and the device's actual locking behavior.\n\nHave the manager complete an authorized action, return the device to its normal state, and confirm the next employee works under the expected identity. Do this in a vendor-supported demonstration or a carefully controlled, harmless workflow. A dashboard screenshot does not prove what happens at a busy register.\n\n## Design permissions around jobs, not trust labels\n\n\"I trust my employees\" is not a permissions model. You can trust the cashier and still avoid giving that account authority to change other employees' access or export information unrelated to the job.\n\nThe useful question is what the business expects the role to accomplish without interruption.\n\nFor an illustrative shop, the owner might define the following distinctions:\n\n| Task | Intended responsibility | Boundary to verify |\n| --- | --- | --- |\n| Complete an ordinary sale | Counter employee | No access to unrelated administration |\n| Correct a routine order error | Trained employee or shift supervisor | Only the correction types the business approves |\n| Handle an unusual refund | Designated supervisor | Approval and reason remain visible |\n| Change permissions or owner settings | Owner or named administrator | Not bundled into ordinary shift work |\n| Review exceptions | Owner or independent reviewer | Enough reporting access without unnecessary transaction authority |\n\nThis is a discussion template, not a claim that every POS supports every boundary. Your provider may offer a broad permission where you want a narrow one. Document that limitation instead of pretending a written policy becomes a software restriction.\n\nIn [Square's permission-set documentation](https:\u002F\u002Fsquareup.com\u002Fhelp\u002Fus\u002Fen\u002Farticle\u002F5822-employee-permissions), full access carries wider capabilities and authorized-representative implications. Inspect those consequences before granting it to solve one inconvenient prompt. A role named Manager should not substitute for reading the permissions inside it.\n\n## A refund is not one universal action\n\nCorrecting a payment from the current shift, refunding an old transaction, and issuing money without a matching original check can carry different risks and permissions.\n\n[Toast's permissions reference](https:\u002F\u002Fdoc.toasttab.com\u002Fdoc\u002Fplatformguide\u002FadminPermissions.html) distinguishes same-business-day void\u002Frefund permissions from broader payment permissions and an optional unlinked-refund capability. That gives an owner concrete questions to ask rather than a vague request for \"refund access.\"\n\nDecide which situations belong with which role. Consider the original transaction, elapsed time, payment method, required explanation, and who should review the exception. Do not assume your system enforces a dollar threshold simply because your policy contains one.\n\nAsk the provider to show what the employee can actually do and what happens outside the allowed case. If the product cannot express the rule, choose an honest alternative: a narrower workflow, supervisor approval, a focused review, or a different capability when the business justifies its cost.\n\nAvoid the expensive overreaction of replacing the entire platform before checking the configuration you already own. Also avoid the cheap-looking shortcut of giving everyone full access and calling a weekly report equivalent to prevention. Review can detect or explain an action after it occurs; it does not stop that action from moving money.\n\n## Do not confuse the device login with the employee\n\nSome systems use one login to initialize the register application and another method to identify the person using it.\n\n[Toast describes this distinction](https:\u002F\u002Fsupport.toasttab.com\u002Fen\u002Farticle\u002FLog-in-to-a-Toast-Product-or-Device): the application signs in at the device level, then individual employees use their POS access codes. That does not mean each employee needs the owner's web-account password.\n\nAsk your provider to map the actual credentials in your setup. Which one starts the device? Which one identifies the employee? Which one approves an exception? Which one changes bank or administrative settings? Keep the answers separate in your access record.\n\nProtect the owner's web account and recovery methods, not just the code on the sales floor. Assign a named administrative backup where appropriate, with its own access and a defined reason, instead of leaving the company dependent on one person's memory or phone.\n\nA workable system gives the shift what it needs without handing the whole company account to everyone who uses a register.\n\n## Test the policy before the next busy shift\n\nConfiguration changes need two kinds of proof: routine work still succeeds, and the intended restriction actually stops or routes the exception.\n\nAsk the vendor or authorized administrator for a supported test method. Do not invent refunds, charge a customer's card, alter real accounting records, or assume a setting called Test has no financial effect. Confirm the environment and consequences first.\n\nWalk through a short acceptance record:\n\n1. A normal employee completes the permitted task using their own identity.\n2. That employee attempts a restricted task through the approved test method and receives the expected denial or approval prompt.\n3. The designated supervisor approves the exception without disclosing their code.\n4. The device returns to the intended employee context afterward.\n5. The report shows the transaction, time, location, reason, and identities the system actually records.\n\nCheck whether the report identifies the initiator, the approver, or only one of them. Do not assume a column labeled Employee means \"person who approved the refund.\" Record the product's meaning and limitations.\n\nInclude the real device types and locations staff use. A web dashboard, handheld, and countertop register may expose different actions. Keep the evidence modest: date, role tested, expected result, observed result, reviewer, and unresolved limitation. You do not need customer data in a training screenshot.\n\n## Read the report as evidence, not a verdict\n\nA transaction associated with an account tells you something about the account or session used. It does not, on its own, prove which human performed the action or whether the action was improper.\n\nShared codes, open sessions, honest corrections, and incomplete explanations all affect interpretation. Accusing an employee from a single report can turn a configuration problem into a personnel problem.\n\nStart with the transaction and its business reason. Compare the original sale, refund details, shift context, approval process, and available records. Keep access to that investigation limited to the people responsible for it. Follow your employment and legal processes before drawing conclusions about misconduct.\n\n[Toast's refund instructions](https:\u002F\u002Fdoc.toasttab.com\u002Fdoc\u002Fplatformguide\u002FadminIssuingARefund.html) describe comments that appear in the refund report. Where your product supports a reason field, define useful explanations. \"Customer returned unopened item; supervisor approved exception\" is more informative than \"refund\" or a blank box.\n\nSet a realistic review responsibility. Name who checks unusual refunds, voids, discounts, or access changes, which report they use, and how they resolve an unexplained entry. A report that nobody opens gives the business very little operational value.\n\n## Retire the shortcut after the replacement works\n\nChanging the manager code before fixing the workflow can strand staff and recreate the same sharing habit with a new code.\n\nFirst confirm that routine tasks work under personal access and that a supervisor can handle exceptions on every shift. Show employees the new process and where to get help when it fails. Then change compromised or widely shared codes through the approved administration process and stop using them as a common credential.\n\nInclude departures and job changes. Remove or adjust the person's access in the actual system, address active sessions where supported, and change shared secrets they knew when those secrets still grant access. Do not assume deleting a scheduling entry also removes every register, reporting, and web-account permission.\n\nReview any role that temporarily gained extra authority for an absence or special event. Assign an end condition at the time of the change. Otherwise temporary access has a way of becoming the permanent setup nobody remembers approving.\n\n## Spend on the missing capability, not the warning label\n\nA paid plan may offer permission detail, reporting, or administration your current plan lacks. Its value depends on whether the business will use that capability and whether it closes the specific gap you found.\n\nAsk for a demonstration of your exact case before upgrading: \"Show the closing supervisor correcting this transaction, the cashier remaining restricted, and the owner finding the resulting record.\"\n\nThen compare the recurring cost with the practical burden you are removing: interrupted shifts, owner calls, unexplained adjustments, or hours reconstructing who did what. Do not invent a guaranteed fraud-savings number. Better attribution and fewer unnecessary interruptions are worthwhile results without a dramatic loss claim.\n\nThis is access control in ordinary business language. You define the job, give it the appropriate authority, preserve a useful record, and remove access when the reason ends. The same reasoning extends to bookkeeping, cloud files, and vendor accounts.\n\nContinue with the [Business Security Checklist](\u002Ftools\u002Fbusiness-security-checklist), or [book a conversation with Trawvid Sec](https:\u002F\u002Fcalendar.app.google\u002FqT8vtwaEDG2Pt51o8) to examine the permissions and provider dependencies behind daily operations. We address the points where staff need a workaround so the business keeps moving without handing out authority nobody intended.",{"type":9,"value":10,"toc":11},"minimark",[],{"title":12,"searchDepth":13,"depth":13,"links":14},"",2,[],"Security Program","Review the access behind daily operations","https:\u002F\u002Fcalendar.app.google\u002FqT8vtwaEDG2Pt51o8","2026-10-20","Keep refunds and discounts moving without sharing the manager PIN. Match register permissions to real jobs and retain records you can actually investigate.","md",false,"\u002Fimg\u002Fblog\u002Fblog-controls.jpg",{},true,null,"\u002Fblog\u002Fpos-permissions-refunds-without-shared-manager-pin","Current",{"title":5,"description":19},"POS Permissions: Stop Sharing the Manager PIN",[31,34,37,40,43],{"label":32,"url":33},"Square permission sets and full-access implications","https:\u002F\u002Fsquareup.com\u002Fhelp\u002Fus\u002Fen\u002Farticle\u002F5822-employee-permissions",{"label":35,"url":36},"Square personal passcodes and timeout settings","https:\u002F\u002Fsquareup.com\u002Fhelp\u002Fus\u002Fen\u002Farticle\u002F8357-require-passcodes-at-point-of-sale",{"label":38,"url":39},"Toast access permissions reference","https:\u002F\u002Fdoc.toasttab.com\u002Fdoc\u002Fplatformguide\u002FadminPermissions.html",{"label":41,"url":42},"Toast device login and employee access codes","https:\u002F\u002Fsupport.toasttab.com\u002Fen\u002Farticle\u002FLog-in-to-a-Toast-Product-or-Device",{"label":44,"url":45},"Toast refund workflow and report comments","https:\u002F\u002Fdoc.toasttab.com\u002Fdoc\u002Fplatformguide\u002FadminIssuingARefund.html","blog\u002Fpos-permissions-refunds-without-shared-manager-pin",[48,49,50,51],"Access control","Point of sale","Small business","Refund approvals",[53],{"title":54,"url":55,"description":56,"uploadDate":57,"duration":58,"thumbnailUrl":59,"watchPage":24},"How to Set POS Permissions Without Slowing Down Your Staff","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=AYDyoY2GJKI","Nick DiVito uses Square and Toast examples to explain personal access, role permissions, manager approvals, and the records behind refunds without slowing routine work.","2026-09-22T10:00:38-05:00","PT9M9S","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FAYDyoY2GJKI\u002Fhqdefault.jpg","eQ3VveFeyx1dB2jaPK075NidAy3cqPMlbYSEIt3Yupk",1792533899371]