Technology · Contactless payments
The reader can be
the phone.
A valet already carries a connected screen, camera, credential, and communication tool. On supported devices and in supported countries, that same phone can accept contactless cards and wallets without a separate reader at the stand.
The shift
Optional hardware changes deployment, not payment discipline.
Removing a dedicated reader reduces charging cables, pairing, handoffs, inventory, and the chance that payment hardware is somewhere other than the curb. It also makes phone eligibility and connectivity part of the payments plan.
As of August 23, 2026, Stripe documents Tap to Pay for compatible iPhone and Android devices, with country, operating-system, security, and device constraints that vary by platform and can change.
The trade
One less device, a different readiness checklist
What disappears and what remains
Dedicated reader
SEPARATE DEVICE- Another asset to buy, charge, pair, and assign
- Purpose-built payment hardware
- Can preserve a separate operational fallback
Tap to Pay
FIELD PHONE- No additional contactless reader at the stand
- Payment stays in the active valet workflow
- Eligibility follows device, OS, country, and security rules
Qualify the fleet before rollout
Device
Supported hardware
Confirm each deployed model, NFC capability, and platform-specific minimums rather than approving a phone family by name.
Software
Current secure OS
Beta releases, old security updates, rooted devices, or altered bootloaders can make an otherwise capable phone ineligible.
Market
Country and payment methods
Availability and cardholder verification behavior differ by country, issuer, and card method.
Network
Payment connectivity
Do not infer offline acceptance from offline check-in. Stripe's Tap to Pay requirements and payment flows have their own connectivity rules.
→Primary source: Stripe Tap to Pay documentation, reviewed August 23, 2026. Recheck before purchasing or assigning devices.
Design the fallback before the first decline
A phone-based reader can fail because the device is unsupported, the merchant is not enabled, connectivity drops, verification requires another path, or the battery is gone.
Detect
Check readiness early
Surface device and merchant eligibility before a guest is waiting to pay.
Explain
Separate setup from decline
An ineligible phone is an operator problem. A declined card is a payment outcome. Give them different recovery paths.
Recover
Keep an approved alternative
Define when to use another eligible phone, a hosted guest payment flow, or a supported physical reader.
The deployment test
Qualify every phone as a payment device, not merely as a phone.
Inventory model, OS, security status, merchant enablement, connectivity, staff sign-in, and fallback. Then run test-mode payments at the actual curb before removing the dedicated reader.
The takeaway: payment hardware is optional because the phone can become the reader. Readiness is not optional.
