Incidents & Vulnerabilities
7pay Fraud (2019) — How a Payment App With No 2FA Got Taken Over
In July 2019, Seven & i's 7pay app was taken over a day after launch — ~808 users lost ~¥38.6M and it was scrapped in ~3 months. Root causes: no 2FA, and a password reset that could send the new password to an unregistered email. Defend with 2FA, resets only to registered channels, and anti–credential-stuffing.
We read real, public breaches not as replayed news but as "how do you defend against this?" This article is based on the public record (company statements, regulators, reputable reporting). Sources are listed at the end, and no attack how-to is included.
- Target
- User accounts in the "7pay" payment app (operator: 7pay, Inc. / Seven & i Holdings)
- Detected
- 2–3 July 2019 (unauthorized access noticed right after launch)
- Pattern
- No 2FA + a password reset whose destination could be an unregistered address → authentication bypass → fraudulent use of balances
- Scale
- ~808 users, ~¥38.6M in fraud (count later refined by investigation)
- Root cause
- No 2FA (ID + password only) + password reset deliverable to an unregistered email + weak resistance to credential-stuffing + weak external-ID (7iD) integration + insufficient pre-launch review of the auth flow
- Real fix
- Require 2FA on sensitive actions, restrict password reset to registered channels, detect/lock credential-stuffing, review auth flows before launch
What happened (in plain terms)
A mobile payment app holds the power to move your money. That makes "only the real owner can log in, nobody else" — the authentication design — the crux. 7pay was weak here: its defense was effectively a single password.
Two problems compounded. First, there was no two-factor authentication (2FA): if the ID and password matched, you were in — so the app was weak against credential-stuffing, where attackers try IDs/passwords leaked from other services. Second, the password-reset design: the new password could be sent to an email address other than the registered one, so anyone holding fragments of personal data (date of birth, phone, email) could replace the password without being the real owner. Together, these meant the single-password defense could be stolen head-on through a weak reset.
Guarding a 'money-moving entry' with one weak factor is the worst case
What attackers value is a single gate that maps directly to money or personal data. Guarding a high-value entry — payments, transfers, admin login — with one password plus a weak reset is exactly that. Beyond payments, any admin panel where one login reaches balances or every user's data carries the same danger.
The attack chain is also a defense map
This was a chain with a place to stop it at every step. Read it as where it could have been broken, not as a how-to.
1. Entry: login by ID + password only
Reused credentials leaked elsewhere could simply work.
Stop: 2FA / passkeys; detect and lock credential-stuffing
2. Impersonation via password reset
The new password could be sent to an unregistered destination.
Stop: reset only to registered channels; stronger identity checks; notify on reset
3. Account taken over, balance abused
The hijacked account was used to pay and charge.
Stop: re-auth before sensitive actions; detect and pause abnormal payments; notify
4. Damage spreads, service killed
After all charging was suspended, the whole service was scrapped in ~3 months.
Stop: review auth flows before launch; don't build a single point of failure by design
Published timeline
2019-07-01
7pay launches (inside the 7-Eleven app, integrated with 7iD).2019-07-02
First reports of unauthorized use begin (including access from overseas IPs).2019-07-03
Unauthorized use recognized; overseas access is blocked and credit/debit-card charging (top-ups) is suspended.2019-07-04
Public press conference; all charging is temporarily suspended. The absence of two-factor authentication is widely noted.2019-07-05
Japan's METI requests a response; root-cause investigation and organizational hardening begin.2019-08-01
Abolition of the service is announced (a safe restart would take considerable time).2019-09-30
7pay shuts down.
The root cause was layers failing, not one mistake
Writing this off as "the password got cracked" invites a repeat. In reality several authentication layers were thin at once.
The setup that failed
- A payment app with no two-factor authentication (ID + password only)
- Password reset deliverable to an unregistered email address
- No resistance to credential-stuffing with leaked credentials
- Insufficient review of the auth flow before launch
The setup that holds
- Require 2FA / passkeys on sensitive actions
- Send reset passwords only to registered channels
- Detect, rate-limit and lock credential-stuffing
- Review the auth flow before launch (kill single points of failure by design)
Design over speed: the after-the-fact bill dwarfs the up-front one
7pay took fraud right after launch, suspended all charging, and in about three months scrapped the service entirely. Racing to compete while skipping auth-flow review means the cost of lost trust, withdrawal and rebuilding far exceeds the up-front design investment. Design authentication to match the value you protect — before launch, not after.
How you defend against this
Even if you don't build payments, if there's a single place where one login moves a lot of value, this is yours. In priority order:
Offer two-factor authentication (2FA) on sensitive actions
Put 2FA on login and on money/data-moving actions, and prefer phishing-resistant methods like passkeys where you can. Even a one-time password (OTP) is far stronger than a single password.
Restrict password reset to 'registered channels only'
Send the new password or reset link only to the registered email/phone — never an arbitrary destination. Don't pass identity checks on fragments alone (date of birth, phone). Notify the owner immediately when a reset happens.
Assume credential-stuffing; detect and limit it
Attacks that replay leaked credentials are a given. Add rate limits, anomalous-login detection, and lockout after N tries, and reject known-breached passwords. Nudge users away from reuse.
Review the auth flow before launch
Have login, reset and re-auth reviewed by a second set of eyes at design time and before launch. "It works" is not "it's safe." Don't skip auth review for speed.
Where this overlaps with how this site is built
At its core, this incident was about guarding a valuable action with a single weak factor, and then letting a weak reset steal that factor. That is the mirror image of this site's own principles — don't build single points of failure, defend sensitive actions in layers, and shrink the blast radius. Beyond payments, any admin panel where one login reaches balances or every user's data carries the same danger. "Add 2FA, reset only to registered channels, re-authenticate before sensitive actions" is a defense anyone can implement at any scale.
Sources (public record)
The facts here are based on the following public information. No attack how-to is included — only the defensive lessons.
- Seven & i Holdings, "Notice of discontinuation of the '7pay' service" (2019) — 7andi.com
- Seven-Eleven Japan, "Unauthorized access to some '7pay' accounts" (2019) — sej.co.jp
- Japan METI, disclosures on cashless-payment fraud response (2019) — meti.go.jp
Read next
- Terms: Two-factor authentication (2FA) / One-time password (OTP)
- Term: Passkey (authentication that doesn't rely on a password)
- Practice: Authentication vs authorization / Security baseline checklist
FAQ
QWhat was the root cause of the 7pay incident?
Authentication design. A payment app shipped without two-factor authentication (2FA), so login required only ID + password. Worse, the password-reset flow could send the new password to an email address other than the registered one, so fragments of personal data (date of birth, phone number, email) were enough to take over an account. The setup was also weak against credential-stuffing (reusing IDs/passwords leaked from other services).
QI don't build a payment service — is this relevant to me?
Yes. The real issue is protecting a valuable action (money, personal data) with a single password, and then letting a weak reset flow steal that one password. Offer 2FA at login, send password resets only to the registered channel, and re-authenticate before sensitive actions. That applies to any app or admin panel.
QAs an individual user, what can I do?
Yes: (1) never reuse passwords across services (this neutralizes credential-stuffing); (2) turn on 2FA or a passkey wherever it's offered; (3) enable transaction notifications for payments so you notice anomalies fast. Even if the operator's design is weak, not reusing passwords closes off the main takeover path.