Short Answer
A Norway snus vending prototype cannot be priced responsibly from a feature list alone. A useful quotation has to separate five pieces of work: legal and provider discovery, the can-dispensing proof, BankID or approved age-check integration, certified payment integration, and the pilot-ready cabinet with testing. The buyer also has to identify the registered Norwegian sales operator, intended location, employee-supervision workflow, identity-provider route, and payment acquirer. Without those inputs, a single total is mostly guesswork.
For the 50-100 can concept described in a recent inquiry, the right commercial answer is a stage-based quotation. Price the decisions that can be controlled now. Put third-party services behind explicit assumptions. Do not promise that an unattended tobacco sale is lawful simply because the machine can scan a BankID QR code.
This may sound more cautious than an instant catalogue price. It is also cheaper than discovering after fabrication that the sales model, merchant agreement, payment terminal, or cabinet workflow has to be rebuilt.
What the Customer Is Actually Buying
The brief looks like one machine: a modern cabinet holding 50 to 100 snus cans, a touchscreen, QR-based age verification, contactless payment, automatic dispensing, 4G or Wi-Fi, and remote stock monitoring. Commercially, it is four systems joined by a transaction contract.
- A regulated retail workflow: who is permitted to sell, where the unit stands, how staff supervision works, what customers can see, and what evidence is retained.
- A physical machine: cabinet, locks, product lanes, single-can release, sensors, collection area, service access, power, modem, screen, and terminal mounting.
- A local service stack: approved identity or age result, payment authorization, settlement, refunds, connectivity, and provider support.
- An operating system: product mapping, prices, inventory events, transaction state, alerts, user roles, audit logs, updates, and incident recovery.
The factory can own much of the second and fourth system. The Norwegian operator must own the legal retail model and usually the commercial relationships for identity and payment. A good RFQ says this plainly. Otherwise every supplier fills the gaps differently and the quotations cannot be compared.
The Legal Gate Comes Before the Cost Sheet
Norway’s Directorate of Health says businesses selling tobacco products such as snus must be registered in the Tobacco Sales Register, and each physical sales location is registered separately. The same guidance confirms the under-18 prohibition, the requirement to request identification when age is in doubt, and the ban on visible display of tobacco products. Closed cabinets or containers are given as practical ways to keep products out of sight.
The earlier feasibility review also found that Norwegian rules restrict self-service and require tobacco machines to remain under employee supervision. That means the phrase “fully unattended” is not a harmless design adjective. It changes whether the proposed transaction can proceed at all.
Ask the Norwegian buyer to provide a written operating position before commissioning the integrated prototype. It should describe the legal entity selling the product, the registered location, staff presence, product-display treatment, age-check responsibility, release authority, customer handover, and internal controls. OBO can engineer against an approved workflow. It should not invent the legal workflow on behalf of the operator.
A Five-Stage Prototype Budget
The following structure makes the quotation useful even when some local agreements are still moving. Each stage has a deliverable and a stop point. The project does not have to spend the full hardware budget to discover a fatal dependency.
| Stage | Quoted work | Buyer input | Exit evidence |
|---|---|---|---|
| Feasibility freeze | Requirements review, sales-flow diagram, responsibility map, preliminary layout, risk register | Norwegian legal position, location and supervision description, product list | Signed system boundary and open-item register |
| Mechanical proof | Measured can envelope, lane prototype, one-can singulation, sensor proof, jam and anti-fishing tests | Representative cans from every planned SKU family | Repeatable dispense report and chosen mechanism |
| Integration proof | Identity adapter, payment-terminal interface, transaction state machine, sandbox logs, failure handling | Provider contacts, merchant ownership, sandbox credentials, test rules | Recorded approved and rejected test journeys |
| Integrated prototype | Cabinet, screen, payment mounting, 4G/Wi-Fi, controller, dashboard, concealed inventory, assembly | Brand files, language copy, approved UI constraints, deployment power and network | Factory acceptance test with traceable issues |
| Pilot release | Packaging, shipping support, installation pack, training, monitoring, defect triage, pilot review | Site readiness, local installer, SIM, acquirer activation, operating procedures | Site acceptance and controlled pilot report |
The first two stages can often proceed while provider discussions continue, provided the cabinet is not represented as an approved Norway sales solution. The integrated transaction should wait until the operator can supply the real interfaces and the legal workflow.
Why One Prototype Price Is Misleading
Two machines can look identical in a rendering and carry very different development costs. A screen mock-up using simulated approval is inexpensive. A pilot unit using an approved merchant identity service, certified terminal, traceable refunds, signed software releases, remote diagnostics, and documented failure recovery is a different product.
Separate the quotation into non-recurring engineering, prototype hardware, third-party equipment, external services, logistics, and optional pilot support. This prevents a low headline price from hiding the items the buyer will later discover are excluded.
| Cost bucket | Typical contents | Pricing treatment |
|---|---|---|
| Non-recurring engineering | Industrial design, drawings, mechanism iterations, electronics adaptation, software configuration, test fixtures | One-time, milestone based |
| Prototype materials | Cabinet, screen, controller, modem, locks, sensors, harnesses, can lanes, collection hardware | One prototype bill of materials |
| Local commercial hardware | Certified payment terminal, SIM, local power parts, optional scanner supplied by an approved route | Quoted allowance or buyer supplied |
| Provider and transaction fees | Identity service, merchant onboarding, payment acquiring, data or messaging services | Contracted directly or passed through with evidence |
| Verification and pilot | Factory acceptance, shipping, customs, installation, on-site validation, support window | Separate and location specific |
For early budgeting, ask suppliers to show these buckets rather than forcing everyone into one number. A quote with exclusions is more useful than a suspiciously precise price built on silent assumptions.
Use a Quote Readiness Score
Before asking for a fixed total, score the project on six questions. Give each item 0 when unknown, 1 when a direction exists, and 2 when documentary evidence is available.
- Sales model: Is the exact Norway transaction and employee role documented?
- Product envelope: Are physical samples and dimensional variation available?
- Identity route: Is the operator connected to Stø, BankID, or an approved service route with a named technical contact?
- Payment route: Has the acquirer or PSP confirmed the terminal, country, merchant category, and integration method?
- Site: Are placement, power, connectivity, mounting, service access, and staff coverage known?
- Acceptance: Has the buyer defined what evidence makes the prototype acceptable?
A score of 0-4 supports discovery pricing only. At 5-8, a mechanical proof and provisional integrated budget are reasonable. At 9-12, the supplier can usually freeze a much firmer scope. This is not a legal score or a promise of approval. It is a way to measure quotation uncertainty.
Mechanical Inputs That Change the Price
“Capacity: 50-100 cans” is not enough for a mechanism quote. The supplier needs the outside diameter, total height, lid and base profile, label seams, mass, coefficient-of-friction variation, temperature exposure, and acceptable cosmetic contact. Samples matter because nominal dimensions leave out the troublesome edges.
SKU count matters too. One adjustable lane holding several compatible cans is different from ten independently mapped channels. A gravity escapement, motorized pusher, belt lane, carousel, and elevator each create a different bill of materials and test burden. The related 50-100 can dispensing design guide explains these trade-offs in detail.
The RFQ should also state whether stock must remain completely concealed, whether customers can touch the delivery door, what happens after a jam, and how service staff reconcile a removed can. A cheap release motor becomes expensive when the machine cannot prove whether one can, two cans, or no can moved.
BankID and Stø Scope: Quote the Boundary, Not the Logo
BankID says its app can generate a QR code for an ID check at a checkout or other verification point. The code is valid for 30 seconds or until scanned. Stø AS is the issuer of BankID, and BankID is an electronic identification and signing solution. Those facts show technical capability; they do not grant a vending manufacturer unrestricted access to a generic “BankID age API.”
The buyer should identify the actual product, contracting route, merchant owner, approved use case, sandbox, data fields, retention rules, support channel, and production approval process. Until then, the supplier can quote an adapter interface and a simulated verifier, but not a guaranteed production integration.
Keep three prices separate:
- the provider’s commercial onboarding and transaction charges;
- the machine-side adapter, secure configuration, UI states, and audit events;
- integration testing with approved test identities, expiry, rejection, outage, and replay cases.
The machine should receive only the decision and transaction evidence needed for the approved sale. It should not become an informal identity database. Extra data fields add privacy review, security work, storage controls, access rules, deletion logic, and breach exposure. They also add cost.
Card, NFC, Apple Pay, and Google Pay Are a PSP Workstream
Apple Pay and Google Pay normally ride through a contactless payment terminal and the operator’s acquiring relationship. The cabinet factory can provide the mounting, power, network path, protocol adapter, transaction state handling, and test support. The local PSP or acquirer determines terminal certification, merchant onboarding, settlement, chargebacks, refunds, and production credentials.
The RFQ should name the preferred terminal or ask for two compatible options. It should state whether payment is authorized before identity approval, after approval, or reserved and captured after confirmed dispensing. For a regulated product, the clean design is usually to avoid charging when authorization has expired or release is blocked. Exact sequencing must be agreed with the PSP and legal workflow.
Failure behavior belongs in the price. Include terminal offline, authorization timeout, duplicate callback, customer cancellation, approved payment followed by a jam, uncertain dispensing, reversal failure, and loss of connectivity before the backend receives the final state.
A Realistic Development Timeline
Do not turn the timeline into a single “production lead time.” There are at least three clocks: engineering work, buyer decisions, and third-party approvals. Only the first is controlled mainly by the manufacturer.
| Workstream | Indicative planning window | What commonly stops the clock |
|---|---|---|
| Requirements and feasibility freeze | 1-3 weeks | Unclear operating model, missing samples, no provider owner |
| Mechanical proof and layout | 3-6 weeks | Can variation, double vend, jam recovery, cabinet changes |
| Identity and payment proof | Runs in parallel when access exists | No sandbox, merchant onboarding, unsupported terminal or use case |
| Integrated prototype fabrication | 6-10 weeks after design freeze | Long-lead terminal, screen, custom metalwork, late UI changes |
| Factory acceptance and corrections | 2-4 weeks | Intermittent faults, incomplete failure tests, buyer sign-off delay |
| Shipping, site activation, and pilot | Location dependent | Customs, site readiness, SIM, acquirer activation, local approval |
These are planning windows, not a fixed promise. Some work can overlap. Provider approval cannot be compressed by adding factory labor. A quotation should show the assumptions behind every date and identify which milestones pause when buyer-supplied access is late.
Do Not Offer a Volume Price Too Early
A buyer naturally asks for one prototype price and a lower unit price for larger quantities. Give the production price as a conditional band or a formula until the prototype closes the unknowns. The final unit cost depends on the released bill of materials, cabinet yield, mechanism cycle results, wiring labor, terminal supply model, licenses, packaging, spare-parts kit, warranty reserve, and order quantity.
Prototype labor should not simply be divided across future units. Some engineering disappears from the repeat price; some pilot findings add better sensors, stronger parts, or service access. Freeze volume pricing after the factory acceptance report and before tooling or batch procurement. State how long component prices remain valid and what exchange-rate or third-party changes can reopen the quote.
Build Payment Milestones Around Evidence
Calendar dates are poor payment gates because a project can reach a date without reducing risk. Tie milestones to evidence instead.
| Milestone | Evidence package | Decision |
|---|---|---|
| Scope approval | Signed requirements, responsibility matrix, assumptions and exclusions | Release mechanical proof |
| Mechanism approval | Sample list, dimensional record, cycle video, jam log, dispense counts | Release cabinet detail design |
| Integration approval | Sandbox transaction logs, UI states, timeout and rejection results | Release production interface work |
| Factory acceptance | Serialised test report, open-issue list, manuals, configuration baseline | Approve packing and shipment |
| Site acceptance | Installation record, connectivity, provider activation, operator training | Start controlled pilot |
This approach protects both sides. The buyer sees what has been achieved. The manufacturer is not financing an undefined integration while waiting for a third party to answer an email.
Use a Responsibility Matrix in the RFQ
Many custom-machine disputes start with the sentence “we assumed you would handle that.” Put an owner beside every dependency.
| Item | Likely lead | Required handoff |
|---|---|---|
| Norway legal interpretation and registered sales model | Norwegian operator and adviser | Written approved transaction and supervision flow |
| Can samples and assortment | Buyer | Labelled samples and planned quantities |
| Dispensing mechanism and cabinet | Machine manufacturer | Drawings, prototype, test evidence |
| BankID or Stø commercial route | Norwegian operator | Agreement, contact, sandbox and permitted result |
| Machine identity adapter | Manufacturer or named software partner | Interface specification, secure deployment, logs |
| Acquirer and payment terminal | Operator with PSP | Approved terminal, merchant account, test credentials |
| Dashboard and telemetry | Manufacturer within agreed scope | Role list, event dictionary, retention and alert rules |
| Site, SIM, customs and local installation | Buyer unless quoted otherwise | Ready-site checklist and responsible local contact |
What to Send for a Quotable RFQ
A concise RFQ can still be complete. Send the following as one controlled package, with version numbers rather than scattered chat messages:
- target city, venue type, indoor conditions, employee presence, opening hours, and installation constraints;
- Norwegian selling entity, intended registration status, legal adviser or authority feedback, and proposed supervision workflow;
- physical samples of every can family, plus forecast SKU count and capacity by SKU;
- customer journey from product request through identity, staff authorization, payment, release, collection, receipt, and exception handling;
- BankID or Stø contact, product name, merchant owner, sandbox status, result fields, and known commercial terms;
- PSP, acquirer, terminal preference, Apple Pay and Google Pay expectations, refund owner, and settlement country;
- screen size, languages, neutral product-list constraints, accessibility needs, branding limits, and receipt requirements;
- dashboard users, stock events, sales reports, machine-health alerts, service roles, and data-retention limits;
- prototype destination, shipping term, local importer, installation owner, warranty expectation, spare-parts plan, and pilot duration;
- acceptance tests, sample size, pass thresholds, documents, training, source-code or API ownership expectations, and change-control process.
Do not wait for every answer before contacting a manufacturer. Mark unknowns honestly. The supplier can then quote discovery where discovery is needed instead of disguising uncertainty inside a contingency.
How OBO Would Answer the Seven Buyer Questions
Can the machine be customized? The cabinet, 50-100 can storage, individual dispensing, touchscreen, connectivity, remote monitoring, and controlled release can be engineered as a custom project.
Can BankID or Stø be integrated? The machine can support a documented approved interface. Production integration is conditional on the Norwegian operator obtaining the suitable commercial and legal route, provider approval, and test access.
Can card and NFC payment be integrated? Yes, through a certified terminal and a PSP/acquirer that supports the Norwegian merchant. Apple Pay and Google Pay availability follows that approved contactless route.
Can one supplier deliver hardware and software? OBO can coordinate cabinet, mechanism, controller, touchscreen workflow, telemetry, and defined adapters. BankID/Stø, acquiring, legal approval, telecom, and local site obligations remain named external dependencies.
What is the prototype price? A fixed total should follow the feasibility freeze and sample review. Before that, request staged prices with the five cost buckets above.
What is the batch price? Provide a provisional quantity ladder, then confirm it after the accepted prototype establishes the BOM, labor, failure rate, licenses, packaging, and warranty assumptions.
How long will development take? Plan the manufacturer-controlled work in stages and show provider approval as a separate clock. The indicative windows above become firm only after their inputs are available.
Sources and Scope
- Norwegian Directorate of Health guidance on tobacco sales, including registration, age, display, and sales-control requirements.
- BankID guidance for using the ID card QR code, including its short validity window.
- BankID personal agreement, identifying Stø AS as issuer and describing BankID as an electronic identification and signing solution.
This article is a project-scoping guide, not Norwegian legal advice, a BankID product approval, or a binding quotation. The operator should confirm the exact product, location, sales journey, and contracts with the relevant Norwegian parties.
Related Custom Vending Guides
- Norway snus vending compliance and BankID guide
- Snus can dispensing design for 50-100 cans
- Custom vending machine development cost
- Vending software, payment API, and dashboard cost
- Custom vending software integration checklist
- Prototype testing before mass production
- Custom vending compliance matrix
- Smart vending machine data privacy questions
Dashboard development should be quoted as an event, alert, role, retention, and acceptance-test scope rather than as a generic cloud checkbox. The Norway snus vending monitoring specification shows what the prototype must report and how payment, age-check, and delivery exceptions should reconcile.
Request a Stage-Based Prototype Review
Send the can samples, capacity by SKU, proposed Norway sales workflow, site description, provider contacts, payment route, dashboard needs, and acceptance criteria. OBO can turn that package into a staged technical proposal showing what can be quoted now, what depends on third-party approval, and what evidence is required before the next payment milestone.
Request a Quote
Privacy respected. No spam. Ever.
