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.

Vending terminal · A4 · BR-2

Selection

Espresso · double

€ 2,40

Tap your card or phone

Visa · Mastercard · Amex · Apple Pay · Google Pay

routed: topropay PCI L1 vault
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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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. 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. 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. 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. 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. 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. 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.