A reliable architecture separates capture, verification, regulated-system reconciliation, trip execution, receiving, and payment. Each layer owns one decision and passes a clear result to the next.
Layer 1: capture the identifier
The scanner should read barcode, QR, or supported printed identifiers and normalize the result. It should not decide whether the package belongs on the load.
This layer can be upgraded independently as camera and SDK technology improves.
Layer 2: verify the load
The Flower Freight verification API checks the captured package against the expected load/Metrc context and updates the departure gate. This is where mismatch logic belongs.
Separating verification protects the workflow from a scanner that merely recognizes valid-looking text.
Layer 3: execute and reconcile transport
Driver custody, GPS, temperature observations, arrival, incident records, receiver acceptance, and Metrc reconciliation belong to the transport lifecycle.
Each event should be authenticated and tied to the same run.
Layer 4: payment at the defined boundary
AeroPay or another payment rail should be invoked according to the business/payment workflow—such as preauthorization at booking and capture at the approved delivery boundary—not because a barcode was read.
That separation reduces the blast radius of change and makes failures easier to diagnose.
Frequently asked questions
Should the scanner call Metrc directly?
The capture layer should hand the normalized identifier to the platform verification layer, which applies the correct Metrc/load context.
Should a scan trigger payment?
No. Payment belongs to its own defined booking/delivery workflow.
Why separate the layers?
It allows one component to be upgraded or repaired without unnecessarily risking unrelated compliance, transport, or payment functions.
Run the 10-minute transport audit.
Test what your operation can actually produce today: vehicle, driver, GPS, package, custody, receiving and historical transport evidence. No signup required to see your score.