Point-of-sale and ordering
Every order moves from entry to pickup without stallingTerminals, payment devices, printers, kitchen or service displays, accounts, software, segmented networks, internet, local services, power, vendor support, and fallback procedures, connected end to end.
What Point-of-sale and ordering includes
The workflow may span attended or self-service ordering, card-present payment, receipt and label printing, kitchen or production routing, pickup displays, drive-through, inventory, loyalty, online aggregators, tax, identity, and reporting. Device count alone does not reveal these dependencies.
Payment scope and compliance are owned by the merchant and its payment partners. Network segmentation can help define boundaries but must be designed, validated, maintained, and reviewed within the organization’s PCI DSS program.
Question to answer before designWhich dependency can stop ordering, payment, routing, preparation, pickup, or reporting, and what is the approved fallback for each failure?
This service may fit when:
- Intermittent terminals, printers, kitchen displays, or payment devices stop service
- Guest, staff, payment, delivery, media, and operations traffic share an undocumented network
- A platform conversion has no staged test, rollback, or after-hours cutover plan
- Store openings rely on multiple vendors without a single dependency and responsibility map
What the system includes
A complete scope covers each part below and the connections between them.
Order
Terminal, kiosk, web, mobile, service desk, menu or queue input
Pay and authorize
Payment device, processor path, identity, role, protected data boundary
Route and fulfill
Printer, kitchen display, workstation, pickup display, inventory or production
Operate
Network, power, internet, local service, monitoring, support, fallback and reporting
How site information becomes a tested project
A complete project record connects the conditions found on site, the design decisions made from them, and the tests and closeout documents delivered afterward.
What we confirm before design
- Order types, payment methods, lane or station count, throughput, and operating hours
- Device, printer, display, kitchen, pickup, inventory, loyalty, tax, and delivery integrations
- Payment provider, PCI responsibilities, segmentation, remote access, and account ownership
What those findings determine
- Platform: Evaluate outage behavior, device support, integrations, data ownership, licensing, and administration.
- Payment: The merchant and payment partners determine validated solution and PCI scope.
- Network: Segmentation must be validated and maintained; a VLAN name is not sufficient evidence.
What you should receive
- Transaction and dependency map
- Lane, endpoint, network, power, and integration design
- Payment-scope assumptions and vendor responsibility matrix
The exact inputs, decisions, and acceptance records depend on the site and signed scope.
Project stagesSurvey through closeoutView details
How the work moves from survey to closeout
Each stage should produce the records and test results needed before the next stage begins.
- 01
Trace the transaction
Follow representative orders through entry, payment, routing, production or picking, status, handoff, refund, close, and reporting; record every device, service, account, and vendor.
EvidenceTransaction journey, device and dependency inventory, data-flow notes, failure history, and vendor responsibility map. - 02
Design boundaries and fallback
Define network segments, ports and services, device placement, power, internet or local dependencies, user roles, offline behavior, support ownership, migration, and rollback.
EvidencePhysical and logical design, payment-scope assumptions, lane schedule, fallback matrix, cutover plan, and responsibility chart. - 03
Stage and cut over
Bench devices, enroll and update endpoints, label connections, validate vendor services, pilot representative transactions, back up configuration, and execute the approved window.
EvidenceStaging checklist, labeled endpoints, configuration record, successful pilot transactions, change log, and rollback readiness. - 04
Prove the whole shift
Test sale, payment, print, routing, status, refund or void as authorized, close, reporting, network separation, failover or offline process, recovery, and operator handoff.
EvidenceAccepted transaction set without real card data, segmentation test record, device-state evidence, recovery results, and shift quick guide.
Design choicesCompare the available approachesView details
How to choose the right approach
The right choice depends on the site, application, operating risk, and acceptance requirements. More equipment does not automatically improve the system.
What we need to know
- Order types, payment methods, lane or station count, throughput, and operating hours
- Device, printer, display, kitchen, pickup, inventory, loyalty, tax, and delivery integrations
- Payment provider, PCI responsibilities, segmentation, remote access, and account ownership
- Internet, local services, power, UPS, cabling, wireless, and environmental conditions
- Opening or cutover window, training, fallback, rollback, vendor contacts, and acceptance transactions
What you should receive
- Transaction and dependency map
- Lane, endpoint, network, power, and integration design
- Payment-scope assumptions and vendor responsibility matrix
- Staging, cutover, rollback, transaction, separation, and recovery evidence
- Labeled asset list, operator quick guide, and support escalation map
When this service makes sense
- Restaurants, retail, hospitality, service desks, pharmacies, and ticketing operations
- New openings, remodels, acquisitions, and platform conversions
- Sites that need defined payment and operational network boundaries
- Multi-site teams building a repeatable lane or counter standard
What we verify first
- GHT does not determine PCI DSS compliance; the merchant, acquiring bank, payment brands, processors, and qualified assessors define applicable obligations
- Offline payment, store-and-forward, failover, and refund behavior are platform- and provider-specific and carry financial risk
- Electrical, mounting, food-area, drive-through, and accessibility work can require separate coordination
- Vendor updates, certificates, accounts, licenses, and API changes can affect the transaction path after closeout
Site contextSee where this work is usedView details
How site conditions change the design
Occupancy, operating hours, user activity, regulation, weather, construction, and access can change the design.
What people usually ask
Does putting POS devices on a separate VLAN make the site PCI compliant?
No. Segmentation may affect scope only when it is correctly designed, implemented, validated, and maintained within the merchant’s complete PCI program.
Can POS run on Wi-Fi?
Some supported endpoints can, but radio coverage, interference, roaming, security, device support, power, outage behavior, and payment-provider requirements must be validated. Fixed endpoints often benefit from wired connections.
What should a cutover test include?
Representative sale, payment, decline, receipt, routing, modifier, status, refund or void as authorized, close, reporting, integration, network separation, fallback, recovery, and support escalation.
Standards and referencesReview the source materialView details
Sources used for this guide
These references inform the guide. The adopted code, engineer of record, authority having jurisdiction, manufacturer instructions, and signed agreement control the project.
Explains PCI DSS as a baseline of technical and operational requirements for entities that store, process, transmit, or can affect payment account data.
Open reference ↗PCI Security Standards Council · reviewed 2026-08-20Point-to-Point EncryptionDefines the P2PE program and how validated solutions protect account data from capture to a secure decryption environment.
Open reference ↗PCI Security Standards Council · reviewed 2026-08-20Guidance for PCI DSS Scoping and Network SegmentationExplains scoping and segmentation principles and cautions that segmentation is not a substitute for a complete security approach.
Open reference ↗