Contactless payments were designed for a card that is six centimeters from the reader — so the entire security model of tap-to-pay is a distance assumption. A relay breaks that assumption: one device talks to the victim's real card or phone through a wall, pocket, or across a room, while a second device presents that conversation to the merchant's terminal as if the genuine instrument were right there. The gap between those two ends is measured in milliseconds, and the whole method either fits inside the reader's latency budget or fails in the merchant's hand.
ROUTE MAP (PLAIN ENGLISH)
Near-field communication is a deliberate physics constraint — the protocol works over centimeters because the field dies that fast, and every tap-to-pay system inherits that limit as an implicit security boundary. A relay violates the boundary without touching the cryptography: a receiver sits next to the victim's card or phone, captures the challenge-response conversation the terminal initiates, pipes it over any transport you like to a transmitter standing at the merchant terminal, and streams the replies back. Neither end breaks the protocol; both ends merely pretend the distance is zero.
What the relay must actually beat is time. The terminal issues a challenge, expects its answer inside a window measured in hundreds of milliseconds, and the whole round trip — victim-side response, transport, merchant-side presentation, and back — has to close inside it. Add transport jitter, add the victim-side device's own wakeup and authorization behavior, and the latency budget becomes the real adversary. Everything else in this method — reader paths, fee tiers, split exits — only matters after the relay closes the loop in time.
STEP 1 - THE PROXIMITY PAIR
STEP 2 - THE LATENCY BUDGET
STEP 3 - READER PATHS AND PRESENTATION
STEP 4 - THE EXIT AFTER AUTHORIZATION
STEP 5 - DETECTION AND COUNTERS
WORKED EXAMPLE - CAFE TERMINAL, $40 TAPS
Target environment: busy cafe with a countertop terminal, staff who hand over orders the moment the tap beeps, floor limit comfortably above an average order, no last-four check. Receiver end: a phone in a bag placed against the cafe table's near side, genuine card in the victim's wallet a table away — passive card, instant answers, zero consent overhead. Transmitter end: relay-capable device shaped into a phone case at the counter, operated during the rush. Transport: short-range link through the venue's own path, round trip averaging 60ms against a terminal window in the high hundreds — slack in the budget, jitter occasionally spiking but never closing it. Run: eleven taps across forty minutes, each under the challenge threshold, each a separate conversation with variance in timing drawn from natural tap-to-tap spread, goods collected by the transmitting operator each time. Exit: goods to resale channels the same afternoon, before cardholder notifications aggregate into a dispute wave. Victim notices the wallet history that evening; by then the tapping sequence has no merchant concentration, no shared terminal beyond the one cafe, and no camera that puts both ends in frame — the issuer dispute lands against an acquirer whose merchant saw eleven ordinary-looking customers buy eleven coffees.
WORKING SEQUENCE
QUICK ANSWERS
RELATED
Near-field communication is a deliberate physics constraint — the protocol works over centimeters because the field dies that fast, and every tap-to-pay system inherits that limit as an implicit security boundary. A relay violates the boundary without touching the cryptography: a receiver sits next to the victim's card or phone, captures the challenge-response conversation the terminal initiates, pipes it over any transport you like to a transmitter standing at the merchant terminal, and streams the replies back. Neither end breaks the protocol; both ends merely pretend the distance is zero.
What the relay must actually beat is time. The terminal issues a challenge, expects its answer inside a window measured in hundreds of milliseconds, and the whole round trip — victim-side response, transport, merchant-side presentation, and back — has to close inside it. Add transport jitter, add the victim-side device's own wakeup and authorization behavior, and the latency budget becomes the real adversary. Everything else in this method — reader paths, fee tiers, split exits — only matters after the relay closes the loop in time.
STEP 1 - THE PROXIMITY PAIR
- Receiver side (victim end): the device that sits near the genuine instrument — a modified reader coil next to a wallet in a bag, a phone held near a coat pocket, a relay terminal planted where phones rest (cafe table, gym bench, transit seat). The receiver triggers the genuine card or phone's contactless stack and captures its challenge-response traffic; on passive cards the conversation happens on demand, while phone wallets add their own hurdles — locked screen, in-wallet state, and per-transaction authorization all gate whether the tap actually fires.
- Transmitter side (merchant end): the device that presents the relayed conversation to the real terminal — shaped like a card, built into a phone case, or hidden in a payment terminal's shell at the merchant's counter. It speaks the identical protocol the terminal expects, feeds it the responses that came from the genuine instrument, and completes the authorization the terminal believes it just performed.
- Transport between them: the pipe that carries challenge and response across distance — a long-range link between the two devices, or a network relay where each end reports to a handler that pairs them live. Transport choice sets the latency floor: the shorter and fatter the pipe, the more budget remains for jitter before the terminal times out.
- Pairing discipline: one victim end bound to one merchant end during a run, cross-pairing queues mixing sessions, and stale bindings leaking state between attempts. A relay stack's reliability comes from boring, predictable pairing — every cross-talk event burns a live authorization window that does not come back.
STEP 2 - THE LATENCY BUDGET
- Terminal windows: contactless terminals expect the full challenge-response exchange to complete in a few hundred milliseconds — the tap gesture itself is a timeout, and a response that arrives after the terminal has given up is a failed tap with nothing captured. The budget is not generous, and it cannot be negotiated from the merchant's side.
- Where the milliseconds go: victim-side wakeup and authorization (phone wallets need the tap to be intentional or unlocked — passive cards answer immediately), transport round trip (radio hop or network path), transmitter presentation, and the reply path back. Every hop spends from the same envelope, and transport jitter is the term that kills runs — a stable short pipe with milliseconds of slack beats a clever long pipe with spikes.
- Passive vs active victims: a bare card in a pocket answers instantly with no user awareness at all — the entire budget goes to transport. A phone in a locked wallet may refuse the tap outright, adding an awareness problem on top of the latency one; the method's cleanest form targets the passive instrument because it spends nothing on consent.
- Timeout behavior and retries: a missed window is a failed tap, not a partial success — the terminal resets, the merchant sees nothing, and the operator at the transmitter end sees a decline with no explanation. Retry discipline matters: hammering the same terminal with relay attempts patterns trivially on the merchant's device logs.
STEP 3 - READER PATHS AND PRESENTATION
- Terminal-side presence: the transmitter works wherever a real tap works — retail counters, vending machines, transit gates, parking terminals. The conversation it streams is genuine end-to-end, so the terminal's protocol checks all pass; what differs is what happens after authorization, because goods, tickets, or access are handed to whoever is standing at that terminal.
- Merchant behavior as cover: staff who watch the tap and hand over goods without a glance are the environment this method feeds on; staff who check the last four against a screen or require signature above a threshold narrow the window to transactions small enough not to trigger it.
- Fee tier selection: contactless transactions carry fee structures and authorization limits that scale with amount — tap windows, floor limits, and occasional-challenge thresholds all define the per-tap ceiling. Staying under the challenge threshold keeps every tap one conversation; crossing it invites a step-up that the relay stack must also carry or fail.
- Split presentation: many small taps across terminals instead of one large one respects both the fee tier and the floor limit, and spreads the pattern across devices and merchants rather than concentrating it. Aggregation is where detection starts — the split is not only about limits, it is about not becoming one loud sequence.
STEP 4 - THE EXIT AFTER AUTHORIZATION
- Goods vs balance: relayed taps produce goods, tickets, or access at the merchant — they do not produce bank balance directly. The liquidation leg is the separate second half of the method: resale of physical goods, transfer of loaded value, or use of prepaid capacity, each with its own spread and its own velocity signature.
- Speed against the dispute clock: the genuine instrument's holder eventually sees the transactions — contactless transactions appear in wallet histories fast, and a cardholder who does not recognize taps disputes them quickly. Exit before the dispute wave reaches the merchant's acquirer, and treat every authorization as reversible until proven otherwise.
- Cross-merchant spreading: one merchant seeing a burst of small authorized taps with no matching customer behavior is a fraud alert waiting in the acquirer's queue; the same taps spread across a city's terminals read as ordinary contactless noise. Movement is the mitigation — there is no static version of this exit.
- Evidence surface: cameras at the merchant end see the transmitter operator's face, cameras at the victim end may see the receiver's placement, and both ends' device logs carry timestamps that correlate when investigators compare them. Presenting ends that never appear on camera with the other end is the entire physical OPSEC discipline.
STEP 5 - DETECTION AND COUNTERS
- Latency forensics: terminal logs record tap duration and response timing — an exchange that took the absolute maximum of the window every single time, or clustered suspiciously close to it, looks different from organic taps with human variance. Some issuers score tap-duration anomalies alongside geography; the relay's fingerprint is its own consistency.
- Geography contradictions: the genuine instrument's wallet history shows ordinary local use, and suddenly carries taps from a terminal the holder was nowhere near — issuer scoring treats distance-impossible sequences as a primary fraud signal, which is why the discovery window on this method is measured in hours, not days.
- Merchant and acquirer review: bursts of small contactless authorizations at one terminal, staff who recall a customer acting oddly around the counter, or a terminal that seems to authorize without goods matching — acquirer queries start the reconstruction. Spreading the pattern across merchants keeps any single query boring.
- Wallet-side controls: phone wallets that require unlock per transaction, cards stored in RF-shielded sleeves, and transaction notifications with instant freeze all compress the window from the victim's side. The method's viability tracks directly against how casually the genuine instrument is carried.
WORKED EXAMPLE - CAFE TERMINAL, $40 TAPS
Target environment: busy cafe with a countertop terminal, staff who hand over orders the moment the tap beeps, floor limit comfortably above an average order, no last-four check. Receiver end: a phone in a bag placed against the cafe table's near side, genuine card in the victim's wallet a table away — passive card, instant answers, zero consent overhead. Transmitter end: relay-capable device shaped into a phone case at the counter, operated during the rush. Transport: short-range link through the venue's own path, round trip averaging 60ms against a terminal window in the high hundreds — slack in the budget, jitter occasionally spiking but never closing it. Run: eleven taps across forty minutes, each under the challenge threshold, each a separate conversation with variance in timing drawn from natural tap-to-tap spread, goods collected by the transmitting operator each time. Exit: goods to resale channels the same afternoon, before cardholder notifications aggregate into a dispute wave. Victim notices the wallet history that evening; by then the tapping sequence has no merchant concentration, no shared terminal beyond the one cafe, and no camera that puts both ends in frame — the issuer dispute lands against an acquirer whose merchant saw eleven ordinary-looking customers buy eleven coffees.
WORKING SEQUENCE
Code:
pair: one receiver bound to one transmitter, transport bench-tested for jitter, passive victim instrument preferred -> budget: transport round trip + presentation inside terminal window, human timing variance maintained -> present: under challenge threshold, one tap per conversation, staff-cover environment, no terminal hammered -> spread: cross-merchant, cross-hour, burst-free, camera ends never co-present -> exit: goods liquidated same window, before notification aggregation -> assume: discovery at hours, dispute clock running from first tap, nothing reversible treated as finalQUICK ANSWERS
- Does the relay break the card's encryption? Nothing breaks — the cryptographic conversation between genuine instrument and terminal runs untouched, just extended across distance. The protocol proves the card is real; it was never designed to prove the card is near, which is the assumption the relay violates.
- Why does a phone wallet behave differently from a bare card? A passive card answers any reader that powers it, instantly and without user awareness. A phone wallet gates the tap behind device state — locked, out of wallet, or requiring per-transaction approval — so half the method becomes an authorization problem the card does not have.
- What is the real limit on transaction size? The terminal's challenge threshold and fee tier: below it every tap is a single conversation; above it the terminal demands step-up authentication that the relay must carry or fail. The practical ceiling is whichever is lower — the terminal's floor limit or the point where staff start checking the customer.
- How long until the genuine holder notices? Wallet notifications are push-based and instant for many holders — the discovery window can be minutes. Everything irreversible must complete inside a conservative window that assumes the holder is looking at their phone during the run, not after it.
- Does latency variation actually get flagged? Terminals and issuers see tap duration on every transaction. Organic taps show human variance; a relay shows either suspicious consistency or repeated near-timeout values — both are patterns that scoring can learn, which is why the presentation side deliberately varies timing.
- What kills the method at the merchant end? Active staff verification — last-four checks, signature demands above threshold, or a culture of watching the customer's face instead of the terminal. Environments that treat the beep as the transaction are the environments where the method operates; everything else is a slow counter.
RELATED