Cannabis POS Integrations: How Payments Should Connect to the Register

The short answer

A cannabis point-of-sale integration should do three things: send the exact basket total to the payment device, return an authorisation the register can attach to the ticket, and write a tender record that reconciles against both the settlement report and the state traceability system. Anything less turns every closing shift into manual detective work.

Integration depth matters more than brand names. A payment product that only sits beside the register, with staff keying totals by hand, will produce mismatches at volume no matter how good the hardware looks.

Because dispensary transactions often mix cash, PIN debit and account-funded tenders in the same shift, the integration also needs to keep each tender type distinct through the whole chain, from ticket to settlement to traceability upload, rather than collapsing them into a single generic sale figure that someone has to unpick by hand later.

Three levels of integration

Most setups fall into one of three tiers, and the tier determines your reconciliation workload.

• Standalone: staff key the amount into a separate device. Fastest to deploy, highest error and shrink risk.
• Semi-integrated: the register sends the amount to the device and receives an approval, while sensitive card data stays out of the POS.
• Fully integrated: authorisation, tender type, tip or rounding, refund and void all flow back into the POS record automatically.

What to test before go-live

Run the awkward cases in a live-but-controlled session rather than discovering them on a Saturday. Split tenders, partial approvals, refunds after settlement, a void mid-transaction, a network drop at the device, and a queue of customers during a promotion all behave differently across products.

Also test the end of day. Close the register, pull the settlement report and reconcile against traceability. If the three numbers do not agree on day one, they will not agree in month three.

Document the results of this testing session in writing, including which scenarios passed and which required a workaround, and keep that record alongside the vendor contract. When a reconciliation gap appears months later, this record tells you quickly whether it is a new problem or one you already flagged and accepted at go-live.

Questions for your POS and payments vendors

Vendors often blame each other when a reconciliation gap appears, so establish ownership before you sign. Ask which party owns the integration, how it is versioned, and what happens to your transaction history if either relationship ends.

• Who supports the integration when the register and the settlement report disagree?
• Does the integration survive a POS software update, and who tests that?
• Can you export full transaction history in a usable format on exit?

Staff training and counter workflow

The best integration still fails if budtenders do not know the correct sequence for split tenders, refunds and voids. Build a short written procedure that covers the three or four situations that come up daily, and walk every new hire through it on a live terminal before their first shift on the floor.

Pay particular attention to refunds and voids, because these are the transactions most likely to be entered incorrectly under time pressure, and incorrect entries are exactly what creates the reconciliation gaps that surface weeks later during a review.

• A one-page cheat sheet at every register for split tenders and refunds.
• A named manager who can override or void a transaction, with a log of every override.
• A short retraining session whenever the POS or payment device software changes.

Multi-location reconciliation

Operators running more than one store often discover that each location's integration was configured slightly differently, by different installers, at different times. That inconsistency is invisible until someone tries to build a single reconciliation report across locations and finds the tender categories do not line up.

Standardise the configuration before you standardise the reporting. Confirm every location uses the same tender type names, the same descriptor format and the same settlement cut-off time, then build the consolidated report on top of that consistent base rather than trying to normalise mismatched data after the fact.

Assign one person the job of auditing a sample of transactions from every location each month against the consolidated report, rather than assuming a system that reconciles correctly for the flagship store behaves the same way everywhere. New locations, in particular, deserve a full manual reconciliation for the first several weeks after opening.