Age verification POS workflow
Put the product rule where the cashier cannot miss it
A smoke-shop catalog can mix unrestricted accessories with products governed by different minimum-age rules. LiftedPOS allows the sellable product or variant to carry none, 18+, or 21+. At checkout the current cart is evaluated as a whole, and the highest age rule in the cart becomes the required threshold. Adding a newly restricted line or a higher-threshold item invalidates an earlier check so the cashier cannot rely on an outcome that covered a narrower cart.
The gate appears before the payment surface. The cashier follows the merchant's procedure to inspect physical identification and enters DOB. Calendar-based age logic handles the exact-birthday boundary and rejects impossible or future dates. The DOB never leaves the browser; the completed transaction receives the computed age and recorded outcome rather than the date that was typed. A known underage result cannot be represented as verified.
An authorized workflow may preserve an explicitly bypassed result. That is not a quiet skip: it is a different outcome that can retain the computed age when one was entered. Merchants decide which roles may use an override, why, and how it is reviewed. The result is a cashier-controlled age gate with an auditable operating record.
Compliance boundary
Software can enforce a step. The merchant owns the policy.
The merchant remains responsible for current federal, state, local, tribal, and other applicable requirements; minimum-age configuration; product classification; acceptable forms of identification; visual inspection; employee training; record retention; privacy policy; signage; and escalation procedure.
Rules and enforcement practices change. Before rollout, have qualified counsel or the responsible compliance professional approve the store's procedure, then demonstrate that procedure with actual products and employee roles in the configured tenant.
Keep every flavor, strength, size, and device tied to the exact stock record
Smoke and vape assortments are not well served by a generic product name with one quantity. LiftedPOS can use configurable variants and sellable child products so flavor, strength, size, color, device family, pack configuration, or another chosen attribute can describe the exact unit. Each sellable item can retain its own price, cost, exact UPC, custom SKU, numeric SKU, image, tax behavior, age rule, status, and inventory identity.
The register's dedicated barcode field resolves one exact match. It checks UPC and custom SKU, and numeric SKU when the submitted code is numeric. No match stops with a not-found result. Multiple exact matches stop as ambiguous rather than ringing whichever product happens to appear first. Rollout tests the merchant's chosen scanner, symbology, station, and connection method with real products.
Product search, category browsing, and parent-to-variant selection provide alternate paths when a barcode is damaged or the customer is choosing between variations. The key is that every route into the cart returns to the exact sellable item that inventory and reporting understand.
Move from low stock to supplier, purchase order, and receiving
Low-stock visibility identifies catalog pressure, but a smoke-shop inventory system also needs an action behind that signal. LiftedPOS supports supplier records and purchase orders connected to the same product catalog. Operators can create the order, retain cost and status context, and compare the delivery with what was expected.
Full or partial receiving records what actually arrived rather than forcing a perfect shipment. That matters when popular variants are shorted, substituted, or split across deliveries. Multi-location inventory and transfers can move available stock from one configured store to another before the buyer places a duplicate order. Location, source, destination, line quantity, and transfer state create a shared operational record in place of a phone call and an unexplained on-hand adjustment.
Use real supplier, receiving, transfer, and inventory examples during rollout to verify the exact data contract the merchant will operate.
Recognize repeat customers without losing control of refunds and staff
Customer profiles, transaction history, loyalty, rewards, and wallet context can connect repeat visits to the sale. The current loyalty surface supports configured spend-based or punch-card programs, and the transaction record gives staff a place to review what was purchased instead of relying on memory. Merchants should design enrollment, consent, messaging, and privacy practice around their actual customer program.
Refunds are permission-controlled and server-capped by what remains refundable. Full, amount, and eligible line-item modes can retain a reason and history; refunded inventory is returned according to the transaction workflow, and associated loyalty consequences stay connected to the sale. Card-present money movement can still depend on the terminal, processor, original transaction, settlement state, and deployed configuration, so the POS must not promise that every refund can be completed away from the payment device.
Employee roles, permissions, schedules, time clock, transaction history, dashboards, product analysis, inventory views, and reporting give the owner context around the people and products behind the totals. For multiple stores, test what an employee can see and do at each location rather than assuming an “admin” label is a complete control design.
Connect supported PAX payments without moving card data into the POS
LiftedConnect is the payment companion being qualified for supported LiftedPOS PAX A920 and A920 Pro deployments. Its verified on-device engine runs alongside BroadPOS through PAX POSLink 2 and excludes raw cardholder data from the allowlisted result. The production backend handoff that connects a LiftedPOS sale to that safe result must be enabled and proven before merchant use.
For a supported credit MID, processor tokenization is opt-in and defaults off. When the merchant enables it and the host supports it, LiftedConnect's on-device engine can request a processor-issued token. Retaining that surrogate with the original LiftedPOS sale still requires the production backend handoff to be enabled and proven.
That qualified transaction thread is the intended token foundation for cards on file, open-batch void resolution, and future refunds without asking staff to re-enter card details. Processor, MID, merchant configuration, host support, backend implementation, and rollout stage determine which token-backed workflows are enabled. Demonstrate the actual terminal, merchant account, network-recovery path, void procedure, settled-return procedure, and access controls before launch.