Platform / Sell
Keep the sale and its records together.
Bring ID checks, package details, receipts and reporting into one checkout workflow. Follow the record from the shelf to the sale, so your team can see what happened and what needs attention.
Product preview with illustrative records. Customer rollout requires confirmed store setup, supported features and go-live approval.
Example dispensary · Register 1
SA-EVRGRN01-000418
- 01
Scan the ID
Example checkThe barcode on the back of the licence is parsed on the register itself. Only the method and the result are recorded; never the name, number, address or date of birth.
age check · id_scan · verified
- 02
Scan the Retail ID
Example checkThe code is resolved in order: a unit's Retail ID, then a Metrc package tag, then a product barcode or SKU. An unknown code is reported as unknown, never guessed.
line 1 · package 1A4…A7F2 · qty 1
- 03
Gate checks
Example checkEvery sale rule runs over the whole cart: package state, recall, lab result, expiry, stock, purchase limit, hours, confirmed taxes, go-live and the ID check. Any block stops the sale.
11 rules · ALLOW
- 04
Tender
Example checkCash is counted at the drawer. The payment record and the sale commit in one database transaction: either both are recorded or neither is.
cash · captured · change returned
- 05
Receipt
Example checkNumbered from the location's own counter, with the dispensary's name, address and licence, the date and time, the employee's first name and last initial, each product's form and quantity and every tax on its own line.
receipt SA-EVRGRN01-000418
- 06
Metrc queued
Example pendingThe sale is written to the durable Metrc queue under the same identifier, with verify-before-retry so it is never sent twice. On a simulated location it reports to the simulated state store.
metrc_sync_queue · QUEUED
Illustrative register walkthroughOne transaction identifier follows the sale through the payment, the inventory movement, the receipt and the Metrc submission. Fictional store, fictional sale.
One transaction from the shelf to the state system of record.
The register is one stage of a single transaction architecture. What it sells was received and reconciled by the same ledger; what it records is what Reconcile and the audit binder later prove.
- Verified
- Checked and agreed at this stage.
- Review
- A person needs to decide.
- Blocked
- The workflow stops here until it is resolved.
- Pending
- Waiting on a step that has not happened yet.
Six records, one identifier.
A sale is not a receipt with a payment beside it. The sale, its payment, the inventory units it took off the shelf, the movements it posted, the receipt it printed and the Metrc submission it queued all carry the same identifier, so any one of them can be traced to the others.
- 01
Sale
The transaction row, its lines and every status change, checked against the state machine on every move.
- 02
Payment
Cash counted at the drawer and recorded in the same database transaction as the commit; either both exist or neither does.
- 03
Inventory
The exact units taken off the books, the quantity movements posted and the package lifecycle events recorded.
- 04
Receipt
Numbered from the location's own counter and stored as a snapshot, so a later settings change never rewrites a past receipt.
- 05
Metrc submission
A durable queue entry under the same identifier, read back before any retry so it is never sent twice.
- 06
Audit
Who did it, on which register, on which shift, with which manager's approval where one was needed.
Built for the New York dispensary floor.
Product preview with illustrative records. Customer rollout requires confirmed store setup, supported features and go-live approval.
- Preview
Shifts and cash events
A shift opens with a counted float on a named register. Paid-ins, paid-outs, safe drops and no-sale drawer opens are recorded with a reason. The close is blind: the person counts before seeing what the records expect, and a variance over the location's tolerance needs a note and a manager's approval.
- Preview
Cash tender
Cash flows through the same payment contract as any other tender. The tender, the payment record and the commit happen in one database transaction, and a repeated request with the same idempotency key returns the completed sale instead of selling twice.
- Preview
Tax engine
New York's state and local adult-use retail taxes and the sales tax on accessories as versioned rules per organisation and location. Templates arrive as drafts; a person confirms them before a production location can sell. Every sale stores the versions it applied.
- Preview
Transaction state machine
Every status change is checked against an explicit set of allowed transitions, so a sale can never complete twice, be paid after it was cancelled, or be reported to Metrc before it was committed.
- Preview
Returns and voids
A same-day void needs the capability or a manager's override; units go back on the shelf only when the person confirms the product never left the counter, otherwise they are quarantined. Returned units are always quarantined, the refund is the proportional share paid including tax, and a Metrc item is opened for a person to record.
- Preview
Discounts under control
A discount on a line or on the whole cart needs the discount capability or a manager's own credentials, and a reason. It is recorded with who approved it, and the cart is re-checked and re-priced afterwards.
A sale moves through named states, and only along allowed paths.
The happy path and the side exits, as the register names them on screen. A transaction that leaves the path lands in a state a person can see and act on; it is never lost between steps.
- StopCOMPLIANCE_BLOCKEDBlocked by a compliance rule
- StopPAYMENT_FAILEDPayment failed
- StopMETRC_FAILEDCompleted · Metrc report failed
- ReviewREVIEW_REQUIREDNeeds review
- StopCANCELLEDCancelled
A sale of accessories only completes without a state report. A sale with cannabis lines is committed straight into the Metrc-pending state and is treated as reported only when Metrc, or the simulated state store on a practice location, confirms it.
11 rules run before payment. Any block stops the sale.
The same engine that gates receiving, adjustments and the kiosk runs every sale rule over the whole cart, first when the cart is validated and again, against fresh facts, inside the commit. A rule the engine cannot run blocks rather than silently allowing.
- NY-PKG-001Only accepted packages are sellable
- NY-REC-001Recalled product cannot be sold, received or adjusted into stock
- NY-LAB-001Passing lab results before sale
- NY-EXP-001Expired product cannot be sold
- NY-AGE-001Valid ID showing 21 or older, every transaction
- NY-LIM-001Per-transaction purchase limits
- NY-HRS-001Sales only during posted hours
- NY-GL-001Live sales only after go-live activation
- NY-TAX-001Confirmed tax rules, each tax shown separately
- NY-TRK-001Cannabis sold from a tracked package
- NY-INV-001Enough on hand
What each rule can say
- Allow
- The fact the rule needs is present and the condition holds.
- Warn
- The sale continues with the warning recorded; a practice location selling on draft tax rules, for example.
- Block
- The sale stops with the rule, its version, the reason, the remediation and the regulatory citation on the record.
Rules are versioned and cited
Each rule carries a version, a severity, the source citation and the remediation text. An organisation may tighten a rule; a block that permits exceptions can be relaxed once, for one subject, by an approved exception, and the record says so.
Scanned or inspected. Never a glance, and never an image.
New York requires staff to inspect the customer's identification and determine that the customer is 21 or older before every sale. The register accepts exactly two ways of recording that, and stores an event, not the ID.
ID scanned
PreviewThe barcode on a driver licence or ID card is read by the scanner and parsed on the register, which computes the age and the expiry from the card itself. Only the computed answer leaves the device.
ID inspected by hand
PreviewThe budtender chooses the kind of government-issued photo ID and confirms three things: the photo matches, the ID is in date and the date of birth shows 21 or older. A verified record cannot be saved without all three.
What is stored: the method, the result, the kind of ID and, for a scan, the issuing state. What is never stored: the image, the name, the ID number, the address or the date of birth. Judging a customer's age by looking at them is refused when recorded, and an older record made that way does not satisfy the rule.
Every New York field, every time.
The statutory fields are not settings. A store can add header and footer lines and choose the paper width; nothing else. The register refuses to take payment for a cannabis sale whose receipt could not carry every field.
- Dispensary name, address and licence number
- Date and time of the transaction
- Employee's first name and last initial
- Each cannabis product's form and quantity
- Each Article 20-C tax on its own line
Printed and kept
Receipts print to ESC/POS thermal printers over Web Serial or WebUSB, on 58 mm or 80 mm rolls, with the receipt number as a barcode so a return can be found by scanning it. The receipt is stored as a snapshot at completion.
The setting exists; the sending does not yet.
Queued, verified, never sent twice.
Every cannabis sale is written to a durable queue and reported to the destination its location's mode named when it was queued: the simulated state store, Metrc's sandbox, or production Metrc.
- A send is written down before the request leaves, so a crash mid-send leaves a row that is read back before it is ever sent again.
- An answer that may mean “recorded” is read back from Metrc at once: found means confirmed; cannot tell means a person reviews it; not there means it is looked at again after a settling time.
- Definite failures are retried with backoff and jitter; after the attempt limit the item is failed and escalated. Metrc's own refusals fail at once, with its message.
- A void archives a confirmed receipt under the same discipline, and waits while the sale's own report is still unsettled.
Every sale queued to Metrc with verify-before-retry so nothing is sent twice; New York's sales payload fields are still being confirmed with Metrc.
Waiting on: Metrc's written confirmation of the New York sales report fields; production API access.
Why production is gated
Metrc's documented New York receipt carries the transaction identifier, the time, each package and quantity and the price. Where the two Article 20-C taxes, the payment method, the employee and the device go is still unresolved with Metrc in writing. While any element is unresolved, no location can activate live sales.
No base subscription. One disclosed fee per completed sale.
Hardware, payment processing and professional deployment are priced separately. Nothing here is a quote.
- Base Smoke Alarm POS software subscription
- $0 a month
- Compliance Technology Fee
- $1.50 per completed qualifying retail transaction
The fee supports transaction assurance, inventory validation, compliance workflows, reconciliation and regulatory-system connectivity. It is Smoke Alarm's fee: not a New York State fee or any government charge, not a payment-processing charge and not a charge from any payment network, and separate from both processing fees and cannabis taxes. Voids, returns and practice sales never qualify.
The Compliance Technology Fee is Smoke Alarm's fee, separate from payment processing and from any cannabis tax. It applies per completed qualifying retail transaction, is disclosed before the transaction completes, and its checkout presentation and tax treatment follow the merchant agreement and the location's configuration.
Tax treatment of the Compliance Technology Fee is configurable per location and merchant agreement — not yet confirmed. Smoke Alarm does not assert that the fee is or is not taxable.
- Hardware: priced separately
- Payment processing: priced separately
- Professional deployment: priced separately
Example checkout
Simulated- Products
- $87
- Compliance Technology Fee
- $1.50
- Applicable cannabis taxescalculated according to the location's configured tax rules
- at checkout
- Total
- calculated at checkout
The Compliance Technology Fee is Smoke Alarm's fee, separate from payment processing and from any cannabis tax. It applies per completed qualifying retail transaction, is disclosed before the transaction completes, and its checkout presentation and tax treatment follow the merchant agreement and the location's configuration.
Illustrative example checkoutIllustrative amounts. How the fee appears at checkout follows the merchant agreement and the location's configuration.
What the badges on this page mean.
- Available
- Available features still require store setup and authorized data. This is not a connected-account status.
- Preview
- Explore with illustrative data. Not generally released for customer use.
- Requires setup
- Provider credentials, a partner agreement or approval may be needed before use.
- Planned
- Not available yet.
Register, cart, compliance rules at the sale, statutory New York receipts, shifts with blind close, voids and returns; live sales open only after the go-live checklist.
Waiting on: Go-live: confirmed tax rates per location, Metrc sales authorization and payload mapping.
A payment boundary that refuses any processor not lawfully able to accept cannabis sales; debit, pay-by-bank and ACH are added through a contracted provider's adapter.
Waiting on: A contracted, cannabis-lawful pay-by-bank partner chosen with counsel, its adapter under src/integrations/payments/smokepay/partners/, and its credentials.
Illustrative register walkthroughThe walkthrough at the top of this page and every amount, package tag and identifier in it are fictional. The kiosk hands orders to this register; the storefront will share its inventory.
Ring one sale on a simulated register.
Twenty minutes with Ken and Charles: scan an ID, scan a Retail ID, watch the gate run, take cash and read the receipt. Then compare it with what your register prints today.