Fake Apple Pay receipt reads a $657 charge aloud through the iPhone's own speech engine

Apple Pay on the web has a fixed shape. The merchant requests the payment, the system puts up a payment sheet, and the user reviews and authenticates it, which is what Apple's own guidelines specify ^[12]. None of that runs here. The "Face ID / verifying identity" line is an HTML element sitting beside an icon, with no Apple Pay request and no biometric-authentication call behind it ^[11], and the splash screen it sits on removes itself on a 2.8-second timer whether the victim touches anything or not ^[13].

The receipt is where the sample gives itself away. Amount, transaction ID and authorization code are hardcoded at $657.00, AP-2026-08-03-14:32 and AUTH-8F3A2B1C, identical for every visitor ^[14]. The date field is not: JavaScript calls new Date() and formats it with toLocaleString(), so the receipt carries the victim's own clock and timezone ^[15]. Because the ID date is frozen and the date field renders at view time, the two only agree for someone who opens the page on 3 August 2026 ^[18]. Malwarebytes flags that mismatch as the contradiction a genuine transaction cannot produce ^[15].

The audio is the part other kits will copy. The page creates a SpeechSynthesisUtterance and hands it to window.speechSynthesis, the browser's built-in Web Speech API, and the device reads out "Unauthorized charge of six hundred fifty seven dollars from your Apple ID. Please call support immediately" ^[16]. No hosted file, no recording, nothing to take down. Malwarebytes notes the effect: a voice already installed on the phone sounds more like the phone than like a website ^[17].

Most of the remaining code is spent on the exits. The page pushes a history entry and listens for popstate, so a backward gesture triggers a warning that closing the page could expose the victim's payments and banking information ^[1]. Cancel that prompt and it raises another warning and pushes another history entry; accept it and the code navigates to a tel: URL holding the scam number ^[2]. Handlers are also registered for beforeunload, pagehide, the context menu, an edge-swipe gesture and common keys ^[3]. Every item on that list is a page-level event.

Scope, plainly. There is no real transaction and no biometric verification in the sample, and the analysis describes hardcoded values, browser speech, fake warnings and navigation tricks whose whole purpose is to get the victim dialling ^[10]. Nothing is stolen by the page. The money moves after the call connects, and this write-up stops at the tel: handoff.

The funnel is the one that has run on desktops for years behind "your computer has a virus" pages ^[5]. What mobile changes is the distance to the phone call: on a desktop the victim had to pick up a second device and type the number, while here the number is a tap and is never read closely ^[2]. That is the reason the old desktop advice has to be restated for phones, against Apple Pay, Face ID and App Store branding rather than antivirus branding ^[6].