iPhone in-depth Lesson 7: POS Terminals & Payment Protocols [Springfield Scammin' Series]

[GarySpringfieldScammin’]

Lesson 7: POS Terminals & Payment Protocols
Part 1 of 2 — continued in the first reply below.

Moving the Same Purchase In-Store​

Lessons 1 to 6 traced a purchase made online, where a fraud vendor scored the checkout before the bank saw it. This lesson takes the same $91.92 purchase, the same card, and the same iPhone into a physical store.

The money still follows authorisation, capture, then settlement and funding in one to three days. What changes is the first hop. There is no browser, no cookie, no IP address, no fraud score, and no 3-D Secure challenge. The terminal is the browser.

That changes what is proved and who bears the loss. A card declined online can often still work in-store, and the reverse is also true. Those are different gates, not one gate with different thresholds.

The terminal does not ask who you are in the way a website does. It asks the chip to prove itself, and it asks you to prove you hold the chip.

Architecture: Who Is in the Room​

• Card or device: a physical chip card, or an iPhone or Apple Watch over NFC. The chip is a tiny computer.
• POS terminal: the card reader. It speaks EMV to the card, encrypts the PIN, and forwards a message. It is usually a certified, tamper-resistant device.
• Acquirer or processor: the merchant bank or its processor. It receives the terminal message and routes it onward.
• Card network: Visa, Mastercard, Amex, or Discover. It routes the message, enforces the rules, and runs clearing and settlement.
• Issuer: your bank. It makes the approve or decline decision and validates the cryptogram.
• Token Service Provider, or TSP: for Apple Pay, this is Visa Token Service, Mastercard Digital Enablement Service, or Amex Token Service. It maps the Device Account Number back to the real card number.

Online, a gateway and a fraud vendor sat between merchant and processor. In-store, that layer is mostly absent; the chip cryptogram does the heavy lifting.

Swipe, Dip, and Tap: Three Ways In​

Method	What Is Read	Freshness Proof	Weakness
Swipe	Static number and expiry	None, data never changes	Copied data can be cloned
Dip, EMV chip	Chip application	One-time cryptogram	Needs a chip reader
Tap, NFC	Same chip data, by radio	Same one-time cryptogram	Relay possible in principle

Swipe: Static Data​

The magnetic stripe holds static data: card number, expiry, and service code. Anyone who copies it can clone it. Verified from EMV history: this is why counterfeit-card fraud was an in-store problem before chip cards. Swipe still exists as a fallback, and that fallback is itself a signal to the issuer. The entry mode is recorded in the authorisation message.

Dip: The EMV Chip, Step by Step​

The chip generates a one-time cryptogram, the ARQC, tied to amount, date, merchant, and a counter, the ATC, that increments every transaction.

1. Terminal selects the payment application, using the AID, for example Visa or Mastercard.
2. Terminal sends GET PROCESSING OPTIONS.
3. Terminal sends READ RECORD.
4. Terminal sends GENERATE AC, with data defined by CDOL1, including amount and an unpredictable number.
5. Chip returns the ARQC, tag 9F26, plus the ATC and the CID.
6. Terminal forwards the ARQC to the issuer, which validates it and returns the ARPC.
7. Chip verifies the ARPC and returns TC for approved, or AAC for declined.

Most chip transactions in the United States go online to the issuer. Some low-value transactions can be approved offline by the chip itself, within floor limits set by the issuer. A terminal may also store-and-forward when its connection is down: approve now, send later. That is why offline limits are low.

Offline PIN is checked by the chip itself. Online PIN is encrypted with DUKPT, Derived Unique Key Per Transaction, and checked by the issuer. US credit cards usually run chip-and-signature or no cardholder verification method. Debit cards usually require a PIN.

Tap: The Same Chip, Over Radio​

Tap is not a different security model. It is the same chip over NFC, ISO 14443, at about four centimetres, with the same flow: SELECT PPSE, using 2PAY.SYS.DDF01, then GET PROCESSING OPTIONS, READ RECORD, GENERATE AC, and the ARQC.

Contactless has a cardholder verification limit. Above it, the terminal asks for a PIN, or the transaction goes online. Limits vary by country, network, and merchant. There is no single universal figure, and this lesson does not state one.

SELECT PPSE 2PAY.SYS.DDF01
GET PROCESSING OPTIONS
READ RECORD
GENERATE AC with amount and unpredictable number
Chip returns ARQC tag 9F26 plus ATC plus CID
Issuer validates ARQC and returns ARPC
Chip returns TC approved or AAC declined

Apple Pay In-Store: The Token at a Terminal​

What leaves the phone is the Device Account Number, or DPAN, plus a one-time dynamic cryptogram and a dynamic CVV, generated in the Secure Element from the token key, counter, and amount. The real card number never leaves the Secure Element.

The terminal forwards the DPAN and cryptogram to the processor, network, and TSP. The TSP validates the cryptogram, de-tokenises the DPAN to the real card number, and passes it to the issuer. The merchant never sees the real card number.

CDCVM, Consumer Device Cardholder Verification Method, is Face ID, Touch ID, or passcode on the phone, replacing the terminal PIN or signature. When the terminal supports CDCVM, you can tap above the normal contactless limit with no PIN and no signature. When it does not, it may still prompt for a PIN. That prompt is a terminal-configuration fact, not a decline.

In-store NFC Apple Pay does not go through Apple servers; the Secure Element talks directly to the terminal. The same card on an iPhone and on an Apple Watch has different DPANs, as does the same card on a second iPhone. The receipt last four will therefore differ from the physical card.

Trust Boundary: The Message That Actually Travels​

Online, the checkout sent HTTPS and JSON to a gateway. In-store, the terminal and acquirer speak ISO 8583, the card industry message format.

ISO 8583 Field	What It Carries	Why It Matters
Card number	Card number or DPAN	Identifies the account or token
Amount	Transaction amount	Bound into the cryptogram
Terminal and merchant ID	Which terminal and merchant	Locates the transaction
Entry mode	Chip, tap, swipe, or keyed	Decides liability after a dispute
Field 55	ARQC, ATC, chip data	The proof the issuer validates
PIN block	Encrypted PIN	Encrypted before it leaves the terminal
Timestamps	Date and time	Ordering and replay checks

The path is terminal to acquirer, to network, to issuer, and the answer returns the same way in about one to two seconds. Authorisation is still a hold, not money moving. Capture happens in the end-of-day batch, and settlement follows the same one-to-three-day pattern.

Authorisation is a hold. Capture is the batch. Settlement is the money moving. The terminal changes only the first step.

What the Terminal Knows, and What It Does Not​

Signal	Online Checkout	In-Store Terminal
Device fingerprint	Browser, canvas, fonts, TLS	The card or phone itself
IP and location	IP address and geolocation	Store location, no IP from you
Behavioural biometrics	Mouse and typing cadence	PIN timing, in principle only
Fraud vendor	Fraud score at checkout	Mostly none at the terminal
Identity graph	Email and account history	Card plus PIN or CDCVM
What proves it is you	Password and 3-D Secure	Cryptogram plus PIN, or Face ID

Inferred: that is why a card declined online can often still work in-store, and vice versa. Online, fraud and browser signals can decline a transaction the issuer would have approved. In-store, the cryptogram proves card presence, with no browser signal to fail on.

Continued in the first reply below — Part 2 of 2.

 

[GarySpringfieldScammin’]

Part 2 of 2 — continued from the thread above.

Weakness: Liability After the October 2015 Shift​

Verified: before October 2015, issuers generally absorbed counterfeit-card fraud. From October 1, 2015, the networks shifted liability to whichever party had not adopted EMV. A merchant swiping a chip card on a magstripe-only terminal bears the counterfeit loss. A chip-reading merchant does not.

Verified: counterfeit fraud at merchants in the United States that fully enabled chip processing fell about 87 percent by early 2019, compared with September 2015, per US Payments Forum figures cited in EMV summaries.

The shift covers counterfeit fraud only, not friendly fraud, lost or stolen card disputes in the same way, or card-not-present fraud. Online, the merchant still bears card-not-present fraud by default. EMV solved much of the in-store cloning problem, and fraud moved online.

Fallback and keyed entry have their own rules. If a chip transaction falls back to magstripe and the merchant flags it properly, the issuer generally bears liability when it approves. If a merchant keys a card number in by hand, the merchant is liable. The entry mode is the evidence.

Weakness: Attacks and Failure Modes​

Skimmers and Shimmers​

A skimmer over a swipe slot copies static stripe data. EMV defeats replay in-store, because the cryptogram cannot be replayed. But a skimmed card can still be used online, where no chip is read.

A shimmer inside the chip slot can capture the card number and some EMV data, but without the chip secret key it cannot generate a valid ARQC. A shimmer alone does not clone a chip card for in-store use. Verified in principle from EMV design. The exact capabilities of a given shimmer are Unknown without a sample.

Relay, Tampering, and Offline Approval​

NFC range is centimetres, but a relay can forward a tap over a longer distance in principle. The cryptogram is still single-use and amount-bound, so the attacker cannot change the amount after it is made. Real-world relay fraud against EMV contactless is rare. Inferred from protocol design, not from a demonstrated case.

A fake keypad or camera captures the PIN. The PIN alone is useless without the card or chip. Combined with a skimmed stripe, it enables a cloned-card plus PIN withdrawal. Covering the keypad, and using tap or Apple Pay with no PIN on the terminal, changes the exposure.

A terminal with no connection can approve small transactions offline. If the issuer later declines, the merchant bears it.

Demonstration: What a Proxy Cannot Show Here​

There is no HTTP to intercept: terminal to acquirer traffic is ISO 8583 over private links, not browser traffic. There is no Secure Element data to capture: the cryptogram and DPAN are generated inside the Secure Element, and a proxy on the phone cannot see them. What is observable is the receipt, the bank app authorisation timing, the entry mode, and the terminal prompts.

Evidence: Hands-On Experiment, Own Purchases Only​

This takes about fifteen minutes, over two shopping trips. Observe only your own receipts and bank app. No proxy, no terminal tampering, and no reading anyone else card.

1. Buy something small twice, on different days. Once, dip the physical card. Once, tap with Apple Pay. Note the receipt, how fast the bank app shows the authorisation, and whether a PIN or signature was requested. The DPAN last four will differ from the physical card last four.
2. Try Apple Pay above the usual tap limit and note whether CDCVM lets it through with no PIN. Do not force it. If it asks for a PIN, that is the data point: the terminal is not CDCVM-configured.
3. Compare the bank app entry for the in-store purchase with the $91.92 online purchase from Lesson 3: same hold and capture pattern, different entry mode and merchant descriptor.

Decision Lab​

Four scenarios. Decide who saw the transaction, who bears the loss, and what the evidence would be. Then open the spoiler to check.

Scenario 1: Chip Dipped, PIN Correct, Issuer Declines​

You dip the chip card, enter the correct PIN, and the issuer declines. Who saw it, and who bears what?

Spoiler: Answer

The terminal, acquirer, network, and issuer all saw it. The chip and PIN proved card and holder, but the issuer still declined, for example for funds or a fraud rule. No money moves, and the merchant bears nothing, because no sale was completed.

Scenario 2: Same Card Swiped at a Magstripe-Only Terminal, Later Charged Back as Counterfeit​

The terminal is magstripe-only, so it swipes. Later the transaction is charged back as counterfeit. Who is liable, and why?

Spoiler: Answer

The merchant is liable. From October 1, 2015, counterfeit liability shifted to the party that had not adopted EMV. The card had a chip, the merchant did not read it. The entry mode, swipe instead of chip, is the evidence.

Scenario 3: Apple Pay Tap, $200, Terminal Asks for a PIN​

You tap with Apple Pay for $200, already authenticated with Face ID. The terminal asks for a PIN. Is this a decline, a fraud signal, or a configuration fact?

Spoiler: Answer

It is a configuration fact, not a decline or a fraud signal. The $200 figure is only the amount in this example, not a stated limit. The terminal is not CDCVM-configured, so it does not accept phone Face ID and falls back to a PIN.

Scenario 4: Card Tapped, Terminal Offline, Says Approved, Issuer Later Declines​

You tap the card. The terminal is offline and says approved. Later the issuer declines. What happens, and who eats the sale?

Spoiler: Answer

The terminal approved offline, or store-and-forward, within a low offline limit. When the issuer declines, there is no valid authorisation to capture against. The hold should not stand, and the merchant bears the sale.

Defense: What Actually Helps In-Store​

• Use the chip, not the stripe. Dip or tap when allowed. Swipe loses the cryptogram protection.
• Use Apple Pay or another tokenised tap when you can. The merchant never sees the real card number, and no PIN is entered on the terminal.
• Cover the keypad if you enter a PIN. A captured PIN is only dangerous with a copied card, but do not give an attacker the easy half.
• Watch the bank app, not just the terminal. It can say approved offline while the issuer later declines.
• Treat a PIN prompt on an Apple Pay tap as information. It tells you the terminal is not CDCVM-configured, not that you were declined.

Each defense follows from the mechanism: a one-time cryptogram, a token that is not the real card number, and verification on your own device.

Discussion Prompts​

• Have you had a card declined online that worked in-store, or the reverse? Which gate declined it, and what evidence did you have?
• EMV cut counterfeit fraud in-store, and fraud moved online. What would you expect if online checkout got a proof as strong as the chip cryptogram?
• Tap to Pay on iPhone turns a phone into the terminal. What changes when the reader is a phone, not a certified terminal?

Next Lesson​

This completes the series so far, from how an iPhone is identified, through where the card lives, the online purchase trace, chargebacks, Apple Account identity, merchant variance and tracing, to this in-store lesson. The next step is open. Share what you want covered next: a terminal teardown, Tap to Pay on iPhone, or a deeper trace of a real in-store purchase of your own.