The locked iPhone tap-to-pay hack shown in Veritasium’s video is a striking example of how a payment system can be fooled without ever opening the phone. In the demo, a locked iPhone still approves a transaction because the message between the phone and the reader is intercepted, altered, and passed along through a relay setup.
At first, the amount is small. Then the same setup is used to push through a much larger charge. The point is not that everyday phones are randomly vulnerable in normal use. The point is that one specific combination of phone behavior, card behavior, and transaction checks creates a narrow but real loophole.
A useful way to understand the story is to treat it like a chain of trust. Every device in the chain believes it is speaking directly to the next one. In reality, the data is being reshaped in the middle.
For readers who want a broader background on proximity-based payment risks, the cybersecurity best practices guide explains how modern systems handle threats.
How the Locked iPhone Tap-to-Pay Hack Works
The demo begins with a locked iPhone sitting on top of a payment device. Nothing on the phone is manually unlocked, and no PIN, Face ID, or password is entered. Yet the payment still goes through.
The setup uses a relay chain. A Proxmark device sits between the phone and the reader, a laptop modifies the data in the middle, and a second phone forwards the adjusted message to the actual card reader. Each side thinks it is talking straight to the other side.
That is the core of the attack. It is a man-in-the-middle setup, but one designed for contactless payments rather than a normal website or network session. The transaction data is not simply copied. It is selectively changed.
The relay chain that sits between phone and reader
The first step is deception by position. The relay devices are placed where each system expects a direct connection. The iPhone believes it is speaking to a transit-style terminal. The terminal believes it is speaking to the real customer device.
That matters because payment systems often rely on assumptions about context. A transit gate is not the same as a retail checkout, and the rules are different. The hack uses that difference.
The three lies that make the payment pass
The video explains the attack as three lies.
First, the phone is tricked into thinking the reader is a transit terminal. That bypasses the usual lock-screen requirement. In Apple’s wallet flow, Express Transit mode is designed to make transit payments fast and frictionless, which is convenient in real life but useful to an attacker in this scenario.
Second, the transaction is made to look low value even when it is not. The phone is not checking the actual dollar amount in a simple human way. It is checking a transaction field that labels the payment as low or high value.
Third, the reader is told that customer verification already happened, even though it did not. Once that bit is flipped, the reader forwards the transaction and the bank approves it.
That is the interesting part of the demo. The system is not being cracked with brute force. It is being nudged by changing the labels that guide the rules.
Why the Locked iPhone Tap-to-Pay Hack Depends on iPhone, Visa, and Express Transit
The attack is not universal. It depends on a very specific combination of phone behavior and card behavior. That narrowness is important, because it explains why this is a real security lesson rather than a general statement about every tap-to-pay system.
Why the Locked iPhone Tap-to-Pay Hack Starts with Express Transit
Express Transit mode is the first doorway. It allows a phone to make certain transit payments without forcing a full unlock every time. That is ideal when someone is rushing through a gate or boarding a bus.
In the demo, that convenience becomes the opening. The phone is made to believe it is in a transit situation, so it behaves differently than it would at an ordinary checkout. Once that trust is established, the attack moves to the next layer.
This is why convenience features need careful boundaries. A shortcut built for commuters should not become a shortcut for an attacker. The challenge is that the phone has to decide fast, and it has to work across many terminals and many cards.
Apple’s support pages cover wallet and transit behavior in more detail, while EMVCo and the NFC Forum document the standards and ecosystems behind contactless payment systems.
Why the Locked iPhone Tap-to-Pay Hack Needs a Visa Card
The video also makes a second point: the card matters. The loophole works with a Visa card in the transit slot, but not in the same way with every network.
The explanation in the video is that Visa and MasterCard do not handle every verification step in the same way. MasterCard’s flow uses a signature check in more situations, which would catch the altered data. Visa’s behavior in this specific setup leaves an opening when the reader is online and the transaction is handled as a particular kind of payment.
That is a subtle but important distinction. A payment network can be highly secure overall and still have edge cases where two legitimate features collide in a bad way.
Why the reader staying online matters
The reader being online is not a side detail. It is one of the reasons the attack works.
When a reader is online, one layer of verification can be used instead of another. The video explains that the attacker deliberately keeps the reader online so the system avoids the check that would expose the manipulated signature. That is a neat example of how security depends not only on encryption, but on which branch of the protocol gets used.
This type of attack is similar to techniques explained in how hackers steal passwords, where attackers manipulate trust instead of breaking encryption directly.
Quick recap: the hack works by making the phone think it is in transit mode, making the payment look low value, and making the reader believe the payment was customer-verified. Each step is small on its own. Together, they create a working exploit.
What the Demo Means for Everyday Payment Security
The most important lesson is not that every iPhone payment is broken. The lesson is that security depends on how protocols interact when different assumptions overlap.
A modern payment system is full of trade-offs. It has to be fast, compatible, and easy to use across countless devices. That means some transaction details may travel in forms that are readable long enough for the system to function across different vendors and countries. That is practical, but it also creates room for misuse in rare combinations.
The demo also shows why “the bank will refund it later” is not a satisfying answer on its own. A refund does not remove the stress of seeing money leave an account. It does not help if rent, insurance, or a bill is due that same day. Security is not just about whether money can eventually be recovered. It is also about whether the system should have allowed the charge in the first place.
For a deeper look at the mechanics behind this kind of payment flow, a guide to mobile wallet security fits naturally beside this article and helps connect the dot between convenience and verification.
The risk is narrow, but the lesson is broad
The vulnerability in the video is specific. It needs a particular phone, a particular card type, and a carefully staged relay. It is not the kind of bug that lets anyone siphon money from any device at random.
Still, narrow vulnerabilities matter. They reveal how many real systems are held together by layers of assumptions. If one layer trusts the wrong label, and another layer trusts the wrong context, a small manipulation can travel surprisingly far.
What users can do now
The simplest protection is to understand what wallet features are enabled on the phone. If Express Transit is available and not needed, it is worth reviewing. The point is not to panic. The point is to know which features are active and why.
It also helps to pay attention to transaction alerts. Fast notification makes a big difference if a suspicious charge appears. Even when refunds are available, early detection is still the best defense.
Coverage Highlights and Practical Value
This story works because it shows security from the inside rather than from a slogan. Instead of saying a payment system is “safe” or “unsafe,” the video shows the exact places where trust is granted, then shows how those trust points can be redirected.
That makes the demo useful beyond the headline. It clarifies why contactless payments are built around speed, why transit systems are treated differently, and why compatibility sometimes forces design compromises. It also shows that a security weakness does not have to be dramatic to matter. A small mismatch between “high value,” “low value,” and “verified” can change the outcome.
The practical takeaway is straightforward. Convenience features should be understood, not just enabled. And when a payment system depends on bits, labels, and context, the details become the whole story.
Conclusion
The locked phone demo is memorable because it looks impossible at first glance. A phone stays locked, a payment terminal is tapped, and money moves anyway. But the explanation is not magic. It is a chain of protocol decisions, context tricks, and transaction fields that can be reshaped in the middle.
That is why the locked iPhone tap-to-pay hack is such a strong security example. It shows how real systems can be technically sound in general while still leaving a narrow opening when two legitimate features meet in the wrong way.
Disclaimer: This article summarizes a controlled security demonstration for educational purposes. It is not advice for misuse, and unauthorized payment interception or tampering is illegal.