In-person payments are card-present transactions: the customer is physically at your location and taps, inserts, or swipes their card or mobile wallet at a Priority terminal.

You accept them with the Priority Terminal API. Your software sends a transaction to a Priority-managed terminal, the terminal captures the card and runs authorization, and you poll for the result and retrieve the final payment record. Priority handles all communication with the device, so you never integrate against a terminal vendor's SDK or touch raw card data.

Every in-person transaction settles to the same merchant account, gateway, and reporting as your online payments, so reconciliation stays unified across all channels.

---

How it works

A terminal transaction always follows the same four steps:

1. Retrieve terminals — list the terminals registered to your merchant account and pick an enabled one.
2. Create a terminal transaction — send the amount and type to the terminal; it prompts the customer to pay.
3. Poll for status — poll until the transaction reaches a final state (approved, failed, or canceled).
4. Retrieve the transaction — fetch the authoritative payment record from the Checkout API.

See Priority Terminal API for the full request and response reference.

---

Before you begin

---

Real-world scenarios

Real-world in-person deployments grouped by vertical. Each scenario shows the business context, the hardware choice, the transaction pattern on the Priority Terminal API, and the configuration to lock in with your PCE team before ordering equipment.

Retail & quick service

Retail counter — single-tap sale

Business context. A specialty retailer (apparel, electronics, home goods) takes payment at a fixed checkout. Staff scans items in the POS, tenders to the terminal, and the customer taps, dips, or swipes. Throughput per lane matters more than custom UI.

Hardware. Dejavoo Z8 (countertop, Ethernet or Wi-Fi). Supports EMV chip, NFC contactless (Apple Pay / Google Pay), and magstripe fallback.

Transaction pattern. Sale (type: "Sale" — authorize and capture in one step). No tip flow, no open tab.

flowchart LR
    A([POS<br/>scans items]) --> B([POS calls<br/>Priority Terminal API])
    B --> C([Terminal prompts<br/>customer to pay])
    C --> D([Card captured<br/>EMV / NFC / swipe])
    D --> E([Auth + capture<br/>in one step])
    E --> F([Receipt printed<br/>POS updated])

Quick-service restaurant — tip on terminal

Business context. A coffee shop or fast-casual brand takes payment at the counter and wants the customer to choose a tip on the terminal screen before approval. Total throughput matters; tab management does not.

Hardware. Dejavoo countertop or wireless — whatever fits the counter footprint.

Transaction pattern. Sale with on-terminal tip prompt. Your POS sends the subtotal; the terminal prompts the customer for a tip; the captured amount includes the tip.

flowchart LR
    A([POS sends<br/>subtotal]) --> B([Terminal shows<br/>tip prompt])
    B --> C([Customer selects<br/>tip amount])
    C --> D([Card captured])
    D --> E([Auth + capture<br/>subtotal + tip])
    E --> F([POS receives<br/>final total])

Full-service restaurant — open tab, pre-auth, capture with tip

Business context. A sit-down restaurant opens a tab when the guest is seated, authorizes the card at the start of service (or when the check is presented), and captures the final amount including tip after the guest signs.

Hardware. Wireless Dejavoo so the server can take payment at the table.

Transaction pattern. Pre-authorization (type: "Authorization") then capture the final amount including tip. See Authorization and Capture.

flowchart LR
    A([Server taps<br/>'Pay' on POS]) --> B([Pre-auth on<br/>wireless terminal])
    B --> C([Tab open with<br/>auth on card])
    C --> D([Guest adds tip,<br/>signs receipt])
    D --> E([POS sends capture<br/>with final amount])
    E --> F([Auth converted<br/>to settled sale])

Mobile & on-site

Field service — payment on completion

Business context. A field technician (HVAC, locksmith, mobile auto repair, lawn care) completes service at the customer's location and collects payment on the spot. The merchant's mobile app drives the workflow; the terminal travels with the technician.

Hardware. Wireless Dejavoo (Wi-Fi + cellular failover where available). The AnywhereCommerce Nomad (WP3s) also fits this profile — see Supported Terminal Devices.

Transaction pattern. Sale. The mobile app pushes the job total to the terminal; the technician hands the terminal to the customer for a tap or chip.

flowchart LR
    A([Technician<br/>completes job]) --> B([Mobile app sends<br/>total to terminal])
    B --> C([Customer taps<br/>or dips card])
    C --> D([Auth + capture])
    D --> E([Mobile app marks<br/>job paid])
    E --> F([Receipt emailed<br/>or printed])

Healthcare — co-pay at point of care

Business context. A medical practice, dental office, or veterinary clinic collects co-pays, deductibles, and service fees at check-in or check-out. Patients want a written receipt; staff need clean reconciliation to the practice management system.

Hardware. Dejavoo countertop at the front desk.

Transaction pattern. Sale. Optionally store the card on file for recurring service plans (handled separately via Card Vaulting).

flowchart LR
    A([PMS shows<br/>amount due]) --> B([Staff initiates<br/>payment from PMS])
    B --> C([Terminal prompts<br/>patient])
    C --> D([Tap, dip, or swipe])
    D --> E([Auth + capture])
    E --> F([PMS updates<br/>patient ledger])

Unattended & multi-channel

Self-service kiosk

Business context. Parking, ticketing, vending, EV charging, laundromats — the customer completes the entire transaction without staff. The kiosk owns the screen and the cash-out flow.

Hardware. Kiosk-mounted terminal on the Priority Terminal API.

Transaction pattern. Sale, usually with strict timeout handling and unattended-mode flags set at file build.

flowchart LR
    A([Customer selects<br/>service on kiosk]) --> B([Kiosk app initiates<br/>payment])
    B --> C([Device prompts<br/>tap or insert])
    C --> D([Auth + capture])
    D --> E([Kiosk dispenses<br/>good or service])
    E --> F([Receipt printed<br/>or emailed])

Omnichannel — in-person + online under one MID

Business context. A merchant sells in-store, on the web, and in-app. Marketing wants one customer view; finance wants one settlement file; ops wants one chargeback queue.

Hardware. Any supported in-person device for the physical lanes, plus your existing online integration for e-commerce and in-app.

Transaction pattern. Priority Terminal API for the in-person lanes plus online card-not-present sales — all under the same MID, reporting, and dispute pipeline.

flowchart LR
    A([In-store<br/>terminal sale]) --> Z([Single MID])
    B([Online<br/>checkout]) --> Z
    C([In-app<br/>payment]) --> Z
    Z --> Y([Unified<br/>settlement])
    Z --> X([Unified<br/>reporting])
    Z --> W([Unified<br/>disputes])

Scenario-to-setup quick reference

---

Where to go next