- 1. Identify which connection actually failed
- 2. Test store internet loss on a prepared register
- 3. Test Metrc downtime while the POS stays online
- 4. Make recovery prove more than a green connection light
- 5. Use these three demonstration scenarios
- 6. Review the integration beyond the outage
- 7. What Blackleaf offers-and what still needs validation
- Frequently asked questions
An offline dispensary POS needs two separate plans: one for losing store internet and another for Metrc downtime. Internet loss requires a prepared register that can safely save permitted work without its cloud connection. When only Metrc is unavailable, an online POS may be able to record permitted sales while reporting waits. Neither condition proves that payments, required customer checks, shared inventory or later reporting will work.
The useful question is: What survives the interruption, what must stop, and how will we prove the records are right afterward? This guide gives dispensary owners, general managers and inventory leads a practical demonstration checklist. Its test scenarios are hypothetical, not Blackleaf customer results.
1. Identify which connection actually failed
A register reaching the internet, the POS reaching its service and the POS reaching Metrc are different observations. Ask the vendor to show each dependency independently.
| Dependency | Question staff need answered |
|---|---|
| Register and POS service | Can this authorized device retrieve the data it needs and save a transaction? What remains local? |
| Metrc | Can the integration submit the required record and confirm its result? Which reports are still pending? |
| Payment provider | Was this tender actually authorized? Is its outcome unknown, and what is the supported way to check? |
| Inventory and online orders | How current are quantities and reservations? Can another register or online order claim the same unit? |
| Required customer and sale checks | Which checks require current information, and which work must pause when it is unavailable? |
| Receipts and peripherals | Can the required receipt or output be produced on the actual equipment? |
Keep a sale’s saved state, payment state and reporting state separate. A printed receipt does not establish electronic payment authorization or accepted Metrc reporting. For the broader responsibilities of checkout, hardware and connected systems, see what a dispensary POS actually does.
Before using any outage mode, establish the store’s current regulatory procedure and permitted operations. For example, California’s loss-of-access rule, §15050, requires comprehensive activity records and prohibits initiating transport, receiving or delivering cannabis goods until access is restored. This illustrates why an offline feature is not blanket permission to continue every operation. Confirm the current requirements for the actual licensed location.
2. Test store internet loss on a prepared register
An offline demonstration should begin before the connection is removed. Identify the authorized device, staff role, available local data and the time that data was last refreshed. A new register that has never downloaded its working data is a different case from a prepared register.
Ask the vendor to demonstrate these requirements in an approved test environment:
- Save before showing completion. The permitted sale, local quantity effect and work needed for later reporting should be saved durably. A screen that temporarily remembers the cart is insufficient.
- Survive a reload and restart. Restore the saved transaction without losing it or deducting stock a second time. Identify the remaining exposure if the device itself is lost.
- Show when work must stop. Reproduce a failed storage write, expired staff authority or unavailable required verification. Staff need an explicit hold and a recovery owner.
- Keep the original identity. Retain the sale reference, licensed facility, register, staff, original time and time zone, package, quantity and unit.
The last-unit problem
Imagine two disconnected registers each showing one remaining unit while an online order also requests it. Those screens cannot establish a shared live balance merely because each one has cached inventory.
Require a demonstrated restriction: a designated offline register, allocated stock quantities or another enforced policy appropriate to the deployment. Include online reservations in the exercise. Do not accept “it will sync later” as the answer to who may sell the unit now.
Electronic tender needs its own provider-supported test. An offline POS mode does not establish offline payment approval or settlement. If authorization is uncertain, check the existing payment through the supported process before attempting another charge.
3. Test Metrc downtime while the POS stays online
In the second demonstration, keep store internet and the POS service available while Metrc cannot be reached. This isolates reporting continuity from register connectivity.
Where the implemented workflow and applicable procedure permit it, a POS can save a sale in its own durable records while the required reporting waits in a separate queue. Ask to see the saved reporting record, not just a banner saying the connection is down.
| State | What the team should be able to establish |
|---|---|
| Pending | The event is saved and waiting; its original reference, age and next action are visible. |
| In progress | An attempt is underway and has an identifiable owner or process. |
| Accepted | The external result is confirmed and linked back to the original sale. |
| Rejected | The response identifies work that needs correction, with a person responsible for it. |
| Uncertain | The system cannot yet establish whether the attempt was accepted. It needs investigation before another create request. |
The product may use different labels. What matters is whether staff can distinguish these outcomes and retrieve their evidence. Ask for the last successful sync, pending count, oldest unreported event, retry history and unresolved exceptions. Agree who monitors reporting obligations during the interruption.
4. Make recovery prove more than a green connection light
When connections return, locally saved work first needs a confirmed handoff to the POS service. Eligible reporting can then proceed through the supported Metrc integration. If both connections failed, restoring internet alone does not prove either handoff is complete.
- Account for every saved event. Match the original local sale to its resulting POS record. Repeated uploads must not create another sale or quantity deduction.
- Preserve order and identity. Retain original times, facility and package references. A correction to an accepted receipt must follow the appropriate original record; an unsent cancellation may require different handling.
- Check uncertain acknowledgements before retrying. A timeout can follow a successful external write. Establish what already exists before another create request.
- Separate retryable faults from correction work. Temporary unavailability, invalid data and insufficient authorization need different responses. A rejected record should not disappear into endless retries.
- Close the remaining exceptions. Reconcile successful, failed and uncertain items individually, including partial batches. Keep an owner and next action for anything unresolved.
Metrc’s California API documentation describes rate limiting, object limits and returned IDs. Some rate-limit responses include a Retry-After instruction. Ask how the integration respects current limits and avoids a burst of retries after recovery; confirm the applicable endpoint, version and agreement rather than assuming one universal throughput.
What if Metrc accepted the receipt but the response disappeared?
Have the vendor reproduce this case. The original reporting attempt may have succeeded even though the POS never received confirmation. The integration should use the supported lookup and original references to establish the result before creating another receipt, or hold the event for investigation if it cannot safely decide.
The California API documents receipt lookup by external number. An external reference is useful for investigation; its presence alone does not prove that repeated create requests are automatically deduplicated. Require evidence of the vendor’s complete recovery behavior.
5. Use these three demonstration scenarios
All scenarios below are hypothetical. Ask the provider to run them in an authorized environment with test records. Record the product version, facility and jurisdiction scope, configured permissions, expected result, observed result and evidence. An explanation of what should happen is not an observed pass.
Scenario A: the store loses internet
A prepared register begins permitted test checkout. The provider disconnects store internet, completes only the supported permitted work, then reloads and restarts the register before reconnecting it.
Inspect: the original saved sale, local stock effect, tender result, pending reporting record and recovered POS record. Check that required unavailable verification stops dependent work and that one intended sale remains after repeated handoff attempts.
Scenario B: Metrc is unavailable, but the store is online
The provider makes Metrc unavailable while the register and POS service remain connected. Several permitted test sales wait for reporting. Metrc becomes available again; one event is rejected and another encounters a rate limit.
Inspect: the pending queue before recovery, automatic processing where supported, accepted references afterward, retry delays and the rejected event’s owner. Ask whether independent eligible work can proceed without hiding blocked dependencies.
Scenario C: acceptance is unknown
Metrc accepts a test receipt, but the response does not reach the POS. The team then attempts recovery.
Inspect: the original sale/event reference, existing external receipt, lookup evidence, quantity effects and final reporting state. Require one intended receipt and stock effect, or a visible unresolved hold if the result cannot be established. A repeated success message is insufficient evidence.
Download the 20-scenario Metrc outage checklist (CSV). Every row begins not_tested. The blank worksheet captures evidence and ownership; it does not run a test, report sales or establish that a vendor passed. Keep completed operational evidence in approved private storage and use redacted references in shared notes.
6. Review the integration beyond the outage
Continuity depends on the quality of the normal records as well as the recovery process. Review these checks alongside the POS integration guide and inventory and receiving guide.
- Direction and timing: identify which records move each way, normal refresh frequency and how stale data is shown.
- Receiving: compare physical packages and quantities with the manifest before affected stock is released. Retain discrepancies and their resolution.
- Units, categories and taxes: review mappings and configured tax treatment. A package tag alone does not establish the correct category, conversion or tax.
- Voids and returns: trace the original and correcting records, tender effects, reporting and permitted product disposition. Refunding money does not automatically make returned stock sellable.
- Staff-accessible audit history: retrieve original references, staff, times, attempts, errors and authorized changes. Confirm export access and retention.
- Transfers: match sending and receiving licensed facilities, manifests, packages and quantities. A shared portfolio screen does not complete a regulated transfer.
Reconcile at one cutoff
As an operating control, compare physical package counts, POS activity and Metrc records at close and after recovery. Use the same facility, package, unit and cutoff time. Account for sales still pending at that cutoff, accepted corrections, holds, returns and transfers.
A difference is a reason to investigate; it does not by itself establish shrink. Do not overwrite one balance simply to make the screens match. Preserve the explanation, authorized correction and external outcome, or leave an open exception with an owner and review time. This suggested operating cadence is separate from any jurisdiction’s required reconciliation interval.
Recovery can also release old stock or order events. Before those events trigger customer messages, recheck current order state, stock, recipient, permission and relevance through the supported messaging workflow. An old pickup-ready event should not become a new invitation after the order was canceled.
7. What Blackleaf offers-and what still needs validation
Blackleaf POS is in production in California, with production Metrc approval. More states are rolling out soon. POS AI agents and offline recovery are also in production. Confirm the licensed-store setup and operating limits during onboarding.
Internet-loss checkout, Metrc outage continuity, durable pending reporting and automatic recovery are production Blackleaf POS capabilities in California. This guide explains the operating checks for your store setup; it is not a report of completed outage tests. Confirm supported equipment, permitted work, payment dependencies and recovery controls during onboarding.
Production approval is distinct from an outage-feature acceptance test. Metrc’s validation explanation limits validation to specified functions and does not endorse a vendor’s product quality or usefulness. It does not establish all-state coverage, every operation, security certification, offline payment settlement or an SLA.
Use the current feature map, security and compliance review and implementation guide to prepare a store-specific discussion. Connected POS AI agents are in production in California; reporting recovery should be evaluated on its implemented controls, not attributed to AI without evidence.
Blackleaf Texting is available separately and can complement supported existing POS systems. If your immediate need is better customer communication, a POS switch is not required.
Bring your outage procedure to the deployment conversation. Tell us the licensed location, devices, tender methods and workflows you need to preserve. Ask for the current supported scope and an agreed demonstration before activation. Talk with Blackleaf about California POS access.
Frequently asked questions
Is internet loss the same as Metrc downtime?
No. Internet loss can disconnect the register from its POS service and other providers. Metrc downtime can leave the POS online while reporting is unavailable. Test both conditions independently.
Can a dispensary keep selling when Metrc is down?
Only where the implemented workflow and the licensed store’s current outage procedure permit the specific work. Required checks, recordkeeping, restricted operations and reporting obligations still need review. A vendor’s offline label is not blanket permission to continue selling.
Does offline POS mean electronic payments work offline?
No. Payment authorization and settlement depend on the actual provider, device and supported process. A locally saved sale or printed receipt does not prove payment approval. Resolve an uncertain payment before attempting another charge.
Do queued sales report automatically after recovery?
That is a capability to confirm for the implemented version. Require durable saved events, ordered processing, limit-aware retries, duplicate checks, acceptance references and visible exceptions. A restored connection alone does not prove every event was accepted.
What if Metrc accepted a sale but the POS timed out?
Treat the result as uncertain until the existing external record and original references establish what happened. Use the supported lookup and recovery process before another create request. Hold and assign unresolved work rather than guessing.
How should voids and returns reconcile?
Link each correction to the original sale and follow the supported reporting and product-disposition process. An unsent cancellation and a correction to an accepted receipt may require different handling. Tender, inventory and external reporting must each reconcile.
What should nightly package reconciliation compare?
Compare physical counts, POS package activity and Metrc records using the same facility, package, unit and cutoff. Explain pending events, holds, returns, transfers and corrections. Investigate unexplained differences before authorized adjustments.
Does Metrc approval prove Blackleaf’s outage features are released?
Metrc approval and product release are separate. Blackleaf POS, offline checkout and Metrc outage recovery are in production in California. More states are rolling out soon. Confirm operating limits and the supported setup for your store; approval does not establish every jurisdiction or workflow.
Technical and regulatory sources reviewed October 16, 2026. Demonstrations and worksheets are evaluation aids; no outage performance, customer outcome or universal operating permission is claimed.