Cashless payment
Cashless payment, from the vending machine to the web checkout.
topropay's unified API surfaces cashless payment across every merchant surface — tap-to-pay terminals on vending machines, kiosks at the airport, in-store POS, mobile-app checkouts and web carts. One authorise endpoint, one webhook stream, one reconciliation feed.
Selection
Espresso · double
€ 2,40
Tap your card or phone
Visa · Mastercard · Amex · Apple Pay · Google Pay
- Tap
- contactless card & wallet
- QR
- buyer-presented and merchant-presented
- API
- same surface online and unattended
- 1 ledger
- across every cashless rail
Key benefits
Why a cashless payment system on one orchestration layer wins on every surface
Four outcomes that show up once vending, kiosk, in-store and online traffic all run through the same platform — instead of a different stack per surface.
- 01
One cashless payment system for every surface
Vending-machine terminals, in-store tills, kiosks, mobile-app checkouts and web carts all call the same /v1/payments endpoint. The merchant doesn't operate a different stack per surface; the platform absorbs the per-surface plumbing.
- 02
Contactless, wallet, QR and card-on-file out of the box
Tap-to-pay (Visa contactless, Mastercard contactless), Apple Pay, Google Pay, Samsung Pay, regional wallets, QR codes (buyer-presented and merchant-presented) and saved-card flows all surface as method values on the same authorise call.
- 03
Unattended-aware routing for vending and kiosks
Vending and kiosk traffic carries distinct MIT / CIT flags and lower per-transaction tickets. The routing engine treats unattended segments as their own policy bucket — acquirers with the right vending appetite, cost-weighted by default, retry windows tuned to short-lived sessions.
- 04
One reconciliation feed across vending, in-store and online
Settlements, fees and refunds from every cashless rail and every merchant location land in one ledger. A merchant running 200 vending machines plus a web store closes the month from one export — not a CSV per fleet zone.
How it works
From a buyer tap to a normalised settlement row
Five stages between a contactless tap on a vending terminal and the settlement landing in the merchant's ledger — most of them under a second.
- 01
Install the terminal SDK or call the REST API
Vending-machine and kiosk terminals integrate via the device SDK; web and mobile call the same REST API the platform exposes for online traffic. The auth model and webhook contract are identical.
- 02
Buyer taps, scans or selects
The buyer taps a card or phone on the contactless reader, scans the merchant-presented QR, or picks a saved card on the merchant's app. Each method maps to the same authorise endpoint with a different `method` value.
- 03
Authorise via routing engine
topropay's routing engine scores the authorisation across the connected acquirer panel — for unattended segments, against an appetite-aware subset. Decision in under 200ms; cascade absorbs soft declines.
- 04
Vend, dispense or ship
On `authorised`, the terminal triggers the dispensing motor, the till opens, or the order ships. On `declined`, the buyer sees a normalised reject screen with a single retry CTA — no per-provider error code.
- 05
Settle and reconcile
Settlements roll into one ledger across vending fleets, in-store estates and online traffic. Per-location, per-machine and per-method analytics are exposed in the dashboard for operations.
Main use cases
Where vending cashless payment systems meet the rest of the platform
Six merchant shapes that share the same authorise endpoint but stress it differently — from vending and EV through to web checkouts.
- Vending
Vending machines and unattended retail
Cashless payment systems for vending machines on topropay support contactless tap, Apple Pay, Google Pay and (where the terminal hardware supports it) QR. The terminal SDK runs on common embedded payment modules; the back-end is the same one your web store uses.
- Kiosks
Self-service kiosks and ticketing
Airport, transit and parking kiosks process cashless authorisations with the same primitives as vending. Session retries and low-amount tap thresholds are tuned for the unattended segment from the dashboard.
- Retail
In-store retail terminals
Attended POS terminals call the same authorise endpoint as vending; the only difference is the CIT/MIT flag and the cashier-side flow. Refunds, voids and returns share the unified API.
- EV
EV charging stations
EV charge points use cashless payment with a pre-authorisation (covering the maximum likely charge), final capture on plug-out, and a signed webhook telling the back-end exactly how much energy was delivered.
- Transit
Open-loop transit and ticket gates
Open-loop tap-to-pay on gates and turnstiles processes cashless authorisations at scale with aggregated daily-capture flows; the orchestration layer keeps the per-tap latency under the transit SLA.
- Online
Web and mobile-app checkouts
The same cashless payment solution that drives unattended also drives web carts and mobile-app checkouts. Vault tokens identify customers across surfaces — the buyer who tapped at the kiosk is the same record as the one who paid online.
Platform features
Capabilities behind the cashless payment solution
What the platform actually ships for cashless — the API surface, the terminal SDK and the orchestration primitives shared with web and mobile traffic.
-
Unified API
One REST surface for vending terminals, kiosks, in-store POS, mobile apps and web carts.
-
Contactless rails
Visa contactless, Mastercard contactless, Amex contactless and regional schemes routed through certified acquirers.
-
Wallet pay sheets
Apple Pay, Google Pay, Samsung Pay and regional wallets — same authorise call, different `method`.
-
QR (merchant- and buyer-presented)
Dynamic QR per authorisation; PIX, Bizum, Brazilian retail QR and Asian QR rails supported via partner gateways.
-
Unattended routing policies
Per-segment routing weights for vending and kiosk traffic, acquirers tuned for unattended appetite.
-
PCI DSS Level 1 vault
Card data captures into the vault before it touches the merchant's terminal stack or origin.
-
Low-amount tap thresholds
Configurable per-market low-amount thresholds (LVT) and offline-data-authentication (ODA) tuning where the scheme supports it.
-
Pre-auth & final capture
Pre-authorisation flows for EV charging, parking and other variable-amount unattended sessions; deterministic final capture on session close.
-
Operator portal
One dashboard for vending fleet, in-store estate and online — authorisations, refunds, disputes, chargebacks.
-
Telemetry-ready webhooks
Signed events into your IoT / telemetry stack — per-machine authorisations, per-location settlements, per-fleet rollups.
-
Offline-resilient terminal SDK
Terminal SDK supports brief offline windows with store-and-forward; reconciliation surfaces the offline batch when the link returns.
-
Sandbox parity
Sandbox tenant supports the full vending / kiosk flow — including simulated tap, decline reasons, pre-auth / final capture and webhook replay.
Trust & compliance
Compliance posture across attended and unattended surfaces
PCI DSS posture from the platform, PCI PTS-listed terminal hardware, scheme CVM rules honoured on tap, signed events all the way to the reconciliation feed.
- PCI DSS Level 1
- Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture across attended and unattended surfaces.
- PCI PTS / scheme-listed terminals
- Vending and kiosk terminals certified to PCI PTS where the scheme requires; topropay's terminal SDK runs on listed hardware only.
- SCA & 3DS2
- Selective authentication on the authorisation path for online; contactless tap relies on the scheme's CVM rules under unattended thresholds.
- Signed webhooks
- Replay-safe webhook delivery with HMAC signatures for terminal events, settlement events and chargebacks.
- Data residency
- Regional data-residency options for merchants under regulators that require it; per-region default residency for EU vending estates.
- Licensed verticals only
- Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of surface.
Ready to deploy
Unify cashless payment across every surface you operate.
A 30-minute unattended review covers the terminal hardware compatible with the SDK, the routing policy for your vending or kiosk fleet, and a sandbox to test against before any commercial commitment.
Frequently asked
Buyer questions about cashless payment on topropay
Questions buyers ask before committing — terminal compatibility, vending fleets, EV charging pre-auth, offline-tap windows, refunds and sandbox parity.
- 01
What does cashless payment cover on topropay?
Cashless payment on topropay covers every non-cash rail the platform exposes — contactless cards, wallets, QR, card-on-file, account-to-account, BNPL and (via partner gateways) crypto. Whether the buyer taps at a vending machine, scans a QR at a kiosk or pays online, the back-end is the same orchestration layer.
- 02
How does a cashless payment system on topropay differ from a single-provider terminal?
A single-provider terminal pins the merchant to one acquirer's appetite and one rate card. topropay's cashless payment system routes authorisations across the connected acquirer panel — including ones tuned for unattended traffic — and consolidates settlement, fees, refunds and chargebacks into one ledger across every machine and every web channel.
- 03
What's involved in deploying cashless payment systems for vending machines?
Cashless payment systems for vending machines on topropay are typically: a scheme-certified embedded payment module (the terminal hardware) running the platform's terminal SDK, a network connection (4G/LTE or Wi-Fi), and the merchant's back-end consuming the same webhook events as the rest of their stack. Onboarding is one contract for the whole fleet — not one per machine.
- 04
Are vending cashless payment systems different from in-store POS in terms of the API?
Vending cashless payment systems share the same authorise endpoint as in-store POS — the difference is the MIT/CIT flag, the unattended-segment routing policy, and the absence of an attendant (which affects scheme CVM rules under low-amount thresholds). From the merchant's back-end, both surfaces emit the same webhook event shape.
- 05
Is the cashless payment solution suitable for high-volume vending fleets?
Yes — the cashless payment solution is sized for fleets in the thousands of machines. Per-machine authorisation throughput, per-fleet settlement rollup and per-location analytics are first-class concerns; the operator dashboard exposes fleet-level views alongside the standard merchant-level ones.
- 06
Does the platform support contactless tap at vending machines?
Yes. Contactless tap (Visa, Mastercard, Amex contactless) and wallet tap (Apple Pay, Google Pay, Samsung Pay) are first-class — they map to the same `method` field on the authorise endpoint. The terminal SDK handles the contactless EMV flow; the back-end sees a normalised tap event.
- 07
What about QR codes at the vending machine?
QR is supported where the terminal hardware can display a screen (or the cabinet has a sticker for a static QR plus a per-machine identifier). Dynamic QR uses the same authorise endpoint with `method: qr_pix` / `qr_bizum` / equivalent per market.
- 08
Can a vending machine accept stored-credentials or saved-card payments?
Yes — if the operator runs a customer-facing app where the buyer authenticates and pre-loads a card, the vending machine can charge that vault token on a tap-to-vend flow. The cashless payment surface and the customer-app surface share the same vault.
- 09
How are vending refunds handled?
Vending refunds are merchant-initiated via the same refund endpoint as web — typically triggered by an operator from the dashboard or programmatically when the machine reports a failed dispense. Partial refunds and full reversals are supported; the buyer's bank account or wallet receives the refund inside the scheme's normal timeline.
- 10
What's the typical latency at a vending-machine tap?
End-to-end latency from card tap to 'authorised' on the terminal is typically well under a second on a healthy 4G or Wi-Fi link, with the routing decision in under 200ms. The contactless EMV flow itself is the dominant component; topropay's back-end adds a small fraction on top.
- 11
How does the platform handle offline vending authorisations?
The terminal SDK supports brief offline windows via store-and-forward where the scheme permits it (typically low-amount taps under LVT thresholds). Stored authorisations forward to topropay when the link returns; the reconciliation feed surfaces the offline batch with the original tap timestamp.
- 12
Are EV charging stations supported under the cashless payment solution?
Yes. EV charging uses the same cashless payment surface with a pre-auth / final-capture pattern: pre-auth at plug-in for the maximum likely amount, final capture at plug-out for the actual energy delivered. The driver sees one tap; the merchant's CPO back-end sees normalised pre-auth and capture events.
- 13
What's the relationship between cashless payment and the rest of topropay's catalogue?
Cashless payment is a surface-level framing — every cashless rail topropay exposes (contactless, wallet, QR, card-on-file) lives inside the wider payment-services catalogue alongside ACH, crypto, subscriber and facilitation services. A merchant running cashless terminals can turn on the other categories from the same dashboard.
- 14
Can I migrate from an existing vending payment provider without a full hardware swap?
Often yes — where the existing vending terminal hardware is scheme-certified and supports a swappable payment module, topropay's terminal SDK can run on that hardware. A full hardware swap is only needed when the existing module is locked to a specific provider's firmware. The integration team flags the relevant case during onboarding.
- 15
Is sandbox parity strong enough to test a vending integration before going live?
Yes — the sandbox simulates the full vending flow: tap-on-terminal authorisation, decline reason codes, pre-auth and final capture for EV-style sessions, webhook replay and offline-batch behaviour. The error model and event shape are identical to production.
Related
Related on the topropay platform
- Catalogue Payment services catalogue How cashless surfaces alongside ACH, crypto, facilitation and subscriber services in the wider catalogue.
- Acceptance Accept online payment, MID optional The online side of acceptance — same authorise endpoint, different surface.
- Surface Payment page on the website The hosted-checkout surface that mirrors the vending tap on the web.
- API Web payment systems on one API The web payment API that vending terminals and kiosks also call.
- Aggregation Payment aggregator overview The aggregation pattern behind multi-acquirer routing for unattended traffic.
- Methods International payment methods Method coverage across markets — including the wallets and QR rails surfaced on vending terminals.