Tap-to-pay · wallets · Click to Pay
Apple Pay, Google Pay, Click to Pay and EMV contactless cards run on the same orchestration platform as the merchant's online checkout. Partner-delivered terminals and SoftPOS / Tap-to-Phone slot in alongside, all sharing one PCI L1 vault and one reconciliation feed.
Key benefits
Four properties that show up the moment wallet pay-sheets become the default on the checkout instead of an afterthought after inline card entry.
Apple Pay and Google Pay surface on web, in-app and at the terminal. Click to Pay reaches Visa, Mastercard, Amex and Discover cardholders without a wallet install. The merchant integrates once; the buyer recognises every surface.
Wallet handoffs ride scheme tokens; raw PAN never reaches the merchant or the topropay vault on the wallet path. Card-based contactless tokenises into the platform vault as the same shape the wallet handoffs produce.
Contactless EMV uses a single-use cryptogram per transaction; the PAN doesn't transit in the clear. Wallet pay-sheets add device biometric or PIN as a CVM on every authorisation. Both close most of the channel-specific fraud vectors.
An online wallet authorisation and an in-store contactless tap clear through the same routing and reconciliation engine. Refund, recurring, dispute and ledger flows match whichever channel the original sale arrived through.
How contactless solutions clear an authorisation
What happens between the buyer's tap or wallet confirmation and the row in the merchant's general ledger — and where topropay sits inside the chain.
Apple Pay or Google Pay sheet (online or in-app), the EMV contactless card on a terminal, Click to Pay one-tap on the checkout, or SoftPOS Tap-to-Phone on a partner-app-equipped phone.
The wallet or card transmits a scheme token plus a single-use cryptogram. PAN never crosses the merchant boundary; on partner terminals the cryptogram drives the EMV authorisation request.
Online wallet authorisations smart-route across the connected acquirer panel. Card-present (terminal / SoftPOS) authorisations carry over the partner acquirer's switch and inherit their scheme-side certifications.
The vault holds the network token; settlement, refund and dispute events ride the unified reconciliation feed; per-channel and per-method splits available for finance reporting.
Main use cases
Six recurring merchant shapes — DTC checkout, mobile apps, recurring subscriptions, in-store retail, field-services and pop-up events.
Wallet pay-sheets surface above inline card entry on the hosted checkout. Buyers complete in one tap; the merchant lifts conversion without a per-wallet integration.
Apple Pay and Google Pay surface inside the merchant's native app via the standard SDKs; the platform handles the authorisation and vault tokenisation downstream.
First authorisation captured via wallet — the platform vault holds a network token; subsequent recurring charges run server-side without a re-prompt.
Partner-delivered terminals accept Apple Pay, Google Pay and EMV contactless cards out of the box; topropay's orchestration handles the cross-channel vault and reconciliation.
Engineers, couriers and at-home technicians accept tap-to-pay on company phones — no terminal hardware shipped — under the same merchant record as online sales.
Compact terminals or SoftPOS scale up for events and back down afterwards. Reporting tags receipts by event location and channel.
Platform features
Twelve capabilities — wallets, cards, terminal-side flows, vault tokens and the shared back-end. Each applies to every contactless surface the platform exposes.
Surfaced on hosted checkout, embedded fields, native iOS apps and on supported Tap-to-Phone partner terminals.
Same coverage across web, Android apps and partner Tap-to-Phone surfaces.
Scheme-tokenised one-tap on the hosted checkout; cardholders enrolled with the schemes pay in one click.
Card-present contactless accepted at partner terminals; cryptogram-per-transaction; PIN step-up above regional CVM thresholds.
NFC-equipped phones act as PCI MPoC-aligned terminals via partner SoftPOS apps.
Wallet tokens stored in the vault as network tokens; recurring renewals don't fail on card re-issuance.
Frictionless 3DS2 on the card-on-file path; wallet authorisations carry their own CVM in most cases.
Online wallet authorisations score across the connected acquirer panel; soft declines cascade inside the same authorisation.
Token issued at a POS tap is the same vault token used online; refund / recurring crosses channels seamlessly.
Wallet and card-present disputes share the queue; evidence-pack templates per vertical.
Refunds against the vault token with justification, reason codes, actor identity and timestamp logged for audit.
Wallet, card-present and online card receipts in one ledger, tagged by method, channel, acquirer and currency.
Industry relevance
topropay's contactless posture targets licensed merchants across Europe, the UK, APAC and LATAM — DTC and retail wanting wallet pay-sheets on every channel, SaaS and subscription businesses capturing the first authorisation through a wallet, hospitality and field-services running SoftPOS on company phones, and licensed gaming operators where current operating licences exist.
Trust & compliance
One audited environment for the orchestration layer; PCI MPoC and scheme contactless rules inherited from the partner terminal estate.
Ready to make tap the default
A 30-minute contactless review covers wallet pay-sheets across web, app and in-store, SoftPOS for the partner terminals you'd add, Click to Pay enrolment on hosted checkout, and a sandbox to test against before any commercial commitment.
Frequently asked
Definitions, wallet-vs-card distinctions, contactless-fraud mechanics, cross-channel vault and the practicalities of running tap-to-pay everywhere through one platform.
Contactless payment methods for online merchants on topropay include Apple Pay, Google Pay and Click to Pay on the hosted checkout, plus embedded hosted-field equivalents inside the merchant's own checkout. On native apps, Apple Pay and Google Pay surface through the platform SDKs. Buyers complete in one tap; the merchant integrates once.
Contactless payment systems differ from traditional card-entry checkouts in two ways. First, the buyer never types a 16-digit PAN — the wallet or contactless card transmits a scheme token. Second, the CVM (biometric on a device, PIN on a terminal above the limit) is built into the authorisation. The result is higher conversion online and a lower fraud profile.
Contactless payment solutions for in-person merchants pair partner-delivered terminals (countertop, portable, mPOS) with SoftPOS / Tap-to-Phone on supported phones. The merchant gets one terminal estate for a given geography, plus topropay's orchestration handling the cross-channel vault and reconciliation underneath.
Yes. The contactless solutions on the platform are cross-channel from day one — a token issued at a POS tap is the same vault token used online. Refund, recurring renewal, dispute representment and reconciliation all reference that one token regardless of which surface the original sale arrived through.
Online payment merchants adding contactless surfaces enable Apple Pay, Google Pay and Click to Pay through dashboard toggles. The hosted checkout surfaces them automatically; embedded-field integrations expose the wallet sheets via JS hooks. No new acquiring relationship is needed if the merchant already has card acceptance configured on the platform.
Contactless payment fraud is dominated by lost-or-stolen card abuse below the regional contactless limit (where no PIN is required) and wallet-provisioning attacks where an attacker enrolls a stolen credential into a wallet on a device they control. The platform's defences include velocity rules, list management, device-fingerprinting signals into the routing engine, scheme tokenisation (which reduces PAN exposure), and the scheme's own ID&V step on wallet provisioning.
Contactless payment services exposed to developers include the unified authorise endpoint (same as card and bank rail), wallet-specific session helpers (Apple Pay merchant session, Google Pay payment data request), Click to Pay enrolment helpers on the hosted checkout, and signed webhooks for every lifecycle event. The same vault token shape is returned regardless of which contactless surface produced it.
Contactless payment merchants choose hosted vs embedded based on PCI scope and UI control needs. Hosted shrinks the merchant's PCI scope to SAQ A and surfaces wallet pay-sheets out of the box. Embedded keeps the merchant's checkout shell and surfaces the wallet sheets via JS hooks; PCI scope sits at SAQ A-EP. Both reach the same back-end.
Click to Pay is technically a scheme-side wallet (SRC — Secure Remote Commerce) that surfaces one-tap card payment for enrolled cardholders. On topropay it sits inside the contactless / wallet bucket because the buyer's interaction is a single tap rather than a full PAN entry — but the authorisation downstream is a card authorisation on the chosen scheme.
On a recurring subscription, the buyer taps the wallet once at sign-up. The platform vault stores a network token (VTS for Visa, MDES for Mastercard); subsequent renewals charge against the token without re-prompting. If the underlying card is re-issued, the scheme's account updater pushes the new credential — the merchant doesn't see a renewal failure.
Contactless limits are set per region by the schemes and by local regulators. Below the limit, the cardholder typically doesn't provide a PIN; above the limit, the terminal steps up to PIN or device biometric. The platform doesn't override these — partner terminals enforce them per the acquirer's scheme certification.
For web flows, Apple Pay requires the merchant to register a merchant ID and verify domain ownership with Apple — topropay surfaces the platform's payment processing certificate so the merchant doesn't manage that side. Google Pay for web is more lightweight and surfaces directly through the platform's merchant configuration. For native apps, the merchant uses their own Apple / Google developer accounts.
Disputes on contactless transactions follow the same path as any card chargeback for the underlying scheme. The unified dispute queue surfaces the originating authorisation, the network token used, the device or terminal that produced the cryptogram, and an evidence-pack template per dispute reason. For wallet-side disputes, the CVM evidence (biometric / PIN) is included in the representment package.
Contactless reaches every market where the connected acquirer panel covers card acquiring and where Apple Pay / Google Pay are launched by the schemes. Coverage spans EU, UK, APAC and LATAM by default; specific market availability per wallet depends on the scheme's launch status and the partner acquirer's certifications.
Yes. The contactless side scales with the wider platform — the connected acquirer switch capacity dominates over the per-transaction cost of the wallet handshake. Peak-event load (e.g. stadium events, retail flash sales) is sized in advance against forecast volume across the partner acquirer estate.
Related