Custom Self-Service Terminal Requirements: How to Get an Accurate Quote and Avoid Prototype Change Orders

Most overseas B2B inquiries for a self-service terminal begin with a reference image and a screen size: “We need 100 units of a 32-inch payment terminal, please quote.” The supplier then fills every engineering decision — enclosure height, payment module position, software scope, compliance destination — with whatever is cheapest to source that quarter. The buyer receives quotes that are not comparable, and the gap only becomes visible at the prototype stage, when the change order arrives.

A requirements document reverses that default. It is a structured record of what the terminal must do, under what conditions, who owns which layer, and how “done” will be verified. The goal is a document a supplier can price line by line, and a buyer can test against at FAT and SAT. This guide provides a B2B checklist and country-level cases to help you write a custom self-service terminal requirements document that gets accurate quotes the first time.

Step 0: Decide the Sourcing Model Before Writing a Single Line

OEM kiosk requirements and ODM requirements are not the same document with different logos. The sourcing model determines how deep the document must go.

The practical rule: the closer to OEM, the more the document reads like a specification; the closer to modified standard, the more it reads like a difference confirmation plus acceptance conditions. A buyer who writes an OEM-depth document for a modified-standard project wastes weeks; a buyer who writes a two-page difference list for an OEM project hands engineering control to the supplier.

This step should output: sourcing model, responsibility boundary, and a self-assessment of document depth.

Step 1: Define the Commercial Scenario and One Primary User Journey

Commercial terminal design requirements start with deployment context, not cabinet dimensions. A terminal specified for a climate-controlled shopping mall and a terminal specified for a semi-outdoor parking structure in a humid climate share almost no enclosure assumptions, even if both run the same software.

Write the deployment context first

• Indoor, semi-outdoor or full outdoor; operating temperature range and humidity exposure.
• Daily operating hours and peak concurrency (one user at a time, or queueing).
• Cleaning regime and chemicals the front surface will contact.
• Public-vandalism exposure and whether the unit is attended, semi-attended or fully unattended.
• Mounting condition: floor-standing, countertop, wall-mounted, recessed or drive-through.
• Deployment country, site count and whether the first order is a pilot or a batch.

One terminal, one primary journey — plus the failure branches

Each terminal should have one primary task: check-in, ticketing, self-order, payment, dispensing or wayfinding. Write the happy path as a short numbered flow, then write the branches that decide whether the terminal is actually usable in public:

• What the user sees when the network is unavailable.
• What happens when payment is declined or the payment terminal is offline.
• What happens when the printer is out of paper or a scan cannot be read.
• How the session ends, and whether the screen returns to a clean state after abandonment.

This step should output: one-sentence scenario, primary journey, failure-branch list, and key environmental conditions.

Step 2: Hardware Requirements — Modules, Failure States and Equivalents

A hardware table that only lists “32-inch touchscreen, thermal printer, card reader” is not a requirement table. It is a shopping list. Each module needs three pieces of information: normal-state requirement, degraded or failure-state requirement, and verification method.

The second discipline is the compatibility chain. Do not specify a scanner model in isolation. Specify the driver version, operating system build and firmware combination that has been validated together. A peripheral that works on a demo unit with a development OS image can fail on a production image after a single firmware update. The document should ask the supplier to name the validated combination, not just the part number.

This step should output: module table with must/preferred/equivalent rules, failure-state requirement per module, and the validated driver/OS/firmware combination.

Step 3: Software Requirements and Scope Ownership

Software is where the largest expectation gap sits in overseas B2B projects. “Hardware and software” can mean three very different scopes, and the price difference is substantial.

Three software scope tiers

• Hardware plus driver and peripheral integration. The supplier delivers the OS image, drivers, peripheral SDKs and a recovery mechanism. The application is the buyer’s responsibility.
• Hardware plus kiosk runtime. The supplier adds kiosk-mode lockdown, remote management, logging and auto-recovery. The boundary between runtime behavior and application behavior must be written explicitly.
• Hardware plus full application development. Business logic, UI, multilingual behavior, backend integration and acceptance scripts all need a named owner.

Behavior under imperfect conditions

Write the software requirements for the states that public terminals actually encounter, not just the demo path:

• Whether the application auto-starts after a power failure with no attendant present.
• What happens after an application crash — automatic restart, error screen, or unrecoverable hang.
• Whether an expired authentication token leaves the terminal in an unusable state.
• Which transaction types can be queued offline and reconciled later, and which must fail closed.
• Whether a restart returns the terminal to the correct policy and language state.

For US-facing deployments, any camera-based or document-based age or identity check should be specified against NIST-evaluated algorithms, not a vendor’s internal claim. NIST’s age estimation evaluation measures classification against a threshold age and reports error margins; the document should ask for the test result, the threshold used, and the human-fallback rule when confidence is low.

This step should output: software scope tier, runtime behavior requirements, and a deliverables table covering source code, license, update responsibility and test/production account ownership.

Step 4: Interface Requirements — Physical Ports and System Integrations

Interface requirements fail when they stop at the physical connector and never reach the integration contract.

Physical interfaces

Write the count, the purpose and the power budget, not just the connector type: USB ports (version, powered or unpowered, allocated use), serial ports, Ethernet, GPIO or relay outputs if the terminal triggers a gate or locker, and spare capacity for future peripherals. A requirement that says “USB × 4” without saying which are powered and what each is reserved for will be interpreted four different ways by four suppliers.

System integration list

For every external system — POS, ERP, PMS, ticketing platform, payment gateway, identity service — the table should include:

The failure column is not optional. Without it, the prototype phase produces the familiar stalemate: the buyer assumes the supplier tests the API, the supplier assumes the buyer provides a live endpoint, and neither party has agreed on what “integration complete” means.

This step should output: physical interface table, integration table with failure conditions, and joint-debug ownership.

Step 5: Commercial Terminal Design — Enclosure, Branding, Accessibility and Environment

This is the section that carries the commercial terminal design requirement. It is where industrial design decisions collide with accessibility law and public-environment durability.

Accessibility is a dimensional requirement, not a claim

For terminals deployed in the United States, ADA reach ranges apply to operable parts and interactive controls. The working numbers used in US accessibility guidance for self-service terminals include a maximum height of 48 inches (about 1220 mm) above the finished floor for operable touchscreen elements, with reach depth limits, and a recommended display tilt of roughly 15° to 20° to serve both seated and standing users. These are not aesthetic preferences. They determine enclosure height, payment terminal position, card reader angle and the depth of the front approach. Write them as acceptance criteria with a measurement method, not as a footnote that says “ADA compliant.”

For European deployments, the relevant harmonized accessibility standard for ICT is EN 301 549, which addresses both hardware and closed-functionality requirements for self-service terminals and references WCAG for the digital interface. European Accessibility Act timelines and procurement practice mean that self-service terminals are explicitly in scope; the document should name EN 301 549 and the WCAG level required, rather than treating accessibility as a checkbox owned entirely by the supplier.

Form factor, serviceability and environment

• Mounting method and stability: floor-standing with anti-tip fixing, countertop, wall-mounted or recessed.
• Service access: can consumables be replaced without removing the display, and from which side does the service door open?
• Cable routing: accessible from outside or requiring partial disassembly.
• Environmental envelope: operating temperature range, front-panel IP rating, screen brightness for the stated lighting condition (indoor, semi-outdoor, direct sunlight), and cleaning-agent tolerance.
• Privacy and security: shoulder-surfing shield, payment terminal visibility and physical reachability, lock type and tamper detection.

This step should output: form-factor and installation requirements, ADA/EN 301 549 dimensional acceptance criteria, branding and finish specification, environmental envelope, and serviceability/security requirements.

Step 6: Market-Specific Compliance, Payment Certification and Power

Compliance is a project variable, not a universal checkbox. The document should map each target market to the evidence required, the testing owner and the cost owner.

Payment certification has three separate layers

For any unattended terminal that accepts card payments, the buyer must distinguish:

• PCI PTS device approval — the payment device itself has been evaluated under the PCI PIN Transaction Security program.
• EMV Level 1 and Level 2 — physical and kernel interoperability with the card schemes.
• CAT classification — Cardholder Activated Terminal rules for unattended acceptance. CAT levels (CAT 1, CAT 2, CAT 3) carry different CVM and receipt rules; Mastercard’s transaction processing rules, for example, specify that a CAT 2 device must not accept signature or PIN as the CVM, and that a device supporting offline PIN may need dual CAT 1/CAT 2 capability depending on the transaction.

The buyer’s document should ask the supplier to state the end-to-end payment architecture and the CAT level the terminal is designed for, not merely to confirm that a card reader has “PCI certification.” The merchant’s own PCI DSS obligations, privacy notices and local electrical approvals sit with the buyer, not the hardware supplier — putting that boundary in writing prevents a costly assumption later.

What to ask for, per market

This step should output: target-market compliance matrix, payment certification scope (device, EMV, CAT), evidence list and responsibility split.

Step 7: Acceptance Criteria, Milestones and Commercial Terms

Every requirement in the document should be testable before the prototype is built. If a requirement cannot be observed as pass or fail, it does not belong in the acceptance section.

Make requirements verifiable

Gate sequence and change control

Requirements sign-off → design freeze → prototype → FAT (Factory Acceptance Test) → SAT (Site Acceptance Test) → mass-production release → final acceptance. Each gate should name the signatory, the output document and the re-test rule when a change is introduced. The acceptance criteria must be agreed before contract signature; after signature, the buyer loses the leverage to define what “success” means.

Commercial checklist

• Prototype quantity and cost; first-batch MOQ and pilot-to-volume pricing logic.
• NRE and tooling cost ownership, amortization and refund conditions.
• Lead time, Incoterms (EXW/FOB/DDP), packaging and shipping-damage responsibility.
• Warranty period, spare-parts availability, end-of-life and replacement-model commitment.
• Software update support duration and the ownership of production/test accounts.

This step should output: verifiable acceptance table, milestone sign-off matrix, commercial checklist and change-control rule.

Country-Level Cases: What the Document Had to Contain

The cases below are deployment facts reported by operators, integrators and trade press. They are included to show which requirement fields become critical in a given market context, not to endorse a particular supplier or product. Each case is followed by the document field it validates.

Item-Level Requirement Register: The Core Deliverable

The document should end with a register that a supplier can price and a buyer can test. Each row needs enough information to survive the prototype phase without renegotiation.

The “Failure behavior” column is what separates this register from a conventional feature list. It forces both parties to agree, before tooling, on what the terminal does when the happy path does not happen.

Frequently Asked Questions