"What Does It Mean to 'Randomly Pick a Player to Charge'?" | Arknights: Endfield's Day-One Payment Bug—What Legal Liability Does Hypergryph Face?

Yesterday (January 22), Arknights: Endfield finally launched globally.

As a veteran Arknights Doctor who quit years ago,

Of course I

didn’t play.

(Still busy updating PrivaTrans v1.3)

But the Endfield drama still reached me—and it’s actually relevant to my day job.

After looking into it, I have to say…

For this bug to happen,

that’s truly impressive.

*This article reflects only the author’s personal views and is not intended as legal advice.

1. What Happened in Endfield?

Arknights: Endfield is Hypergryph Network’s highly anticipated sequel in the Arknights series. Since its announcement, it has drawn enormous expectations from players.

After multiple rounds of domestic beta testing, it finally launched globally on January 22.

However, shortly after launch, a flood of severe bugs emerged (some unverified), including one serious enough to go down in the history of operational mishaps.

Colloquially known as

“drawing from the player pool.”

In simple terms, any player worldwide who had linked PayPal to their account (similar to Alipay) and enabled one-click payment could potentially become the “server-wide public wallet.”

In theory, the normal payment flow for in-game purchases should be:

Player A buys a virtual item → the game server sends Player A’s user token with the charge request to PayPal → PayPal verifies Player A’s token and deducts the amount → PayPal sends a confirmation → the game delivers the item to Player A.

But what happened this time was:

Player B (and C, D, E…) buys a virtual item → the game server continues sending Player A’s user token with the charge request to PayPal → PayPal verifies Player A’s token and deducts the amount → PayPal sends a confirmation → the game delivers the item to Player B (and C, D, E…).

The result: Player A did nothing but watch their phone buzz nonstop as their account balance was drained by unfamiliar orders from around the world.

Because the charges involved multiple currencies (JPY, USD, EUR, etc.), the account could even be frozen by risk control for suspected “cross-border fraud.”

Based on reports so far, the “luckiest” victim had a total of €15,000 (≈ ¥125,000) charged:

There used to be a classic Zhihu question:

Never thought this would become reality so soon—though in golden form, and no one would actually “die”:

2. What Could Be the Cause?

Although the official postmortem hasn’t been released, let’s first look at the normal PayPal one-click payment flow:

We can see that PayPal itself only verifies whether the person presenting the token is authorized to charge—not whether the token actually belongs to the player currently making the transaction.

When the game service provider holds Player A’s “vault key” (Token) and tells PayPal “I’m representing A to pay this,” PayPal just checks if the key is real and lets it through.

So the root of the problem likely lies on Hypergryph’s server side.

In simple terms, Hypergryph’s server handed over the wrong “key” (token) when initiating the request.

Here are two possible causes I’ve considered:

Possibility 1: Race Condition Under High Concurrency

At the moment of launch, players’ spending enthusiasm was extremely high. The server faced enormous pressure, with potentially hundreds of thousands of payment requests flooding in per second.

To enable PayPal one-click payments, Hypergryph’s server needed to input two key parameters for each order: its own Access Token and the user’s Billing Agreement ID (BAID, functioning like a “pay-on-sight” authorization).

If the backend service failed to implement strict thread-safety protections when processing these requests, a “cross-wiring” situation could occur.

It’s like a bank counter with only one window (shared resource). The teller (server thread) just finished handling Player A’s bank card (BAID token) and hasn’t returned it yet (or the process lacks a return step), when Player B cuts in to make a withdrawal.

And the teller just goes ahead and uses Player A’s card to process the withdrawal.

// Pseudocode

Player A is ready to pay. This server node triggers the payment function for the first time, reads A’s BAID into memory. After a round of operations, Player A gets their purchased item and is charged successfully.

Then Player B’s request comes in. Since the old BAID data wasn’t cleared, B’s request directly reuses this memory variable. The program thinks “there’s payment info, just use it.”

As a result, the request ultimately sent to PayPal is:

[A has a pending order]

[A has another pending order (actually placed by B)]

As long as the variable isn’t cleared, subsequent players C, D, E all become “serial killers” until some new operation resets this payment info.

Possibility 2: Redis Cache Key Collision

Faced with massive global launch traffic, to improve performance under high concurrency, the server typically uses Redis (a super-fast Key-Value database, often used to store tokens—I use it for many services) for high-frequency data caching, avoiding costly and slow database queries.

“They’ll definitely keep spending!”

So the server didn’t verify by querying the database for payment info each time. Instead, after one lookup, it stored all BAIDs in Redis.

When the backend processed new orders, it could directly fetch BAIDs from Redis.

But unfortunately, it probably didn’t implement “UID:BAID” verification, or the key was set incorrectly, or the code hardcoded extracting “the first BAID in the database.”

Either way, some “lucky” player’s BAID became the “public wallet.”

Moreover, because of global operations, a single server couldn’t handle the load—clustering was necessary.

K8s (Kubernetes) launch!

Then tools like RedisShake were used to sync Redis data across nodes.

Since the K8s cluster was deployed across different global nodes (corresponding to different currency settlement zones), this explains why the victim’s account was bombarded with JPY, USD, EUR, and even various obscure currencies.

3. What Legal Consequences Could Follow?

Given that the affected payment channel is PayPal and this is a global incident, let’s look at what official actions, penalties, or liabilities might arise in the EU, US, and Japan (corresponding to the main currency sources in the screenshots).

Europe

Europe has the strictest data privacy protection globally.

The EU has the well-known GDPR. In this incident, Player A’s payment credential (BAID) was used to process Player B’s transaction, which could constitute serious “unauthorized data processing.”

Under GDPR, for violations involving failure to protect user data security (Security of Processing) with high-risk consequences, the maximum fine can be up to 4% of global annual turnover or €20 million (whichever is higher).

Given Hypergryph’s global scale, that could be an astronomical sum… or is it?

Hypergryph’s core game Arknights is operated overseas by Yostar. For Ex Astris and Endfield, the overseas operator is GRYPHLINE, an overseas publishing brand under GryphLine—Hypergryph’s own overseas subsidiary established in Singapore and Japan.

Given Ex Astris’ actual revenue and the fact that Endfield just launched, 4% might not amount to much. So the maximum penalty would be €20 million.

If they can’t pay, they could just bankrupt the subsidiary, right?

Wrong!

In EU GDPR enforcement practice, the concept of an “Undertaking” typically follows EU competition law.

If the parent company (Hypergryph) exercises decisive influence over its subsidiary (GRYPHLINE), they are considered the same economic entity. EU regulators are fully entitled to calculate the 4% fine based on the entire group’s (parent + subsidiary, a.k.a. “piercing the corporate veil”) global annual turnover, to ensure the penalty is deterrent.

When issuing fines, regulators have the right to directly pierce through the subsidiary and hold the parent company jointly liable.

The fine base is calculated on the total global turnover of the entire group (parent + all subsidiaries), not just the bankrupt subsidiary’s book value.

Considering that the developer (Hypergryph) wrote the game code, and GRYPHLINE (the operator) is its subsidiary—the entire incident occurred within the Hypergryph group—they can easily be deemed joint controllers and held jointly liable.

In other words, if the subsidiary can’t pay (goes bankrupt), victims and regulators can directly go to the parent company (Hypergryph) for full compensation.

For example: when France first invoked GDPR against Google in 2019, it directly referenced Google Inc. (the group) rather than Google France’s revenue, ultimately imposing a €50 million fine.

United States

The US is a litigation powerhouse. This incident has all the elements that excite lawyers: financial losses, multinational corporations, and massive numbers of victims—a dream for American lawyers.

Affected players (not only those whose money was taken, but also those whose accounts were frozen or whose game experience suffered due to refund rollbacks) are highly likely to file a class-action lawsuit (which US lawyers will typically encourage).

Claims include but are not limited to: negligence, unjust enrichment, breach of contract, and violations of consumer protection laws.

If they don’t settle, beyond compensating players for their losses, a jury often awards substantial punitive damages.

For example: the 1994 McDonald’s coffee case, where the jury initially ordered McDonald’s to compensate the victim $160,000 in compensatory damages plus $2.7 million in punitive damages.

Additionally, if this bug resulted from a lack of basic security testing, the FTC (Federal Trade Commission) could investigate whether it constitutes “unfair or deceptive business practices” and require the company to undergo third-party auditing for up to 20 years.

Japan

As the main battleground for anime-style games, Japanese law isn’t as aggressive as EU or US law, but its scrutiny is still significant.

Similar to GDPR, Japan’s Act on the Protection of Personal Information requires businesses to take necessary security measures for personal data (including payment information).

With such a large-scale bug involving misused data, the game company must report to the Personal Information Protection Commission and notify victims, or face administrative penalties.

Regarding in-game currency and erroneous charges, Japan’s Financial Services Agency and Consumer Affairs Agency may intervene under the Payment Services Act and the Consumer Contract Act, with the authority to issue “business improvement orders.”

Unlike fines, being officially labeled a “dishonest business” can lead to banks tightening cooperation, artists refusing commissions, and IP partners canceling collaborations.

Given that the Japanese market is one of Hypergryph’s main revenue sources with extensive artist collaborations, this Japanese-style social death could be more painful than a fine.

4. Final Thoughts

According to Hypergryph’s latest announcement, they have disabled the PayPal channel and promised full refunds.

But there’s a new operational nightmare:

How to roll back?

Player A’s deducted money must be refunded.

But Player B (the freeloader) has already used the items, pulled characters, and even fed them upgrade materials.

If the game forcibly deducts Player B’s items and retrieves their six-star characters, Player B will rage: “I clicked to pay—your system bug caused this. Why are you taking my resources/characters?”

If they don’t deduct Player B’s resources, Player A (and other legitimate paying players) will rage: “Why do they get free draws?”

Of course, if they don’t care about reputation, they could set resources to negative.

Let the operations team figure that out.

What Hypergryph needs most right now might be emergency hiring for operations and legal staff.