Technical Causes and Accounting Security Design for Abnormal Game Recharge Credits

1. Starting with an Extreme Case

A widely discussed case involved a user who made a small recharge, while a system failure credited an astronomical amount of virtual currency. After the user spent part of it in the game, the platform asked the user to make up the difference based on the fiat-currency price of the virtual currency, and the two sides disagreed over responsibility.

Setting aside emotional reactions, the technical essence of this type of incident is very clear: an abnormal amplification of a single accounting write, combined with irreversible consumption on the spending side, ultimately becomes a question of responsibility allocation. For any system involving virtual property, this is a scenario that must be defended against in advance. This article does not start from the correctness of a particular judgment. Instead, it treats the incident as a typical accounting security engineering problem and breaks it down: how the anomaly occurs, why it is difficult to roll back, and how architecture design can keep risk within an acceptable range.

2. Technical Attribution of Abnormal Crediting

Recharge crediting is essentially a cross-system state change: the payment side confirms receipt, the accounting side increases the balance, and the business side issues items or virtual currency. A deviation in any link can cause an amount mismatch. Common causes include:

1. Amount unit and precision errors. The payment side uses cents, the accounting side uses yuan, or virtual currency has multiple exchange ratios. Mistakes in multiplication or division, integer overflow, and floating-point precision loss can all magnify a small payment by several orders of magnitude.
2. Duplicate consumption and replay. A payment callback is delivered repeatedly due to network jitter. If the server does not handle idempotency, the same order will be credited multiple times.
3. Concurrent write races. Balance updates use a read-modify-write pattern without atomicity guarantees, resulting in lost updates or over-accumulation under high concurrency.
4. Configuration and rule errors. Recharge tiers, bonus multipliers, event bonuses, and other operational configurations are set incorrectly, causing issuance to deviate from expectations.
5. Compensation logic out of control. Batch resend scripts after an incident lack upper-limit validation, turning a small-scope compensation into a global anomaly.

As can be seen, the vast majority of anomalies are not “hacker attacks” but ordinary engineering defects amplified in the sensitive dimension of money. This also determines the defense approach: do not rely on human caution; rely on mechanism constraints.

3. Why “Post-Incident Recovery” Is So Technically Passive

The core dispute in the case is that part of the over-issued virtual currency had already been consumed, and the platform demanded recovery calculated at the fiat-currency price. From a system perspective, this exposes three structural difficulties:

First, there is no natural one-to-one correspondence between virtual currency and fiat currency. Virtual currency is often obtained through multiple channels such as recharge bonuses, event rewards, and task outputs, and its “cost” and “face value” are not consistent. Once abnormal issuance occurs, there is no technical basis for deciding which price to use for conversion.

Second, consumption behavior is irreversible. After virtual currency is used for lotteries, item purchases, or gifts to others, it has already been converted into other assets or sunk costs. A simple “balance deduction” cannot handle insufficient balance, and forced deduction creates a negative balance, which then affects all subsequent accounting calculations.

Third, responsibility boundaries require an evidence chain. The platform must prove that “this was a system failure rather than user behavior,” and the user must prove that “I spent based on reasonable reliance.” Both claims depend on complete and tamper-evident operation logs. Without audit trails, neither side can easily prove its case.

Therefore, the correct engineering posture is to front-load the problem: make anomalies as unlikely as possible, detect them quickly when they occur, roll them back precisely when detected, and define responsibility when rollback is impossible. Do not wait until afterward to negotiate with users.

4. Core Design for Accounting Security

4.1 Idempotency and Unique Constraints

Every entry point involving an amount change must use a business unique key for idempotency control. Taking recharge crediting as an example, the order number should be a globally unique identifier, and a unique index should be created at the database layer to ensure that the same order is credited at most once.

CREATE TABLE account_credit (
  id            BIGINT PRIMARY KEY,
  order_no      VARCHAR(64) NOT NULL,
  user_id       BIGINT NOT NULL,
  amount        BIGINT NOT NULL,      -- stored in the smallest currency unit
  currency_type VARCHAR(16) NOT NULL,
  status        TINYINT NOT NULL,     -- 0 pending, 1 success, 2 failed
  created_at    DATETIME NOT NULL,
  UNIQUE KEY uk_order (order_no)
);

This should be combined with a “persist first, process later” flow: when a callback arrives, first attempt to insert a ledger record. Only if the insert succeeds should crediting continue; if the insert conflicts, return a success response directly. In this way, even if the callback is delivered repeatedly, no second crediting will occur.

4.2 Double-Entry Bookkeeping and Ledger Reconciliation

A single balance field is fragile—it records only the result, not the process. A more robust approach is to introduce double-entry bookkeeping concepts: every balance change generates an immutable ledger entry, and the balance is derived from the entries (or updated by the entries and periodically verified).

Ledger entry example:
  Debit: user virtual-currency account   +1000
  Credit: recharge issuance account      -1000
  Reference: order_no = "xxx"

The ledger table should allow append-only operations and disallow updates and deletions. Any balance adjustment must be expressed as a “reversal entry” rather than by directly changing the number. The benefit is that the balance at any point in time can be recalculated and verified, and anomalies can be traced to specific ledger entries.

4.3 Upper-Limit Validation and Circuit Breaking

Amount-related operations must have business upper limits. Per-transaction recharge limits, daily cumulative limits, and per-issuance multiplier limits should all be hardcoded on the server side or strongly constrained through a configuration center, and upper-limit validation should be the last gate before crediting.

Furthermore, a circuit-breaking mechanism can be introduced: when the total issuance volume of a given issuance channel within a short period deviates from the historical baseline beyond a threshold, automatically pause that channel and trigger an alert. This can cut off the impact before the failure spreads.

4.4 Exception Rollback and Reversal Strategy

When an anomaly has been confirmed, the handling strategy should be layered according to “whether it is reversible”:

• Unconsumed portion: Generate a reversal entry directly to deduct it. The operation must record the reason, operator, and approval ticket number.
• Consumed portion: Trace where the consumption went. If it has been converted into recoverable assets, recover them; if it has already been sunk, enter a manual assessment process rather than having the system automatically deduct it.
• Insufficient balance: Do not allow the balance to be deducted below zero. Instead, convert it into a receivable or risk flag and hand it over to the business and legal teams.

The key principle is: the system performs only deterministic operations; ambiguous areas are handed to humans, but humans must leave complete records.

4.5 Audit Trails and Observability

All accounting-related operations—crediting, reversal, manual adjustment, and configuration changes—should be written to audit logs, including operation time, actor, before-and-after values, related order number, and reason description. Audit logs should be stored independently and physically isolated from the business database to prevent accidental modification by business logic.

At the monitoring level, dedicated metrics should be established for the accounting domain: crediting success rate, reversal rate, per-transaction amount distribution, abnormal large-amount alerts, reconciliation discrepancy count, and so on. Reconciliation tasks should run in near real time, comparing the payment-side and accounting-side order sets at least once per hour. Discrepancies should trigger alerts immediately rather than waiting until end of day.

5. Product and Rule-Level Support

Beyond technical controls, rule design is equally important. At a minimum, the user agreement should clarify that for abnormal issuance caused by system failure, the platform has the right to correct it after notification; if a user knowingly exploits an anomaly by consuming large amounts maliciously, the platform reserves the right to pursue accountability. At the same time, the recharge page should display clear exchange ratios and crediting rules to reduce ambiguity.

For dispute handling, it is recommended to establish a tiered response: small anomalies go through automated reversal, large anomalies go through manual review plus customer support communication, and extreme cases enter the legal process. Make “whether to recover and how to recover” a process with predefined plans rather than an ad hoc decision.

6. Conclusion

Returning to the initial question: after an abnormal credit, if the user spends heavily and refuses to return the funds, should the user bear legal liability? This is a legal question, but its premise is a technical one—whether the platform has the ability to prove that an anomaly exists, locate the scope of the anomaly, and quantify the impact of the anomaly. If the accounting system has idempotency constraints, double-entry ledgers, upper-limit circuit breaking, and complete auditing, then the vast majority of anomalies will be intercepted at the moment they occur or can be precisely rolled back, and the matter will never reach the point of confronting the user in court.

For developers, the core of a virtual property system is not how flashy its features are, but that the origin and destination of every cent are traceable, verifiable, and correctable. Putting this principle into table structures, API contracts, and monitoring metrics is what truly fulfills responsibility to the business and to users.