What does a shop need to take contactless payments on a phone?
A payment service provider, and an application built on the platform framework meant for it. The phone replaces the terminal hardware and inherits everything that came with a terminal: certification, an entitlement from the platform, and a device that has to be kept up to date.
The phone as the reader
This is the mirror image of the rest of the section. Instead of the phone presenting a card, it is reading one, which is reader mode as the reader mode page describes, applied to a payment card.
Apple documents it as Tap to Pay on iPhone in the ProximityReader framework, which allows an iPhone to act as a point of sale device without additional hardware, and which also reads loyalty passes from the wallet in the same session.
The equivalent exists on the other platform through payment providers rather than as a general framework, and the shape of the requirements is the same either way.
You still need a provider
Apple's documentation is explicit: using the framework requires coordinating with a participating payment service provider that is certified at the highest level of payment testing, and an entitlement requested from Apple before the application can integrate it.
So the phone removes a piece of hardware from the counter and removes nothing from the contractual chain. The acquirer, the provider, the fees and the settlement are all still there.
The documentation also states that Tap to Pay on iPhone follows the PCI CPoC standard, which is the security standard written for accepting contactless payments on an ordinary device, with certified payment kernels and a defined user interface.
What the framework imposes
One read at a time, from a session obtained after the device has been configured, as the reader session sets out. There is no way to poll for cards in the background or to run two readers at once on one device.
A way to capture a code when the transaction requires one, which is the part people assume is impossible on a phone.
A store and forward mode, which lets a device take payments while it cannot reach the provider and send the batch afterwards. That is the feature a market stall or a delivery round actually needs, and it is documented rather than improvised.
And a published date at which the current operating system version stops being accepted for payment, exposed through the session itself. A shop phone that is never updated stops being able to take money, by design.
What it means in a shop
The saving is the terminal and its maintenance, not the payment economics. Anyone comparing this with a terminal on price should compare provider fees rather than hardware.
The phone becomes till equipment: it needs charge through a shift, a case that survives a counter, and an update policy, because the framework will refuse to work on an operating system that has been left behind.
And the customer experience is the one that decides adoption: a phone held out across a counter is less obvious than a terminal, so tell people where to tap, which the signage page covers and which applies to a member of staff holding a phone as much as to a tag on a wall.
Frequently asked questions
Can any phone take payments?
No. It needs a supported device, an application built on the platform framework, and a payment service provider that is certified for it.
Does it replace the payment provider?
No. It replaces the terminal hardware. The acquirer, the provider, the fees and the settlement are unchanged.
Can it take a PIN?
The framework documents a way to capture a code when a transaction requires one, so a payment above the ceiling is not automatically refused.
What happens if the phone is never updated?
It stops being able to take payments. The session exposes the date at which the current operating system version is no longer accepted.