As someone who recently experienced this, and with all due respect, I have to disagree with your theory of a BIN brute force. If someone had brute-forced the card number, rotating the Apple Cash card number would have stopped the charges immediately because the old number would be dead and they’d have to start guessing again from scratch. That’s not what happened to me, and seemingly not what happened to the other expressing their frustration in this thread. The charges resumed on the new card number for myself within less than 24 hours after rotation, which rules out any attack that depends on knowing or guessing the card number.
The assumption that sequential reissuing makes brute forcing viable doesn’t track either. Card networks don’t reissue numbers sequentially. Visa’s tokenization and card generation systems use randomized numbering specifically to prevent this kind of predictability. Even if someone knew the old number, the new number isn’t old number plus one. And even setting that aside, brute forcing a card number still requires guessing the expiration date and CVV alongside it, which aren’t sequential by anyone’s definition. The math on brute forcing all three in combination doesn’t support the idea that someone could re-acquire a working set of credentials within hours of a rotation.
What actually fits the evidence is token-based persistent authorization, and there are two layers to how this works based on Apple and Visa’s published legal and privacy documentation, as well as from Krebs on Security.
The first layer is device-level token provisioning. If an attacker intercepts a one-time verification code through social engineering, they can provision the victim’s Apple Cash card onto their own device’s wallet. When that happens, Visa issues a Device Primary Account Number, which is a device-specific token that represents the underlying card but is not the card number itself. That DPAN lives on the attacker’s device and functions as a fully authorized payment credential. It doesn’t require the victim’s Apple ID session to persist, doesn’t care about password changes, and doesn’t get invalidated when the victim logs out all devices from their Apple ID, because the DPAN exists at the network level, not the Apple ID level.
The second layer is merchant-level token provisioning. When that device-provisioned card is used with a merchant like TikTok or Telegram, Green Dot and Visa issue a separate merchant-specific token tied to that merchant relationship. This token allows the merchant to initiate future charges without any further cardholder authentication. No Apple ID, no 2FA, no card number required. And critically, when the consumer rotates their card number, Visa’s token update service propagates the new credentials to all active tokens automatically. The merchant token refreshes itself.
Together, these two layers create what is effectively a permanent authorization chain. The device token gives the attacker a persistent foothold that survives credential resets, and the merchant token gives them a persistent billing relationship that survives card rotations. They’re legitimate tokens issued through legitimate infrastructure. They were just obtained through illegitimate means. That’s what makes this so difficult to detect and remediate from the consumer side. Everything looks valid to the network because technically it is.
The likely sequence is that at some point the Apple Cash credentials were provisioned against TikTok or Telegram through some form of social engineering, whether that was an intercepted OTP or something else. Once that provisioning occurred, the resulting token chain survived every remediation step available to the consumer. Password resets, card number rotations, session logouts, even a full factory reset of the device. The only thing that actually stopped the charges was locking the entire account, which just froze all activity rather than revoking the tokens themselves. Even if you choose to unlock the account later, unless Green Dot revokes the merchant tokens (which they informed me they refuse to do), the permanent authorization token still exists with the merchant, meaning you can continue to be charged even after all is said and done. The “scorched earth” approach being requesting Green Dot to close the Apple Cash account and open a new one.
A BIN brute force would also mean random merchants, not the same merchant hitting repeatedly through what is clearly a valid tokenized relationship. The pattern here is consistent with a provisioned token chain being exploited, not someone guessing numbers and hoping they land.
Just figured I’d include the results of my findings after countless hours of fighting with Apple, Green Dot, Phone Companies, Engineering Teams, Corporate Reps, etc.
