Shopify POS cash management rebuilt: what developers and merchants need to know about Cash Drawers, Payment Sessions, and POS UI extensions

Table of Contents

1. Key Highlights
2. Introduction
3. What changed: the new building blocks
4. Why the new model matters: merchant needs and technical constraints
5. Cash Drawers: concept, lifecycle, and API operations
6. Payment sessions: the atomic unit for cash reconciliation
7. Reason codes: categorical context for adjustments
8. POS UI extensions: bringing cash operations into the register
9. Common merchant workflows and how they map to the new APIs
10. Integrating cash data with accounting and analytics
11. Migration and compatibility: from CashTrackingSession to Payment Sessions
12. Developer implementation checklist
13. Sample API sequences
14. Operational best practices and policies
15. Testing, QA, and rollout guidance
16. Troubleshooting and common pitfalls
17. Opportunities for app developers and partners
18. Security, compliance, and privacy considerations
19. Looking ahead: advanced automations and integrations
20. FAQ

Key Highlights

• Shopify reengineered cash management for POS with new Admin GraphQL resources: CashDrawer and PointOfSaleDevicePaymentSession, enabling shared drawers, richer reconciliation data, and programmable cash workflows.
• POS UI extensions and a Cash Drawer platform API let developers build custom register experiences and automate cash operations (assign devices, open/close sessions, record adjustments, capture reason codes).
• New primitives simplify multi-device stores, improve auditability with reason codes and financial summaries, and open integration opportunities for accounting, loss prevention, and shift management apps.

Introduction

Shopify has rebuilt cash management on POS, replacing the older cash-tracking model with a modular, API-first system that separates physical cash storage from devices and adds richer session data for reconciliation. The changes deliver two practical advances: a Cash Drawer resource that represents an actual storage unit at a location, and PointOfSaleDevicePaymentSession as the canonical unit of work for a shift or day. App developers gain new Admin GraphQL endpoints and POS UI extension targets to surface and control cash operations directly on the register.

These capabilities matter for retailers that rely on cash: multi-till boutiques, cafés with mobile POS devices, regional chains with centralized reporting, and third-party developers building reconciliation, loss-prevention, or payroll integrations. The new model supports multiple devices connecting to one drawer, standardized reason codes for adjustments, and session-level financial summaries that make reconciliation deterministic rather than manual.

The following sections explain the new resources, how they map to real-world workflows, implementation patterns for developers, and operational guidance for merchants who must migrate or adopt these features.

What changed: the new building blocks

Shopify replaced and expanded the prior cash-tracking approach with several new GraphQL objects and POS extension APIs. The most significant additions are:

• CashDrawer: A first-class resource representing a physical cash storage unit at a location. Multiple POS devices can be assigned to the same drawer.
• PointOfSaleDevicePaymentSession: Replaces CashTrackingSession as the main session entity. A payment session covers the active usage period of a drawer (one shift, day, or defined interval) and records all cash movements.
• CashManagementReasonCode: Lets merchants attach categorical reason codes to adjustments, improving auditability and reporting.
• POS UI extension targets and a Cash Drawer platform API: Allow custom register UI and direct control of cash operations from the POS application.

Each resource is exposed through Admin GraphQL queries and mutations. Core mutations include creating drawers, assigning devices, opening and closing sessions, and recording adjustments. Sessions also expose a set of financial summary fields—total cash sales, refunds, net cash sales, adjustments, discrepancies, and overall sales totals—that support automated reconciliation workflows.

Why the new model matters: merchant needs and technical constraints

Stores rarely map one-to-one between a tablet and a cash drawer. Practical retail setups include:

• A single drawer shared across two ring devices for peak periods.
• A dedicated drawer per location but transient assignment of mobile devices (pop-ups, markets).
• A safe or backend drawer that receives cash drops from multiple front-of-house drawers.

Separating the drawer from the device addresses those patterns directly. Decoupling enables:

• Flexible hardware topologies: assign/unassign devices without reconfiguring drawer records.
• Accurate aggregation: query a drawer’s activity across devices for end-of-day totals.
• Consistent reconciliation: session-level financial fields make expected balances machine-calculable.

On the developer side, the existing POS architecture needed extensibility. Register screens are where merchants handle cash operations. By giving extensions both UI targets and a platform-level Cash Drawer API, Shopify hands developers the tools required to build custom workflows—automated safe drops, shift reports, or specialist cash-counting flows—without resorting to brittle workarounds.

Cash Drawers: concept, lifecycle, and API operations

A Cash Drawer models a physical storage unit for cash. Conceptually, it is a named container tied to a location and can have one or more POS devices connected.

Key properties and operations:

• Identification: a drawer has an ID and a human-readable name so staff can easily identify where cash is stored.
• Location scope: drawers exist at a specific location; queries should respect location boundaries.
• Device connections: the pointOfSaleDevices connection lets you see which devices are currently assigned.
• Balances and activities: queries return balances and a history of activities for auditing.

Primary GraphQL operations include:

• cashDrawerCreate: create a named drawer at a location.
• cashDrawers: query drawers across locations, including balances and activity.
• pointOfSaleDeviceAssignToCashDrawer: assign a device to an existing drawer, creating the device-to-drawer relationship.

Practical example A bookstore with two tills in the main sales area and a back-office deposit safe would use three CashDrawer objects: Till A, Till B, and Safe. During the day Till A and Till B are assigned to their respective devices. At midday, an employee records a cash pickup from Till A to Safe; that movement is represented as an activity against both the drawer (decrease in Till A balance) and the session that tracks the device.

Operational considerations

• Naming convention: use clear, consistent names (e.g., "Main-Till-1", "BackSafe-A") to avoid confusion during audits.
• Device affinity: although devices can be reassigned, map expected default assignments to reduce operator error.
• Physical labeling: align drawer IDs to printed or engraved labels on hardware to make verification fast.

Payment sessions: the atomic unit for cash reconciliation

PointOfSaleDevicePaymentSession is the session object for cash activity. It represents a contiguous period when a drawer is in active use—typically a shift or business day. Sessions track cash from open to close and aggregate the financial impacts of sales, refunds, adjustments, and discrepancies.

Core behaviors and fields

• Open and Close mutations: a session is explicitly opened (pointOfSaleDevicePaymentSessionOpen) and closed (pointOfSaleDevicePaymentSessionClose). The close mutation instructs Shopify to calculate expected balances and discrepancies automatically.
• Financial summary fields: totalCashSales, totalCashRefunds, netCashSales, totalAdjustments, totalDiscrepancy, totalSales, totalRefunds, and netSales. These fields remove much of the manual math that used to be necessary during reconciliation.
• Filters and queries: pointOfSaleDevicePaymentSessions supports filtering by status, opening_time, and closing_time for robust reporting.

Adjustment flow Adjustments—cash added to or removed from the drawer for reasons other than sales/refunds—are recorded with pointOfSaleDevicePaymentSessionAdjust. Each adjustment can be associated with a CashManagementReasonCode to classify the activity.

Why sessions are central Sessions tie device activity to a time-bounded window. This simplifies responsibilities:

• Cashiers are accountable for a session.
• Managers reconcile session totals against physical counts.
• Apps can automate discrepancy alerts, generate shift reports, and post session totals to accounting systems.

Real-world example A café opens at 7:00 a.m.: the morning barista opens a session on the tablet assigned to Till A. During the shift, the tablet records all cash sales. At 2:00 p.m., when the closing barista counts the drawer, they record a final physical count and close the session. The session close calculates expected balance from totalCashSales minus refunds plus adjustments. Any mismatch becomes totalDiscrepancy and is available to reporting and adjustment flows.

Reason codes: categorical context for adjustments

CashManagementReasonCode allows merchants to categorize cash adjustments using a human-friendly label and a machine-readable code. Shopify provides default codes; merchants can create custom ones.

Why reason codes matter

• Auditing: managers can filter adjustments by category (e.g., "cash drop", "petty cash", "till over") to identify patterns.
• Root cause analysis: consistent categories allow teams to spot frequent small discrepancies versus rare large errors.
• Integration: accounting systems and loss-prevention tools can map reason codes to GL accounts or incident types.

API operations

• cashManagementReasonCodeCreate: create a custom reason code.
• cashManagementReasonCodeDelete: remove an obsolete code.

Practical taxonomy Standard codes for retailers could include:

• CASH_DROP – transfer to safe/bank.
• PETTY – petty cash disbursement for supplies.
• TILL_OVER – overage found during count.
• TILL_SHORT – shortage found during count.
• HOUSE_CHARGE – manual adjustment for non-sale cash movement.

Implementing a good taxonomy reduces ambiguity and enforces consistent staff behavior during adjustments.

POS UI extensions: bringing cash operations into the register

Shopify added new POS UI extension targets and a Cash Drawer platform API so extensions can render custom UI elements on the register and interact with cash hardware and session data.

Capabilities exposed to extensions:

• Register details block and action targets: render information and actions on the register screen (available in API version 2026-04).
• Cash Drawer API: platform API accessible from POS UI extensions for reading and modifying drawer and session state.
• deviceId on Session API: extensions can obtain the current POS device ID and use Admin APIs to retrieve device and session data.

Developer opportunities

• Custom cash-count dialogs: present an ergonomic drawer count screen that guides a cashier through denominations and reports.
• Automated cash-drop flows: a button on the register that triggers prompts, records the movement, and prints receipts tied to a drawer activity.
• Shift management overlays: show session health, expected balance, and recent adjustments in real time.

Sample experience A third-party app builds an overlay that shows the current session's expected balance and a "Record Deposit" action. When tapped, the extension prompts for denominations, posts pointOfSaleDevicePaymentSessionAdjust to record the withdrawal, and prints a deposit slip. The manager receives an immediate notification if the deposit causes an unusually large discrepancy.

Security and permissions POS UI extensions operate within Shopify's extension framework. Ensure permissions and scopes are limited to the necessary Admin APIs. Extensions accessing sensitive cash operations should follow least privilege principles and rely on Shopify's authentication flows.

Common merchant workflows and how they map to the new APIs

The new model supports multiple operational patterns. Below are concrete workflows with recommended API usage.

Workflow: Single-Device Single-Drawer daily shift

• Setup: Create one CashDrawer for the location.
• Morning: Device assigned to CashDrawer; open session via pointOfSaleDevicePaymentSessionOpen.
• Day: Sales and refunds are associated with the session automatically. Adjustments (cash drops, petty use) recorded with pointOfSaleDevicePaymentSessionAdjust and tagged with reason codes.
• Close: Cashier counts, records final physical count, and calls pointOfSaleDevicePaymentSessionClose. Shopify computes expected balance and totalDiscrepancy.

Workflow: Two devices sharing one drawer (peak coverage)

• Setup: One CashDrawer, assign both devices using pointOfSaleDeviceAssignToCashDrawer.
• Opening: Each shift opening action references the same CashDrawer. Sessions may be per-device but reference common drawer activity. Reconciliation aggregates at the drawer level.
• Midday transfer: If a physical cash drop occurs into a back safe, record an adjustment specifying the target drawer (the safe) and reason code.

Workflow: Pop-up shop with multiple mobile devices and a single portable cash drawer

• Setup: Create portable CashDrawer and assign devices dynamically via POS UI extensions to reflect which device currently has the drawer attached.
• Reconciliation: Use payment sessions to record start/end for each device to establish accountability for cash flows.

Workflow: Centralized counting and bank deposit

• End of day: Cash from multiple drawers is consolidated into a Safe drawer using adjustment flows. The Safe drawer's session shows receipts from multiple sources. Deposit records can then be posted and attached to reason code CASH_DROP or BANK_DEPOSIT.

These workflows highlight the versatility of decoupling devices and drawers and the value of session-level summaries for reconciliation workflows.

Integrating cash data with accounting and analytics

Accurate, structured cash data improves downstream financial processes. Use the session financial fields to automate journal entries and to reconcile ledger balances with physical cash flow.

Mapping suggestions

• Cash sales and refunds: map totalCashSales and totalCashRefunds to a cash account in the general ledger with timestamps matching session close.
• Adjustments: map common reason codes to GL entries (PETTY to petty cash expense, CASH_DROP to intercompany or bank deposit account).
• Discrepancies: record totalDiscrepancy to a shrinkage or cash variance account for investigation.

Batching strategy Large retailers should batch session closes and adjustments in a single daily job that posts consolidated entries into accounting systems. Doing so reduces API calls and ensures that reconciliation happens against a stable snapshot (sessions that are closed).

Reconciliation automation

• Automated checks: compare actual drawer counts posted at close against totalCashSales and known adjustments; flag large discrepancies automatically.
• Root cause analysis: use reason code frequency over time to detect systemic issues: repeated PETTY use without receipts indicates a need for policy change.

Third-party integrations Third-party cash management apps can fetch pointOfSaleDevicePaymentSessions and cashDrawers to build reports, send alerts, and create fortified workflows such as scheduled pickups, armored carrier pickups, or bank deposit reconciliation.

Migration and compatibility: from CashTrackingSession to Payment Sessions

For merchants and developers with existing flows, migrating to the new model requires mapping legacy concepts to the new resources and preparing for data synchronization.

Migration steps

1. Audit current usage: identify where CashTrackingSession was used (apps, scripts, reports) and catalog session semantics (open/close semantics, adjustments).
2. Map entities: CashTrackingSession -> PointOfSaleDevicePaymentSession; physical drawer assumptions -> CashDrawer.
3. Create drawers: programmatically create CashDrawer objects for each physical storage unit if they do not exist.
4. Reassign devices: use pointOfSaleDeviceAssignToCashDrawer to reflect current device-drawer topology.
5. Recreate open sessions: for in-flight sessions at migration time, open Payment Sessions tied to the appropriate device and drawer, and reconcile historical counts as adjustments.
6. Update integrations: replace old GraphQL calls with new endpoints, and map fields such as totals and adjustments.

Considerations

• Historical data: depending on retention policies, some legacy cash-tracking records may remain available for historical reporting. Export historical data before switchover for audit continuity.
• Backwards compatibility: older apps designed for CashTrackingSession will not automatically gain the new features. Plan phased updates or create compatibility layers that translate old semantics to the new model where feasible.
• Staged rollout: test migration in a small set of stores before wide deployment. Use staging environments and simulated devices when possible.

Developer implementation checklist

Use this checklist when building or updating an app for the new cash management system.

1. Authentication and permissions
   • Ensure the app requests Admin GraphQL permissions for cash drawer and session operations.
   • Validate extension installation permissions for POS UI components.
2. Drawer model
   • Create a canonical CashDrawer per physical storage unit.
   • Implement naming conventions and metadata for location mapping.
3. Device assignment
   • Support pointOfSaleDeviceAssignToCashDrawer to assign/unassign devices.
   • Persist assigned device IDs in your app state if you need offline continuity.
4. Session lifecycle
   • Implement pointOfSaleDevicePaymentSessionOpen at shift start.
   • Subscribe to device signals or provide a manual open option in your extension UI.
   • Handle pointOfSaleDevicePaymentSessionClose with final counts and capture discrepancy handling logic.
5. Adjustments and reason codes
   • Provide UI flows for adjustments that require a reason code.
   • Fetch and cache merchant-created reason codes; offer a default mapping.
6. Reconciliation and reporting
   • Use financial summary fields for journal entry creation and reporting.
   • Implement alerting for discrepancies that exceed configured thresholds.
7. UI extensions
   • Use register details block to present session totals on the register screen.
   • Implement action targets to invoke cash-drop or deposit flows.
8. Error handling and retries
   • Build idempotent mutation patterns for adjustments to withstand network failures.
   • Validate state transitions: prevent closing already closed sessions.
9. Testing
   • Simulate multi-device scenarios.
   • Test device assignment changes mid-session.
   • Ensure proper handling of concurrent adjustments.
10. Logging and audit trail
    • Log all actions with user IDs, timestamps, deviceId, and reasonCode for audits.
    • Provide a way for managers to export activity logs.

Sample API sequences

Below are representative GraphQL operations and the sequence in which to call them. Use these as a blueprint for implementation logic. (These are schematic; refer to the Admin GraphQL reference for exact field names and required arguments.)

Sequence: New drawer and device assignment

1. Create a drawer: mutation cashDrawerCreate { ... }
2. Assign a device: mutation pointOfSaleDeviceAssignToCashDrawer { deviceId, drawerId }

Sequence: Open session and record adjustments

1. Open session: mutation pointOfSaleDevicePaymentSessionOpen { deviceId, drawerId, openingTime }
2. Record adjustment during session: mutation pointOfSaleDevicePaymentSessionAdjust { sessionId, amount, reasonCodeId, note }
3. Close session with final count: mutation pointOfSaleDevicePaymentSessionClose { sessionId, closingTime, actualDrawerCount }

Sequence: Querying sessions and drawers

• Query active sessions for a device: query pointOfSaleDevicePaymentSessions(filter: {status: OPEN, deviceId: "xxx"}) { nodes { totalCashSales, totalAdjustments } }
• Query drawer activity: query cashDrawers(locationId: "yyy") { nodes { balances, activities } }

Idempotency and error safety

• Use server-assigned session IDs to avoid duplicate opens.
• Implement client-side checks that prevent calling close on a session that is already closed.

Operational best practices and policies

Standardize processes to minimize discrepancies and streamline investigations.

Staff training

• Train cashiers on opening/closing sessions and attaching appropriate reason codes to adjustments.
• Maintain clear, short checklists for counts, denomination recording, and bank deposit procedures.

Process controls

• Limit who can perform adjustments and deletions through app-level role checks.
• Use daily till audits with managerial sign-off when discrepancies exceed thresholds.

Physical controls

• Use tamper-evident bags for cash drops.
• Schedule regular cash pickups and avoid accumulating large amounts in front-of-house drawers.

Loss prevention

• Monitor trends by reason code: repeated small shortages by the same cashier may indicate theft or poor counting practices.
• Integrate session data with CCTV metadata where possible to correlate incidents.

Counsel for multi-currency environments

• Ensure drawer currency is defined per CashDrawer; do not mix currencies in a single physical drawer without clear policies.
• When multi-currency sales are accepted, consider routing cash in foreign currency to separate drawers tagged for that currency.

Testing, QA, and rollout guidance

A controlled approach reduces downtime and user friction.

Staging and test devices

• Use a staging Shopify environment and test POS devices to validate extension behaviors and API interactions.
• Simulate multi-device scenarios and assign/unassign devices frequently during tests.

User acceptance testing (UAT)

• Pilot builds with a small subset of stores that represent the diversity of topologies (single-till, multi-till, pop-up).
• Collect feedback from floor staff about UI clarity and from managers about report accuracy.

Monitoring and metrics

• Track failed mutation rates, average session open/close times, and # of adjustments per session.
• Use those metrics to refine UI flows and to identify training needs.

Rollout strategy

• Phased rollout reduces risk: pilot -> early adopters -> full rollout.
• Provide rollback plans: when necessary, constrain changes to UI-only updates while leaving core session flows untouched until resolved.

Troubleshooting and common pitfalls

Concurrency and race conditions

• When multiple devices update the same drawer/state, implement idempotent operations and optimistic locking strategies where possible.
• Avoid race conditions by ensuring session operations validate current session status.

Network outages

• POS devices may operate intermittently; publish clear handling rules for offline adjustments. If offline mode is supported, reconcile local adjustments with server state upon reconnect.
• Prevent double recording by tagging local actions and checking server-side before re-posting.

Incorrect device assignments

• Mismatched device-to-drawer assignments can cause reconciliation headaches. Provide a visible indicator on devices showing current drawer assignment.

Discrepancies due to rounding or currency exchange

• Small discrepancies can be caused by rounding during tax or currency conversions. Configure discrepancy thresholds and reporting that takes rounding into account.

Permission errors

• Ensure that the API tokens used by extensions have the required Admin GraphQL privileges. Permission mismatches are a common cause of unexpected failures.

Opportunities for app developers and partners

The new model creates a range of possibilities:

• Reconciliation apps: Automate journal entry creation and discrepancy triage using session summaries.
• Loss-prevention platforms: Correlate reason codes and adjustments with user behavior and CCTV to build anomaly detectors.
• Workforce management: Link session times to employee schedules for easier payroll reconciliation.
• Hardware integrations: Tie cash drawer open events to physical sensors and audit logs.
• Banking and logistics: Automate pickup scheduling and deposit reconciliations with armored carriers and banks.

Example: cash forecasting An analytics app can use historical session totals and adjustment frequency to forecast daily cash needs and predict safe pickup schedules. This reduces the cash held on-premises and lowers theft risk.

Example: automatic discrepancy escalation An app monitors closed sessions and triggers an immediate escalation workflow when totalDiscrepancy exceeds a threshold: notify managers, lock suspicious user accounts, and request CCTV review.

Security, compliance, and privacy considerations

Cash data is operationally sensitive. Treat it with the same rigor as payments data.

Access control

• Limit who can perform adjustments and delete reason codes.
• Use Shopify’s OAuth and app permission model to request minimal necessary scopes.

Audit logging

• Persist a full audit trail that includes user ID, deviceId, timestamp, reasonCodeId, and pre/post balances for each adjustment.
• Make audit logs immutable if possible, or retain original records when edits occur.

Regulatory compliance

• Local cash-handling and financial reporting regulations vary. Ensure that your reconciliation processes and recorded data meet local tax and reporting obligations.
• For multi-jurisdictional merchants, map adjustment reason codes to decision logic that reflects local compliance rules.

Data retention and privacy

• Store only the necessary cash activity details and purge data according to merchant policies and legal requirements.
• Avoid storing unnecessary personally identifiable information (PII) with cash events unless required for internal investigations.

Looking ahead: advanced automations and integrations

The new resources unlock long-term automation possibilities:

• Real-time discrepancy detection: use streaming session updates to detect anomalies as they occur instead of at the end of a shift.
• Machine learning for shrinkage: train models on historical adjustments and reason codes to predict which shifts or registers are at risk.
• Robotic process automation (RPA): automate deposit scheduling and communication with armored carriers based on session totals and safe drawer thresholds.
• Cross-location optimization: consolidate pickup routes by projecting combined daily cash needs using drawer-level data across stores.

These applications depend on structured, timely data. The new GraphQL resources and POS extension APIs make that possible.

FAQ

Q: Can multiple devices share the same CashDrawer simultaneously? A: Yes. CashDrawer is decoupled from devices so multiple POS devices can be assigned to a single drawer. Sessions remain device-specific, while drawer activity aggregates across assigned devices.

Q: How do I record a cash drop from a till to a back-office safe? A: Use pointOfSaleDevicePaymentSessionAdjust on the originating device’s session to record the removal, tag the adjustment with a CashManagementReasonCode such as CASH_DROP, and optionally record a complementary adjustment on the Safe drawer’s session to reflect the incoming funds if your workflow requires the safe to have its own session.

Q: What happens to historical CashTrackingSession data? A: Historical records remain in place per Shopify’s data retention policies. Developers should export or archive legacy data if continuous historical reporting is required. Move forward by mapping existing flows to the new PointOfSaleDevicePaymentSession model.

Q: Can merchants create custom reason codes? A: Yes. Shopify provides default reason codes and lets merchants create custom CashManagementReasonCode entries via Admin GraphQL so adjustments can be categorized to match merchant operations.

Q: How does the session close compute expected balances and discrepancies? A: When a session is closed using pointOfSaleDevicePaymentSessionClose, Shopify calculates expected balances from session activity (cash sales, refunds, and recorded adjustments) and compares that to the physically reported closing count. The difference is returned as totalDiscrepancy.

Q: Are POS UI extensions required to use the new cash APIs? A: No. The Admin GraphQL APIs are available to backend apps, but POS UI extensions provide the best merchant experience for in-register interactions: quick counts, deposit flows, and register buttons for recording adjustments.

Q: How should I handle offline mode and intermittent connectivity? A: Design client-side logic to queue idempotent mutations and reconcile them once connectivity returns. Use server-side validation on session state to prevent duplicate closes or invalid adjustments.

Q: Can I export drawer and session activity for external reporting? A: Yes. Use cashDrawers and pointOfSaleDevicePaymentSessions queries to retrieve full activity and summary fields for export to BI or accounting systems.

Q: Where can I find developer documentation and API references? A: Shopify’s Admin GraphQL API and POS UI extension documentation (API version 2026-04 and later) include detailed references for CashDrawer, PointOfSaleDevicePaymentSession, CashManagementReasonCode, and the POS Cash Drawer platform API.

Q: What are the recommended practices for naming CashDrawers? A: Use consistent, human-readable names that include location context and physical identifiers (e.g., "London-Main-Till-1", "NYC-BackSafe") to simplify audits and match labels on hardware.

Q: Will the new APIs affect payroll or shift reporting? A: The session object includes opening and closing times and can be mapped to employee shifts for payroll reconciliation. Use session lifecycles to align shifts with sales and cash responsibilities.

Q: How should discrepancies be handled operationally? A: Define thresholds for automatic escalation. Small discrepancies may be logged and reviewed weekly; larger discrepancies should trigger immediate investigation, including CCTV review and managerial interviews.

Q: Do reason codes support localization or multiple languages? A: CashManagementReasonCode includes a human-readable name and a machine-readable code. For multi-lingual shops, adopt a naming convention and maintain localized label mappings in the app UI.

Q: Can an app automatically assign devices to drawers? A: Yes. Use pointOfSaleDeviceAssignToCashDrawer to programmatically manage device-to-drawer assignments; ensure that the app enforces authorization and confirms physical device-handling policies.

Q: How do I test custom register UI components? A: Use Shopify’s POS UI extension development tools and test on staging devices. Simulate drawer and session operations, and validate the app behavior under different device assignments and network conditions.

Q: What should I watch for in large rollouts across many locations? A: Prioritize consistent naming, device mapping accuracy, staff training, and phased rollout. Track key metrics like session open/close rates, discrepancy frequency, and failed API calls to spot systemic issues early.

Q: Are there limits on the number of drawers or sessions per location? A: Shopify's API limits depend on plan and API version. Review the Admin GraphQL API limits and implement batching where large volumes of sessions or drawers are expected.

Q: Where can merchants find guidance for cash handling best practices? A: Merchants should consult internal operations and loss-prevention teams. Use the CashManagementReasonCode taxonomy and session audit logs to implement policies and continuous improvement programs.

---

This rebuilt foundation for cash management on Shopify POS modernizes how merchants and developers manage physical cash. By representing drawers as discrete resources, surfacing detailed session summaries, and enabling extensible register UI, Shopify provides the primitives required to automate reconciliation, minimize shrinkage, and craft tailored in-store experiences. Developers who adopt these resources can build more reliable operations plugins, and merchants can take immediate advantage of clearer audit trails and more consistent cash workflows.